This EIP defines a migration process of existing Merkle-Patricia Trie (MPT) commitments for receipts to Simple Serialize (SSZ)
Motivation
While the consensus ExecutionPayloadHeader and the execution block header map to each other conceptually, they are encoded differently. This EIP aims to align the encoding of the receipts_root, taking advantage of the more modern SSZ format. This brings several advantages:
Better for light clients: Light clients no longer need to obtain and decode entire receipts to verify receipt related fields provided by the execution JSON-RPC API.
Better for smart contracts: The SSZ format is optimized for production and verification of merkle proofs. It allows proving specific fields of containers and allows chunked processing, e.g., to support handling receipts with lots of logs.
Reducing complexity: The proposed design reduces the number of use cases that require support for Merkle-Patricia Trie (MPT).
Specification
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.
Existing definitions
Definitions from existing specifications that are used throughout this document are replicated here for reference.
When building a consensus ExecutionPayload, the receipts_root is now based on the normalized Receipt SSZ container. Implementations that currently produce receipts in the EIP-2718 format can convert them using the normalize_receipt helper function.
The EIP-6404Transaction SSZ container defines computed fields that are derived from a transaction’s original representation. Namely, the tx_hash and tx_from fields, and also tx_to for DESTINATION_TYPE_CREATE. Arguments could be made to move them to the Receipt SSZ container.
While moving the fields would simplify consensus ExecutionPayload a bit, those fields do not fit the semantics of a receipt describing a transaction’s outcome after being applied to a state. The fields can be computed without access to a state. Furthermore, for SSZ transactions, the tx_hash and sig_hash are implicitly available as part of their original representation. Having those hashes in the transaction representation further suggests that they should not be copied into the receipt.
What about ReceiptLog data?
ReceiptLog data is formatted according to the Ethereum contract ABI. Merkleizing log data according to its original structure would be more useful than merkleizing it as a ByteVector. However, the data structure is determined by the log event signature, of which only the hash is known. As the hash preimages are erased from emitted EVM logs, it is not reliably possible to recover the original log event signature. Therefore, log data is provided as a ByteVector for now, with the option for a future EIP to extend it.
Backwards Compatibility
Applications that solely rely on the TypedReceipt RLP encoding but do not rely on the receipts_root commitment in the block header can still be used through a re-encoding proxy.
Applications that rely on the replaced MPT receipts_root in the block header can no longer find that information. Analysis is required whether affected applications have a migration path available to use the SSZ receipts_root instead.