Title: Uncouple_execution_payload_from_beacon_block
Category: EIPs

Author: g11in
Date: 2025-03-01T17:21:14.017Z

Abstract
Currently the beacon block in ethereum consensus embeds the transactions in 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 except that block availability also now includes waiting for the availability of ExecutionPayloadWithInclusionProof and this is where its different (and simpler) from proposals like ePBS.
But this availability requirement can infact be restricted to gossip import while allowing optimistic syncing of ELs on checkpoint/range sync as EL can pull full blocks from their peers in optimistic sync as they do now.
Motivation
Ethereum protocol has an ambitious goal to grow the gasLimit of the execution payloads (possibly by 10X). This introduces bigger and bigger messages in the networking and block processing pipeline of the CL clients leading to following issues:


Latency for the arrival of Beacon Block increases and make it more and more dependent on the bandwidth resources available to the running node.


The greater number/size of transactions directly increase the merkelization compute time directly affecting 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 import pipeline will be unchocked and allows for greater flexibility in reception of huge ExecutionPayloadWithInclusionProof while the beacon block can undergo processing.
Infact EL clients can also independently participate in the propagation/pull of the execution blocks. That mechanism however can be independently developed and is not the part of this EIP.
Other side benefits of this EIP are that


consensus clients don’t need to store and serve blocks with transactions and provides greater efficiency and reduced resource requirement for running the nodes.


the PBS pipleline becomes more efficient by proposer transmitting the signed block directly to the p2p network while also submitting to the builder/relay for independent reveal of the ExecutionPayloadWithInclusionProof.


in future with ZK proof of the EL block execution, one could treat the transactions just like blobs leveraging DAS mechanisms for the availability without worrying about their execution validity.


Specification


ExecutionPayload in the BeaconBlockBody is replaced by ExecutionPayloadHeader


ExecutionPayloadWithInclusionProof is computed by the proposer/builder and transmitted independently on a gossip channel.


data availability checks now also wait for availability of a VALID ExecutionPayloadWithInclusionProof


newPayload on engine api is modified to now accept newPayloadHeader and a new method for newExecutionPayload is introduced to check the vailidity of the ExecutionPayload recieved within ExecutionPayloadWithInclusionProof


ELs can optionally introduce getExecutionPayload method (like getBlobs) to help fast recovery of execution payload from the EL p2p network but as noted above that mechanism could be independently speced and is not part of this EIP.
Update Log

2025-03-01: initial draft Add EIP: Uncouple execution payload from beacon block by g11tech · Pull Request #9432 · ethereum/EIPs · GitHub

External Reviews

Author: sbacha
Date: 2025-03-02T15:31:49.738Z

Why should timing games be of any consideration?

Author: g11in
Date: 2025-03-12T13:28:23.576Z

g11in:

We know from timing games that the block import latency greatly affects a client’s performance to make correct head attestations


its not a concern of this EIP but inference how critical the latency of import pipeline can get for a CL client