EIP-8101: Payload Chunking with Chunk Access Lists

Abstract

---

This EIP introduces Payload Chunking, a protocol upgrade that restructures Ethereum block propagation into self-contained execution chunks with separated Chunk Access Lists (CALs). The proposer propagates beacon and execution payload headers, followed by CALs and chunks as independent network messages. CALs contain state diffs from chunk execution, enabling parallel chunk validation: chunk N can be validated once CALs 0..N are available. After all chunks validate successfully, the consensus layer finalizes the block. This architecture transforms block validation from a monolithic operation into a streaming pipeline while preserving block atomicity. Chunks exist only as a propagation and validation construct; the canonical chain stores complete execution payloads.

Motivation

---

As Ethereum's gas limit increases, block sizes and execution complexity grow correspondingly. The current monolithic block structure requires validators to download and decompress the entire execution payload before beginning execution, creating a bottleneck in the consensus timeline. This sequential dependency—download, decompress, then execute—becomes increasingly problematic as blocks grow larger.

This proposal addresses these constraints by:

• Parallel propagation: Nodes propagate parts of the block separately, improving propagation speed through the network
• Streaming validation: Execution begins as chunks arrive rather than after full payload receipt
• Parallel chunk execution: CALs provide state diffs enabling independent validation of chunks
• Bounded resources: Per-chunk gas limits (CHUNK_GAS_LIMIT = 2**24) bound memory and CPU per validation unit
• Early rejection: Invalid blocks can be rejected at the first invalid chunk without processing remaining chunks
• Proving compatibility: Chunk boundaries create natural proving units for future ZK proving systems

Specification

---

Constants

Name	Value	Description
CHUNK_GAS_LIMIT	2**24 (16,777,216)	Maximum gas per chunk, from EIP-7825
MAX_CHUNKS_PER_BLOCK	2**8 (256)	Maximum chunks per block
MAX_TRANSACTIONS_PER_CHUNK	2**16 (65,536)	Maximum transactions per chunk
CHUNK_INCLUSION_PROOF_DEPTH	floorlog2(get_generalized_index(BeaconBlockBody, 'chunk_headers_root')) + 1 + ceillog2(MAX_CHUNKS_PER_BLOCK) (13)	SSZ Merkle proof depth for message inclusion
MAX_CAL_SIZE	2**24 (16,777,216)	Maximum size in bytes of RLP-encoded CAL

Type Aliases

Data Structures

Execution Chunk

Chunk Access Lists (CALs)

CALs are RLP-encoded structures following the Block Access List format from EIP-7928, scoped to individual chunks. Each CAL records state diffs produced by executing its corresponding chunk.

Type Definitions:

Change Structures:

CAL Properties:

1. Incremental: Each CAL contains only the state diffs from its chunk. Changes from earlier chunks are not repeated.
2. Independent: CALs can be validated independently given the pre-state.

System Contract Entries:

• First CAL (chunk 0): Includes pre-execution system writes (EIP-2935 block hash history, EIP-4788 beacon root)
• Last CAL (chunk N-1): Includes post-execution system operations (EIP-4895 withdrawals, EIP-7002 and EIP-7251 validator operations)

ExecutionPayload and ExecutionPayloadHeader

The ExecutionPayload is no longer used and is replaced by ExecutionPayloadHeader.

The ExecutionPayloadHeader is modified to include number of chunks in a block:

Beacon Block Commitments

The beacon block body replaces execution_payload with execution_payload_header and includes two Merkle roots committing to chunks and CALs:

Note: If EIP-7732 (ePBS) is enabled, then execution_payload field of ExecutionPayloadEnvelope is replaced by execution_payload_header in the same way.

Commitment construction:

Note: The EL uses keccak256(RLP(CAL)) in chunk headers per EIP-7928. The CL uses SSZ hash_tree_root for inclusion proofs. Both reference the same RLP-encoded CAL data.

Network Topis

Chunks and CALs propagate as separate network message with SSZ Merkle inclusion proofs against the beacon block header.

The signed_block_header provides the proposer signature for authentication and the beacon block root for proof verification.

Chunk Construction Rules

Block producers MUST follow these rules when constructing chunks:

1. Gas Bound: Each chunk MUST satisfy gas_used <= CHUNK_GAS_LIMIT
2. Minimal Chunking: For any two consecutive chunks i and i+1, their combined gas MUST exceed CHUNK_GAS_LIMIT. This ensures chunks cannot be trivially merged, preventing unnecessary fragmentation.
3. Transaction Atomicity: Transactions MUST NOT be split across chunks. Each transaction belongs entirely to one chunk.
4. Withdrawal Placement: Withdrawals MUST appear only in the final chunk. All other chunks have empty withdrawal lists.
5. Chunk Count Bound: A block MUST contain at most MAX_CHUNKS_PER_BLOCK chunks
6. Sequential Indexing: Chunks MUST be indexed sequentially from 0 to N-1 where N is the total chunk count

Network Protocol

Gossip Topics

Chunks and CALs propagate on dedicated gossip topics:

Topic	Payload
execution_chunk	ExecutionChunkMessage
chunk_access_list	ChunkAccessListMessage

Message Validation

Nodes MUST validate messages before forwarding:

ExecutionChunkMessage validation:

1. Verify signed_block_header.signature is valid for the proposer at the given slot

2. Verify chunk.chunk_header.index < MAX_CHUNKS_PER_BLOCK

3. Verify chunk.chunk_header.gas_used <= CHUNK_GAS_LIMIT

4. Verify hash_tree_root(chunk.transactions) == chunk.chunk_header.txs_root

5. Verify inclusion proof:

ChunkAccessListMessage validation:

1. Verify signed_block_header.signature is valid for the proposer at the given slot

2. Verify chunk_index < MAX_CHUNKS_PER_BLOCK

3. Verify len(chunk_access_list) <= MAX_CAL_SIZE

4. Verify inclusion proof:

Nodes MUST subscribe to chunk and CAL topics. Messages may be validated immediately using the signed block header without waiting for the full beacon block.

Consensus Layer Changes

The consensus layer orchestrates chunk validation as beacon blocks, chunks, and CALs arrive from the network.

Types

Store Extensions

Three-Phase Validation

Phase 1: CAL Reception

CALs are forwarded to the execution layer upon receipt. The EL caches CALs for use in subsequent chunk validation.

Phase 2: Chunk Validation

Chunks are validated as they arrive, provided all prerequisite CALs (indices 0 through N for chunk N) are available.

Phase 3: Block Finalization

Once all chunks have been validated, the block is finalized by verifying chunk chaining and aggregate consistency.

Attestation Rules

Validators MUST NOT attest to a block until:

1. All chunks have been received and individually validated (Phase 2 complete)
2. Block finalization has succeeded (Phase 3 complete)

ePBS Integration (EIP-7732): PTC (Payload Timeliness Committee) members attest to chunk and CAL data availability. PTC attestations are independent of execution validity—they confirm only that all messages were received within the timeliness window.

Execution Layer Changes

Chunk Execution

The execution layer validates chunks independently. For chunk N, the EL applies CALs 0..N-1 to the parent block state to reconstruct the chunk's pre-state, then executes the chunk transactions. It uses CAL N to execute transactions in parallel (the same as in EIP-7928).

Engine API

Four new Engine API methods support chunked validation:

engine_newBlockHeaderV1

Replaces engine_newPayloadV5. Informes EL that new block is available and passes block data, except CALs and chunks. Must be called first, as other calls depend on this data.

Parameters:

• payload_header: ExecutionPayloadHeader
• beaconRoot: Hash32
• blobHashes: List[Hash32]
• executionRequests: List[Bytes]

Returns: PayloadStatusV1

engine_newChunkAccessListV1

Caches a CAL for subsequent chunk execution. Requires block data to have been sent via engine_newBlockHeaderV1.

Parameters:

• blockHash: Hash32 - The block hash
• chunkIndex: ChunkIndex - Index of the chunk this CAL corresponds to
• chunkAccessList: ChunkAccessList - RLP-encoded chunk access list

Returns: PayloadStatusV1

engine_executeChunkV1

Executes and validates a chunk. Requires block data to have been sent via engine_newBlockHeaderV1, and all prerequisite CALs (indices 0 through N) to have been sent via engine_newChunkAccessListV1.

Parameters:

• blockHash: Hash32 - The block hash
• chunk: ExecutionChunk - The chunk to execute

Returns: PayloadStatusV1

engine_finalizeBlockV1

Finalizes block validation after all chunks have been executed. Verifies:

• Chunk headers chain correctly: chunk N's pre_chunk_* fields equal chunk N-1's cumulative values
• Final state root matches payload_header.state_root
• All block header fields are valid

Parameters:

• blockHash: Hash32 - Hash of the execution payload

Returns: PayloadStatusV1

Response Types

All new Engine API methods return PayloadStatusV1 type, but status field has different meaning and values depending on the method. Following table defines all possible values and when they can be used.

Status	Semantics	newBlockHeader	newChunkAccessList	executeChunk	finalizeBlock
ACCEPTED	BlockHeader/CAL accepted successfully	✅	✅
VALID	Chunk/block executed correctly			✅	✅
INSUFFICIENT_INFORMATION	Missing prerequisite CALs			✅
INVALID	Execution or validation failed	✅	✅	✅	✅
SYNCING	Parent state not available (node syncing)	✅	✅	✅	✅

The error field is present if status is INSUFFICIENT_INFORMATION or INVALID.

Rationale

---

Incremental CALs

Chunk N applies CALs 0..N-1 to the parent state to reconstruct its pre-state. This incremental approach provides:

1. Parallel Execution: Multiple chunks can execute concurrently once their prerequisite CALs arrive. Alternative designs where each CAL contains cumulative state diffs would cause CAL sizes to grow linearly with chunk count, creating worst-case bandwidth issues.
2. Early Rejection: Invalid chunks cause immediate block rejection without processing subsequent chunks.
3. Bounded Resources: Each chunk validation is independently bounded by CHUNK_GAS_LIMIT.

CL-Driven Architecture

The consensus layer orchestrates chunk execution because:

1. Consistency: Existing CL-EL interaction follows CL-driven patterns (e.g., engine_newPayload).
2. Global View: The CL tracks which CALs have arrived from gossip and can optimally schedule chunk execution based on availability.
3. Dependency Enforcement: The CL ensures chunks execute only when prerequisites are satisfied.
4. Timeliness Tracking: The CL determines whether messages arrived within attestation deadlines.

Separate CAL Propagation

Decoupling CALs from chunks provides:

1. Faster Propagation: CALs (kilobytes of state diffs) propagate faster than chunks (megabytes of transactions), enabling earlier execution starts.
2. Parallelization: Chunks can execute independently by applying prior CALs to reconstruct pre-states.
3. State reads: CALs allow us to start reading required state from db before transactions arrive.
4. StateRoot calculation: EL can start calculating state root as soon as all CALs are received.
5. Extensibility: CALs can be extended with proving metadata without modifying chunk structure.

Semantic Chunking

Semantic chunking (transaction-aligned boundaries with gas limits) differs from byte-level fragmentation:

1. Streaming Validation: Each chunk is a complete execution unit validatable upon receipt.
2. Resource Bounds: Gas limits bound per-chunk memory, CPU, and proving costs.
3. Transaction Integrity: No transaction splitting simplifies execution semantics.

Parameter Selection

Parameter	Value	Rationale
CHUNK_GAS_LIMIT	2^24 (~16.7M)	Balances parallelization granularity with per-chunk overhead. Large enough for complex transactions, small enough for bounded ZK proving circuits.
MAX_CHUNKS_PER_BLOCK	256	Supports ~4 Ggas blocks (256 × 16M). Conservative upper bound accommodating future gas limit increases.
MAX_TRANSACTIONS_PER_CHUNK	2^16 (65,536)	Accommodates chunks filled with minimal-gas transactions (ETH transfer - 21,000 gas) with margin for future gas cost reductions.

Backwards Compatibility

---

This EIP introduces breaking changes requiring a coordinated hard fork:

Component	Change
Block Propagation	Execution payloads propagate as chunk and CAL messages instead of monolithic payloads
Network Protocol	New gossip topics for ExecutionChunkMessage and ChunkAccessListMessage
Engine API	Four new methods: engine_newBlockHeaderV1, engine_newChunkAccessListV1, engine_executeChunkV1, engine_finalizeBlockV1
Validation	Three-phase validation (CAL reception, chunk validation, block finalization)

Post-fork, nodes must implement chunked validation to participate in consensus. Historical blocks remain unaffected.

Security Considerations

---

Data Availability Attacks

Chunk separation introduces new attack surfaces:

Attack	Description	Impact	Mitigation
Chunk Withholding	Builder publishes some chunks but withholds others	Block unvalidatable; attestation deadline missed	Attestation rules require all chunks; PTC votes on availability
CAL Withholding	Builder publishes chunks but withholds CALs	Streaming execution blocked; falls back to sequential	CALs reconstructible by sequential chunk execution
Reverse Propagation	Builder sends chunks/CALs in reverse order (N→0)	No parallel execution until chunk 0 and CAL 0 arrive	Rational builders propagate in order for faster attestations

Copyright

---

Copyright and related rights waived via CC0.