Relationship between Transaction Trie and Receipts Trie

Question

Reading through the Yellow paper, I can see that each block header includes the Keccak 256 hash of the root of the trie for transactions and transaction receipts. I am struggling to understand how and where they are created.

How are the Transactions Trie and the Transaction Receipts Trie related for a given block?

Is it the case that, as the world state is updated by going through the transactions, the transactions and transaction receipts are stored in their respective tries?

Answer 1

Transaction Tries and Transaction Receipt Tries are indeed independent data structures with distinct roots stored on the blockchain header and differ in both purpose and content.

Purpose:

• Transaction Tries: records transaction request vectors

• Transaction Receipt Tries: records the transaction outcome

Content:

Parameters used in composing a Transaction Trie [details in section 4.3 of the yellow paper]:

• nonce,
• gas price,
• gas limit,
• recipient,
• transfer value,
• transaction signature values, and
• account initialization (if transaction is of contract creation type), or transaction data (if transaction is a message call)

Parameters used in composing a Transaction Receipt Trie [details in section 4.4.1 of the yellow paper]:

• post-transaction state,
• the cumulative gas used,
• the set of logs created through execution of the transaction, and
• the Bloom filter composed from information in those logs

Answer 2

In https://blog.ethereum.org/2015/11/15/merkling-in-ethereum Vitalik Buterin gave an example of using the different trees (transactions, receipt, state trees).

• Has this transaction been included in a particular block?
• Tell me all instances of an event of type X (eg. a crowdfunding contract reaching its goal) emitted by this address in the past 30 days
• What is the current balance of my account?
• Does this account exist?
• Pretend to run this transaction on this contract. What would the output be?

The first is handled by the transaction tree; the third and fourth are handled by the state tree, and the second by the receipt tree. The first four are fairly straightforward to compute; the server simply finds the object, fetches the Merkle branch (the list of hashes going up from the object to the tree root) and replies back to the light client with the branch. The fifth is also handled by the state tree, but the way that it is computed is more complex. Here, we need to construct what can be called a Merkle state transition proof. Essentially, it is a proof which make the claim “if you run transaction T on the state with root S, the result will be a state with root S', with log L and output O” (“output” exists as a concept in Ethereum because every transaction is a function call; it is not theoretically necessary).

Receipts are basically for proving logs and events.