2

The documentation around emitting events states that events are written to storage, and then cleared next block.

This has considerable costs

  • You add extra db write/read overhead to practically every extrinsic, and cleanup, making extrinsics more expensive and wasting block weight.
  • As the log of events grows during block execution, the object being written back and forth to the underlying database becomes bigger and bigger, because its all one big Vec.

I have three questions about this

  • What is the benefit of this writing to storage, and why is this the default?
  • What is the downside of removing this writing to storage? does it cause some cascade of other changes one has to make?
  • Should we be seeing this cost, and the dbwrite, in our benchmarking? because we currently are not.
Improve this question

2 Answers 2

Reset to default
2

The idea behind writing the events into the storage is to ensure they influence the state root in the block and ensure that events are stored somewhere for retrieval.

The fact that the events are stored in the trie and influence the state root allows for anybody to ask "what were the events at this particular block" and get the answer with unforgeable proof. This is very useful for light clients.

Then to serve the events, they have to be stored somewhere. The most straightforward way to provide that is to ensure every node stores them.

Substrate and FRAME could be smarter about this. For example, an idea was floating around about introducing a transient trie. Such a trie would allow writing the elements to the set but won't allow the Substrate Runtime to read them. That trie would still maintain the state root when elements are inserted. If the storage of events were backed by a transient trie, then writing the events into the database becomes optional to follow the consensus. Thus, the nodes not interested in storing them can turn off that and save some disk throughput.

Improve this answer
4
  • 1
    This was a very useful reply, thank you. Is there any reason there just wasn't some logging commitment added to headers, separate from state root, similar to Ethereum receipts trie commitment, that solves the same problem while sidestepping all of this.
    – Bedeho Mender
    Aug 8, 2022 at 16:41
  • I guess the current solution was picked because it was really simple and fit into the initial vision of the light-client friendliness. That vision was changed over time though, and I think it would be pertinent to revisit this. It's also not 2017 anymore; we have way more experience, and the new tech was also discovered, and that would allow us to come up with a better solution.
    – pepyakin
    Aug 9, 2022 at 10:12
  • Lastly, the note about the receipts trie. The hypothetical transient trie Substrate feature I described above would allow replicating the same approach as the receipts trie.
    – pepyakin
    Aug 9, 2022 at 10:13
  • Thank you for the clarification.
    – Bedeho Mender
    Aug 10, 2022 at 11:22
1

Blockchain is a large state world tree.

Events were removed in the next block. But that does not mean they have never existed.

As you can see, most of the RPCs have an arg named at. You can fetch the state at any block.

For example, the events were removed at 100 block height. But you could fetch state at 99 block height. Then you know those events happened.

Imagine, if you have an event listener. Once it goes offline, does it mean all the events are lost? Apparently not, you can start the scan from an old block height.

Just a note. This is pretty useful in the cross-chain bridge. You could use the storage proof to perform the verification.

Improve this answer
1
  • 1
    Thank you for reply. There is a big distinction between saying they have existed and that it's wise to put them in runtime storage despite the state not being used in validation. Transactions also exist at specific blocks, that does not mean they should be in storage each block. Same apples to cross-chain inclusion proofs, they work fine for transactions without this. The problem is the state root has been overloaded in this use case (see Ethreum receipts trie commitment in headers), and a price is being paid.
    – Bedeho Mender
    Aug 8, 2022 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.