EIP-7732 propagates the execution payload as a single message on the execution_payload gossipsub topic. This EIP replaces that topic with execution_payload_chunks, which carries the payload envelope split into TOTAL_EXECUTION_PAYLOAD_CHUNKS chunks. The builder commits to the chunk set with a Merkle root carried in the execution bid, so each chunk is independently verifiable from a single bid signature check plus an inclusion proof.
The gas-limit growth that EIP-7732 enables implies larger payloads leading to increased latency. If Payload Timeliness Committee (PTC) members do not receive the payload within the attestation deadline, an otherwise valid payload is considered missed.
The existing execution_payload gossipsub topic scales poorly as payloads grow. Two effects dominate:
Both effects are mitigated when the message is chunked. Large duplicates are impossible with chunk granularity, and a peer can forward each chunk as soon as it arrives, so hops overlap instead of serializing.
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.
| Constant | Value |
|---|---|
TOTAL_EXECUTION_PAYLOAD_CHUNKS | 64 |
CHUNK_INCLUSION_PROOF_DEPTH | 6 |
MAX_PAYLOAD_CHUNK_SIZE | MAX_PAYLOAD_SIZE // TOTAL_EXECUTION_PAYLOAD_CHUNKS (163,840 bytes) |
| Name | SSZ equivalent | Description |
|---|---|---|
ChunkIndex | uint64 | Index of a chunk, 0 through TOTAL_EXECUTION_PAYLOAD_CHUNKS - 1 |
Chunk | ByteList[MAX_PAYLOAD_CHUNK_SIZE] | Contiguous slice of the serialized ExecutionPayloadEnvelope |
The execution bid commits to the chunked envelope:
payload_chunks_root is the SSZ hash_tree_root of the Vector[Bytes32, TOTAL_EXECUTION_PAYLOAD_CHUNKS] of SHA-256 hashes of the chunks of the serialized ExecutionPayloadEnvelope, as computed by compute_payload_chunks_root in the Chunking section. A receiver therefore verifies one bid signature and, per chunk, one Merkle inclusion proof. Once the envelope is reconstructed, it MUST be checked against the payload hash committed in the beacon block.
Chunking is applied to the envelope:
beacon_block_root is removed because it is not known at the time of envelope construction.
Under EIP-7732 the builder constructs the envelope after observing that its bid was included, and can therefore embed the beacon block root. Under this EIP the builder must commit to the chunks when it produces the bid — before the block exists — so the root cannot be part of the committed bytes. It is instead carried per chunk in the PayloadChunk message, together with the payload_chunks_root committed in the bid:
payload_chunks_root matches the commitment in the bid and identifies the chunk set. Because bids propagate on their own gossip topic before the beacon block, a receiver that has observed a valid bid committing to this root can verify the chunk as soon as it arrives, without waiting for the block.
slot and beacon_block_root sit outside the inclusion proof and are unauthenticated hints: slot allows windowing a chunk cheaply and MUST equal the slot of a bid committing to payload_chunks_root, while beacon_block_root lets a receiver locate or request the corresponding beacon block and MUST equal the root of the block containing that bid. Receivers MUST NOT treat either field as authenticated and MUST use them only to route lookups; a chunk is bound to a bid solely through payload_chunks_root.
The builder MUST derive the chunks, and therefore payload_chunks_root, as follows. No padding is added: the last non-empty chunk can be shorter, and trailing chunks can be empty.
Each leaf is hash(chunk), the SHA-256 hash of the chunk's bytes; chunk_inclusion_proof is the corresponding Merkle branch:
Receivers concatenate chunks 0 through TOTAL_EXECUTION_PAYLOAD_CHUNKS - 1 and deserialize the result; nothing is stripped, since each leaf hashes its chunk's exact bytes.
This EIP introduces the execution_payload_chunks gossip topic and deprecates execution_payload. The topic carries PayloadChunk messages.
Once the builder observes a beacon block containing its bid, it is able to construct the TOTAL_EXECUTION_PAYLOAD_CHUNKS PayloadChunk messages and publishes them to the topic.
The Seen cache used by the gossip validation functions is extended to retain the chunk commitments of observed bids and to track received chunks:
The tuple (bid.slot, bid.payload_chunks_root) is added to payload_chunks_roots for every bid whose SignedExecutionPayloadBid is accepted on the bid gossip topic, and for the bid contained in every valid beacon block. Entries MUST be retained at least until the end of their slot (within MAXIMUM_GOSSIP_CLOCK_DISPARITY) and MAY be pruned afterwards. The set stays small: the bid topic's own validation rules bound how many bids enter it per slot.
payload_chunk_tuples records the (payload_chunks_root, index) pair of every accepted chunk, analogous to data_column_sidecar_tuples for column sidecars, and backs the first-seen check below.
The following validations MUST pass before a node forwards a PayloadChunk chunk on the topic.
chunk.slot equals the current slot, within MAXIMUM_GOSSIP_CLOCK_DISPARITY allowance.chunk.index is less than TOTAL_EXECUTION_PAYLOAD_CHUNKS.(chunk.slot, chunk.payload_chunks_root) is present in seen.payload_chunks_roots. Clients MAY queue chunks referencing an unknown root for a short period and revalidate once the bid arrives.verify_payload_chunk_inclusion_proof(chunk).chunk.payload_chunks_root: chunk.beacon_block_root equals the hash tree root of that block.(chunk.payload_chunks_root, chunk.index) is not present in seen.payload_chunk_tuples (first-seen per commitment and index); the tuple is added upon acceptance.A chunk that passes these validations MUST be forwarded immediately, without waiting for the remaining chunks or for the beacon block, and buffered until the envelope can be reconstructed.
bal_chunks topic following the same broadcasting scheme for Block Access List (BAL, EIP-7928) messages, which are currently part of the execution payload. This would allow BAL message propagation to start sooner than the rest of the payload.Why a Merkle commitment. Alternatives such as KZG place proof generation on the builder's critical path. A Merkle tree over chunks is cheap enough to build at bid time, and a single root in the bid makes each chunk self-verifying against one already-verified signature.
Why TOTAL_EXECUTION_PAYLOAD_CHUNKS = 64. The value is not derived from measurement; smaller chunk counts already show benefit compared to single large messages. 64 is chosen for forward compatibility in case we decide to extend protocol erasure coding via c-kzg, which segments data into 64 chunks and extends them to 128.
Why unpadded ByteList chunks. SSZ has no outer length prefix, so padding bytes would deserialize as envelope data; hashing each chunk's exact bytes commits its true length instead. Pinning the split and merkleization to SSZ lets two clients derive identical roots with existing code.
The execution_payload topic is removed, so this change is not backwards compatible and requires a fork.
TBD.
Chunks are not individually signed; their authenticity derives entirely from the bid signature via payload_chunks_root. The root carried in a chunk is unauthenticated on its own, but a chunk is only accepted if a bid that already passed signature validation committed to that root: a chunk referencing an unknown root is not forwarded, so unsigned chunk spam is filtered at the first hop.
slot and beacon_block_root are covered by neither the bid signature nor the inclusion proof, which is why the specification restricts them to routing lookups. The consistency checks in gossip validation bound their misuse: a chunk replayed with a divergent slot fails the (slot, payload_chunks_root) membership check, and a divergent beacon_block_root is rejected once the block containing the bid is known. Because the chunk bytes are proof-bound, a message that differs only in these hint fields cannot alter the reconstructed envelope.
Per-index equivocation is not possible: two distinct chunks that both verify at the same (payload_chunks_root, index) would imply a collision in the Merkle tree, so at most one chunk per index can propagate for a given commitment.
The chunk.index bound is load-bearing: is_valid_merkle_branch reads only the low CHUNK_INCLUSION_PROOF_DEPTH bits, so an unbounded index would let the same chunk propagate again at index + k * TOTAL_EXECUTION_PAYLOAD_CHUNKS.
Pre-block buffering is bounded: a node stores at most TOTAL_EXECUTION_PAYLOAD_CHUNKS chunks per entry in payload_chunks_roots, and the size of that set is itself limited by bid gossip validation (builder signature and slot window).
Gossip validity of a chunk does not imply validity of the reconstructed envelope; full envelope validation still happens after reconstruction, as under EIP-7732.
Copyright and related rights waived via CC0.