feat(token-blueprint): improved support for aggregation via events

[dvinubius]

Problem

When a token process mints, burns or transfers tokens, the significant changes to the process state are cumbersome to track, due to a lacking unified pattern.

The task of data aggregation via observing specific messages on the gateway can be simplified a lot if there is some standardized way of "emitting events" about such significant changes.

Solution

In a similar way to EVM systems, we can define event messages that are associated with the significant changes that occur in a mint / burn / transfer.

See the PR

Such event messages

• are reflexive (process sends them to self)
• have a standard tag e.g. Event = 'Mint'
• have specific semantic tags for all the data (as opposed to using the Data tag) , e.g. TotalSupply = TotalSupply

In order to be as focused as possible on serving as "events", these messages are somewhat redundant with the data they provide, in the sense that part of their data can be found in other messages too (Credit-Notices, Mint confirmations, etc.). But the advantages, we argue, make this compromise acceptable.

Unlike EVM systems, where limitations on data and computation make the events rather scarce and often cumbersome to leverage, on AO we can pack more useful data into them, thereby saving aggregators lots of heavy lifting.

The PR proposes a simple way to define events and integrate them in the existing message handlers.

Potential for a Standard

Since this pattern is very similar to EVM systems and it improves aggregation capabilities via the gateway, we think it would serve the builder community well if it became a standard. The token blueprint, being central in the landscape, is a great way to start with that.

Native Support Outlook

The event messages proposed in the PR are not native, as in EVM systems. But conceivably they could become native to AO, by making the global Events table be "reserved" and have utility functions, similarly to Handlers.