Linear hashing: The signing hash (sig_hash) and unique identifier (tx_hash) of an RLP transaction are computed by linear keccak256 hashes across its serialization. Even if only partial data is of interest, linear hashes require the full transaction data to be present, including potentially large calldata or access lists. This also applies when computing the from address of a transaction based on the sig_hash.
Inefficient inclusion proofs: The Merkle-Patricia Trie (MPT) backing the execution block header’s transactions_root is constructed from the serialized transactions, internally prepending a prefix to the transaction data before it is keccak256 hashed into the MPT. Due to this prefix, there is no on-chain commitment to the tx_hash and inclusion proofs require the full transaction data to be present.
Incompatible representation: As part of the consensus ExecutionPayload, the RLP serialization of transactions is hashed using SSZ merkleization. These SSZ hashes are incompatible with both the tx_hash and the MPT transactions_root.
No extensibility: Transaction types cannot be extended with optional features. Hypothetically, if EIP-4844 blob transactions existed from the start, new features such as EIP-2930 access lists and EIP-1559 priority fees would have required two new transacion types each to extend both the basic and blob transaction types.
Technical debt: All client applications and smart contracts handling RLP transactions have to correctly deal with caveats such as LegacyTransaction lacking a prefix byte, the inconsistent chain_id and v / y_parity semantics, and the introduction of max_priority_fee_per_gas between other fields instead of at the end. As existing transaction types tend to remain valid perpetually, this technical debt builds up over time.
Inappropriate opaqueness: The Consensus Layer treats RLP transaction data as opaque, but requires validation of consensus blob_kzg_commitments against transaction blob_versioned_hashes, resulting in a more complex than necessary engine API.
This EIP defines a lossless conversion mechanism to normalize transaction representation across both Consensus Layer and Execution Layer while retaining support for processing RLP transaction types.
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.
All transactions are represented as a single, normalized SSZ container. The definition uses the StableContainer[N] SSZ type and Optional[T] as defined in EIP-7495.
Name
Value
Description
MAX_FEES_PER_GAS_FIELDS
uint64(2**4) (= 16)
Maximum number of fields to which FeesPerGas can ever grow in the future
MAX_CALLDATA_SIZE
uint64(2**24) (= 16,777,216)
Maximum input calldata byte length for a transaction
MAX_ACCESS_LIST_STORAGE_KEYS
uint64(2**19) (= 524,288)
Maximum number of storage keys within an access tuple
MAX_ACCESS_LIST_SIZE
uint64(2**19) (= 524,288)
Maximum number of access tuples within an access_list
MAX_AUTHORIZATION_PAYLOAD_FIELDS
uint64(2**4) (= 16)
Maximum number of fields to which AuthorizationPayload can ever grow in the future
MAX_AUTHORIZATION_LIST_SIZE
uint64(2**16) (= 65,536)
Maximum number of authorization tuples within an access_list
MAX_TRANSACTION_PAYLOAD_FIELDS
uint64(2**5) (= 32)
Maximum number of fields to which TransactionPayload can ever grow in the future
EIP-7495Profile definitions provide type safety for valid transactions. Their original RLP TransactionType is retained to enable recovery of their original RLP representation and associated sig_hash and tx_hash values where necessary.
Helpers are provided to identify the EIP-7495Profile of a normalized Transaction. The type system ensures that all required fields of the Profile are present and that excluded fields are absent.
LEGACY_TX_TYPE=TransactionType(0x00)ACCESS_LIST_TX_TYPE=TransactionType(0x01)FEE_MARKET_TX_TYPE=TransactionType(0x02)BLOB_TX_TYPE=TransactionType(0x03)SET_CODE_TX_TYPE=TransactionType(0x04)SET_CODE_TX_MAGIC=TransactionType(0x05)defidentify_authorization_profile(auth:Authorization)->Type[Profile]:ifauth.payload.magic==SET_CODE_TX_MAGIC:ifauth.payload.chain_id==0:raiseException(f'Unsupported chain ID in Set Code RLP authorization: {auth}')returnRlpSetCodeAuthorizationraiseException(f'Unsupported authorization: {auth}')defidentify_transaction_profile(tx:Transaction)->Type[Profile]:iftx.payload.type_==SET_CODE_TX_TYPE:forauthintx.payload.authorization_listor[]:auth=identify_authorization_profile(auth)(backing=auth.get_backing())ifnotisinstance(auth,RlpSetCodeAuthorization):raiseException(f'Unsupported authorization in Set Code RLP transaction: {tx}')returnRlpSetCodeTransactioniftx.payload.type_==BLOB_TX_TYPE:if(tx.payload.max_priority_fees_per_gasorFeesPerGas()).blob!=0:raiseException(f'Unsupported blob priority fee in Blob RLP transaction: {tx}')returnRlpBlobTransactioniftx.payload.type_==FEE_MARKET_TX_TYPE:returnRlpFeeMarketTransactioniftx.payload.type_==ACCESS_LIST_TX_TYPE:returnRlpAccessListTransactioniftx.payload.type_==LEGACY_TX_TYPE:returnRlpLegacyTransactionraiseException(f'Unsupported transaction: {tx}')
To obtain a transaction’s from address, its identifier, or an authorization’s authority address, see EIP assets for a definition of compute_sig_hash, compute_tx_hash, and compute_auth_hash that account for the various transaction types.
In the engine API, the structure of the transactions field in ExecutionPayload versions adopting this EIP is changed from Array of DATA to Array of TransactionV1.
TransactionV1 is defined to map onto the SSZ Transaction type, as follows:
payload: TransactionPayloadV1 - An OBJECT containing the fields of a TransactionPayloadV1 structure
signature: ExecutionSignatureV1 - An OBJECT containing the fields of an ExecutionSignatureV1 structure
TransactionPayloadV1 is defined to map onto the SSZ TransactionPayloadStableContainer, as follows:
type: QUANTITY|null, 8 Bits or null
chainId: QUANTITY|null, 256 Bits or null
nonce: QUANTITY|null, 64 Bits or null
maxFeesPerGas: FeesPerGasV1|null - An OBJECT containing the fields of a FeesPerGasV1 structure or null
gas: QUANTITY|null, 64 Bits or null
to: DATA|null, 20 Bytes or null
value: QUANTITY|null, 256 Bits or null
input: DATA|null, 0 through MAX_CALLDATA_SIZE bytes or null
accessList: Array of AccessTupleV1 - 0 through MAX_ACCESS_LIST_SIZEOBJECT entries each containing the fields of an AccessTupleV1 structure, or null
maxPriorityFeesPerGas: FeesPerGasV1|null - An OBJECT containing the fields of a FeesPerGasV1 structure or null
blobVersionedHashes: Array of DATA|null - 0 through MAX_BLOB_COMMITMENTS_PER_BLOCKDATA entries each containing 32 Bytes, or null
authorizationList: Array of AuthorizationV1 - 0 through MAX_AUTHORIZATION_LIST_SIZEOBJECT entries each containing the fields of an AuthorizationV1 structure, or null
FeesPerGasV1 is defined to map onto the SSZ FeesPerGasStableContainer, as follows:
regular: QUANTITY|null, 256 Bits or null
blob: QUANTITY|null, 256 Bits or null
AccessTupleV1 is defined to map onto the SSZ AccessTupleContainer, as follows:
address: DATA, 20 Bytes
storageKeys: Array of DATA - 0 through MAX_ACCESS_LIST_STORAGE_KEYSDATA entries each containing 32 Bytes
AuthorizationV1 is defined to map onto the SSZ AuthorizationContainer, as follows:
payload: AuthorizationPayloadV1 - An OBJECT containing the fields of an AuthorizationPayloadV1 structure
signature: ExecutionSignatureV1 - An OBJECT containing the fields of an ExecutionSignatureV1 structure
AuthorizationPayloadV1 is defined to map onto the SSZ AuthorizationPayloadStableContainer, as follows:
magic: QUANTITY|null, 8 Bits or null
chainId: QUANTITY|null, 256 Bits or null
address: DATA|null, 20 Bytes or null
nonce: QUANTITY|null, 64 Bits or null
ExecutionSignatureV1 is defined to map onto the SSZ ExecutionSignatureStableContainer, as follows:
secp256k1: DATA|null, 65 Bytes or null
Consensus ExecutionPayload changes
When building a consensus ExecutionPayload, the transactions list is no longer opaque and uses the new Transaction type.
The additional validation constraints defined in EIP-4844 also apply to transactions that define tx.payload.blob_versioned_hashes or blob_data.
Transaction gossip announcements
The semantics of the types element in transaction gossip announcements (NewPooledTransactionHashes) are changed to match ssz(PooledTransaction.active_fields()). The separate control flow for fetching blob transactions compared to basic transactions is retained.
Note that this change maps active_fields for PooledTransaction with blob_data to 0x03, which coincides with the previous BLOB_TX_TYPE prefix of blob RLP transactions.
Objects are encoded using SSZ and compressed using the Snappy framing format, matching the encoding of consensus objects as defined in the consensus networking specification. As part of the encoding, the uncompressed object length is emitted; the RECOMMENDED limit to enforce per object is MAX_CHUNK_SIZE bytes.
Implementations SHOULD continue to support accepting RLP transactions into their transaction pool. However, such transactions MUST be converted to SSZ for inclusion into an ExecutionPayload. See EIP assets for a reference implementation to convert from RLP to SSZ, as well as corresponding test cases. The original sig_hash and tx_hash are retained throughout the conversion process.
Rationale
Switching to a single, unified and forward compatible transaction format within execution blocks reduces implementation complexity for client applications and smart contracts. Future use cases such as transaction inclusion proofs or submitting individual verifiable chunks of calldata to a smart contract become easier to implement with SSZ.
Various protocol inefficiencies are also addressed. While the transaction data is hashed several times under the RLP system, including (1) sig_hash, (2) tx_hash, (3) MPT internal hash, and (4) SSZ internal hash, the normalized representation reduces the hash count. Furthermore, Consensus Layer implementations may drop invalid blocks early if consensus blob_kzg_commitments do not validate against transaction blob_versioned_hashes and no longer need to query the Execution Layer for block hash validation.
Backwards Compatibility
Applications that rely on the replaced MPT transactions_root in the block header require migration to the SSZ transactions_root.
While there is no on-chain commitment of the tx_hash, it is widely used in JSON-RPC and the Ethereum Wire Protocol to uniquely identify transactions. The tx_hash remains stable across the conversion from RLP to SSZ.
The conversion from RLP transactions to SSZ is lossless. The original RLP sig_hash and tx_hash can be recovered from the SSZ representation.