[AIP-44][Discussion] Module Events

[lightmark]

AIP Discussion

This AIP defines module-level event framework targeting to replace the current instance event framework.
The new event framework associates every event stream with a static struct type instead of an EventHandle instance.

In short, an event will be defined like this:

/// An example module event struct denotes a coin transfer.
#[event]
struct TransferEvent<Coin> {
  sender: address,
  receiver: address,
  amount: u64
}

where emit event will be as simple as:

emit<T: store + drop>(event: T)

Read more about it here: Link to AIP

[alnoki]

Will these be treated as part of the authenticated data structure, e.g. can these be queried during runtime as if they were typical data?

Will this change be backwards compatible with the existing framework, e.g. will this be a breaking change for legacy projects that use the current event handle schema?

[lightmark]

Events are always part of the authenticated data structure as they contribute to the final ledger hash; however, they cannot be queried by move code during runtime as they are not data in state tree. They are actually stored in another tree. Similarly, Ethereum stores its events in receipt Trie iirc.

Unfortunately, it is not backwards compatible with the existing events (v1) since it is totally redesigned. It is not a breaking change as it's not going to replace v1 but just another(preferred) option for emitting events. The projects using existing event scheme will be supported but we believe devs will mostly prefer module events (v2) for all new projects as it is superior in all aspects.

[magnum6actual]

There may be utility in having a switch in the struct definition that would persist the storage of the event to the state tree to facilitate querying during runtime. Of course - this would have to come with necessary increases in gas fees if that switch was used.

[lightmark]

@magnum6actual we may adds utility functions to for test only purpose. Module events is a normal struct so if you wanna store event data somewhere as state as your wish, it is totally legit. But the purpose of event stream framework is to deliver notifications with metadata to for offchain systems. Another caveat to mention is differing from latest state, events are not guaranteed to be available forever as they're subject to pruning.

[alnoki]

Another caveat to mention is differing from latest state, events are not guaranteed to be available forever as they're subject to pruning.

@lightmark is the idea here to maximize pruning with the new event framework to consolidate event storage to gRPC streamers?

[lightmark]

@alnoki It has nothing to do with that. For pruning it will be the same with the old event stream.

[jolestar]

I suggest introducing the #[private_generics(T)] annotation to restrict the caller of emit to the module which defines the event T. move-language/move#1043

[lightmark]

I think for this solution, emit is treated specially as #[private_generics(T)] where T is annotated with #[event]. But I heard what you are trying to achieve.

[jolestar]

If the developer carelessly provides a published new function for an event, anyone can trigger a fake event.

[Vital7899]

Hi! So, as for me, I think the compatibility with previous version is also very useful and important. Especially, for first, initial period of adoption new one.

[lightmark]

If the developer carelessly provides a published new function for an event, anyone can trigger a fake event.

you mean provide a public function emitting module events?
This would be the same in solidity, right?

In programming, public function just means anyone can trigger the logic inside this function. I failed to see any loophole here.

[lightmark]

Hi! So, as for me, I think the compatibility with previous version is also very useful and important. Especially, for first, initial period of adoption new one.

Could you elaborate the compatibility you want? We keep both events coexisting and respect their emitting order.

[jolestar]

you mean provide a public function emitting module events?

A public construct function, like public fun new_event(a,b,c): XEvent{}

[Vital7899]

Hi! It would be nit so bad.

[lightmark]

you mean provide a public function emitting module events?

A public construct function, like public fun new_event(a,b,c): XEvent{}

Even if you do that by mistake, emit function does not allow any other module to emit this event except the one defining it. When you publish the contract it will throw an error. When you compile, compiler will complain too.