I tried to build a proof of inclusion for a particular receipt in a block, but I noticed that in some cases, the receipt was serialised together with the partial state root hash after executing this tx.

See more detailed information about this on this github issue.

Basically from the Yellow Paper (Section 4.3.1, equation 21) we see that the receipt is serialised as a tuple of four elements. In particular I'm more concerned about the first element. It can be one of two types:

  • Status of the Transaction, 0x01 for successful tx, and 0x00 for failed tx.
  • State root after applying the tx. (I understand this is there for legacy reason, but haven't confirmed that anywhere).

The Yellow Paper isn't very clear in this regard, and I like to know in which cases will be used the status of the transaction, and when the state root.

I see some recent receipts in Ropsten that are using state root. Is it possible that similar receipts are created in Ethereum Mainnet too, or is this the result of Ropsten using another fork?

Moreover my problem exists because the state root after a particular transaction is executed is not exposed in any RPC endpoint, the workaround I see for this is modifying one ethereum client to expose this particular info. How is it done now-days by other, if done at all?


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.