Uncouple execution payload from beacon block

Abstract

Currently, the beacon block in Ethereum Consensus embeds transactions within the ExecutionPayload field of BeaconBlockBody. This EIP proposes to replace ExecutionPayload with ExecutionPayloadHeader in BeaconBlockBody and to independently transmit ExecutionPayloadWithInclusionProof.

However, this EIP makes no change to the block import mechanism, with the exception that block availability now includes waiting for the availability of ExecutionPayloadWithInclusionProof, making it different and simpler from proposals like ePBS/APS.

But this availability requirement can in fact be restricted to gossip import while allowing optimistic syncing of the execution layer (EL) on checkpoint/range sync as EL can pull full blocks from their peers in optimistic sync as they do now.

Motivation

The Ethereum protocol has an ambitious goal to grow the gasLimit of the execution payloads (possibly by 10X). This leads to larger messages, negatively affecting the networking and block processing pipelines of the consensus layer (CL) clients leading to following issues:

1. Higher latencies for the arrival of beacon blocks increase, requiring larger bandwidth resources to be made available for the beacon node.
2. The greater number and size of transactions directly increase the merkelization compute time, increasing the import time of the block.

We know from timing games that the block import latency greatly affects a client's performance to make correct head attestations. With this EIP, block transmission and block import processes will be decongested, allowing for greater flexibility in receiving a larger ExecutionPayloadWithInclusionProof, while the beacon block can simultaneously undergo processing.

In addition, EL clients can also independently participate in forwarding and receiving larger execution blocks. That mechanism however can be independently developed and is out of scope for this EIP.

Additional benefits obtained from this EIP:

• Consensus clients don't need to store and serve blocks with transactions, providing greater efficiency and reduced resource requirements for running a beacon node.
• The proposer-builder separation (PBS) pipeline becomes more efficient by the proposer transmitting the signed block directly to the p2p network, while submitting to the builder/relay for the independent reveal of the ExecutionPayloadWithInclusionProof.
• In the future with zero-knowledge (ZK) proof of the EL block execution, nodes could treat the transactions similarly to blobs which leverage data availability sampling (DAS) mechanisms for available data without requiring re-execution of transactions to establish validity. Hence the L1 execution could itself become a rollup by alleviating the need to import all transaction data by a node.

Furthermore CL clients apis and code path will become cleaner and more maintainable because of collapse of blinded and full versions (like BlindedBeaconBlock, BlindedBeaconBlockBody) into same types.

Specification

• ExecutionPayload in the BeaconBlockBody is replaced by ExecutionPayloadHeader
• ExecutionPayloadWithInclusionProof is computed by the block proposer/builder and gossiped independently on a separate new topic. Also builder submitBlindedBlock api is modified to respond with ExecutionPayloadWithInclusionProof instead.
• Data availability checks for block import into forkchoice now must wait for availability of the corresponding ExecutionPayloadWithInclusionProof but only for gossiped blocks
• newPayloadHeader engine api is introduced to augment the previous usage of newPayload in block processing when ExecutionPayload is not available for e.g. in processing range synced blocks signaling EL clients to optimistic sync those payloads from EL p2p network.

ELs can optionally introduce a getExecutionPayload method (similar to getBlobs) to assist with faster recovery of execution payload from the EL's p2p network peers who could announce new payload hashes when they see new VALID payloads. However, as noted above, that mechanism could be independently specified and is out of scope for this EIP.

<-- TODO: add spec details -->

Rationale

There is another choice we could have made to go for SignedExecutionPayload instead of ExecutionPayloadWithInclusionProof and having a SignedExecutionPayloadHeader with builder signing these messages (validator is the builder in local block building). But without builder enshrinement tight gossip validation of SignedExecutionPayload would be an issue and could become a DOS vector.

The benefit of SignedExecutionPayload design is that it could be transmitted ahead of even the SignedExecutionPayloadHeader inclusion in beacon block and is especially useful in PBS pipeline where the proposal to builder/relay latency can be reduced significantly.

Backwards Compatibility

This change isn't backward compatible and a new hardfork is required to activate this EIP.

Test Cases

<-- TODO -->

Reference Implementation

<-- TODO -->

Security Considerations

<-- TODO -->

Needs discussion.

Copyright

Copyright and related rights waived via CC0.