Currently NEAR supports Ethereum-like events in two ways:
- Used by contract that were already deployed, like fungible tokens, lockup contracts, staking pools, etc;
- Merkelized and merkle root is included in header, which makes it provable;
- Only accepts UTF8 strings, which is enforced by the protocol;
- Treat part of the function call output as event. E.g. make function calls output always return
(Vec<Event>, Result<T>). This is currently used by the Ethereum bridge;
- Technically exactly the same as emitting binary logs;
- Merkelized, since function call outputs are merkelized;
- Binary, which allows having Ethereum-like ABI;
- Deserializing one event requires deserializing all events that happened during contract execution. In Ethereum logs are serialized and merkelized independently;
Both approaches have a common disadvantage that they currently do not support Bloom filter similar to Ethereum events, which allows faster verification that an event has occurred on the chain.
Ethereum has a very well-thought DevX with events: support of ABI, easy provability, Bloom filters. We would like to have the same DevX for NEAR events.
I propose we achieve it in two, potentially separate steps:
log_binhost function in addition to
log_utf16(link). This function would accept any binary. We then will switch
env::login Rust SDK to use it instead;
- Add Bloom filter into block header;
Additionally, the first step would require some updates in
near-api-js and explorer to support displaying binary logs.
Another proposed alternative is to add a new type of logs, together with introduction of a separate merkelization mechanism.
The disadvantages of this approach is the following:
- Currently deployed contracts will not support it, so any kind of solution built on top of NEAR (e.g. the Graph) will not support contracts that were already deployed. Unfortunately, there are many important contracts that were already deployed that we need to continue supporting;
- It adds an almost duplicated new functionality, since merkelization mechanism is going to be exactly the same. This will unnecessarily complicate protocol spec and node implementation. Any kind of aggregation solution built on top of NEAR will also become more complex;
- It might confuse users developing contracts on NEAR, since it might not be clear why these logs are treated differently.
After a discussion in this thread, we are going to create a NEP proposal following the format described here.