Receipts, events, and logs (WIP)

[lrettig]

Overview

Transaction receipts are an essential part of any smart contract platform. They enable many light client use cases. As discussed in #13, they're the only way a user knows that their transaction has been executed, and its results (without rerunning a transaction through a full node). They're how a user keeps track of "internal" transactions affecting their balance, both in the native coin and in tokens. They also allow smart contracts to pass success, failure, or other events up to the application layer.

Background reading:

• https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/ (how reciepts/events tree fits into the higher-level data structure including transactions and state)
• https://github.com/ethereum/go-ethereum/issues/1897 (why Ethereum did not implement receipts for ETH transfers, and why doing so is hard)

Goals and motivation

High-level design

Proposed implementation

Implementation plan

Questions

Dependencies and interactions

Stakeholders and reviewers

Testing and performance

[avive]

One of the problems with the eth design is that receipts are part of canonical state. e.g. I think full nodes are supposed to verify them in order to verify the global state as the tx root is part of the block state, and so they were abused as cheap storage of historical data / state for dapps. Something we need to keep in mind.

[avive]

I think is that where we left things (see other smip draft) was here:

1. A receipt are generated per tx execution and is indexed by the tx id in the local node db. The receipt include the execution result and any log entries for svm tx.
2. Receipts are not part of the global state. A standard full node only stores the receipts of the last n=2048 layers or so. An archive mode, configured by cli flags, stores all the receipts from genesis. Full node, archive node and n should all be configurable from config file and cli flags. Events are just data entry in a receipt. There is no separate event data item.
3. The only other global state update side effect are rewards data items. Each reward assign to smesher should generate a reward item, indexed by the layer, smesher id and award coinbase account. Like receipts, standard nodes only store rewards for n=2048 layers, archive nodes store from genesis based on node config.
4. The API should be updated to return execution results of a receipt when the node generating a tx data has the receipt for the transaction. There's no need for a new TransactionReceipt data item - at least this is the current design idea... Rewards API is already specified and node just returns reward data items it knows about and has indexed.
5. We'll need to add n to the node api service. when 0 - node is archive node. when non-zero - node keeps receipts and rewards for n layers from the tip.
6. We need to decide about for how long standard nodes keep the intermediate state. e.g. the complete state tree for a past layer and implement in the api the way to query the state for a past layer. It is my understanding that intermediate state is currently not discarded and is kept from genesis in the local db. This needs to change where full nodes only store intermediate state for n=2048 layers and archive nodes store intermedia state from genesis.

Summary: Archive Node vs. Full Node Summary

• Archive node stores receipts, rewards data items and accounts db state at any layer from 0 to the tip and makes this data available via the api.
• A full node only store the above data in its db for n=2048 layers from the tip and should delete all older data automatically.

I think this covers the core.

[dshulyak]

we should start from scratch with all things related to transactions and receipts