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.
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:
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:
ExecutionPayloadWithInclusionProof.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.
ExecutionPayload in the BeaconBlockBody is replaced by ExecutionPayloadHeaderExecutionPayloadWithInclusionProof 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.ExecutionPayloadWithInclusionProof but only for gossiped blocksnewPayloadHeader 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 -->
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.
This change isn't backward compatible and a new hardfork is required to activate this EIP.
<-- TODO -->
<-- TODO -->
<-- TODO -->
Needs discussion.
Copyright and related rights waived via CC0.