# Implementing Semantic Payload Chunking (EIP-8101) in CL While working on prototyping Semantic Payload Chunking (EIP-8101) in Prysm, I noticed several things that I would like to highlight in order to help other developers while implementing the EIP. It's worth noting that my work was based on Fulu fork, and a lot of things would change with Gloas and ePBS ([EIP-7732](https://eips.ethereum.org/EIPS/eip-7732)). ## Chunk Count In order for clients to know when validating individual Chunks and CALs (ChunkAccessLists) is finished, they need to have access to chunkCount. This is currently not part of the ExecutionPayload, but I think it should be. ## Block Body One of the main design questions is where in BlockBody to put Chunks and CALs. There are two most direcy ways of doing it: 1. Add two fields directly into BlockBody (`chunk_headers_root`, `chunk_access_lists_root`) containing commitments to chunks (contaning chunk header, transactions and withdrawals) and chunk access lists. 2. Add `chunks` field in the BlockBody. It is a list of `ChunkBundle` containers, each containing chunk header, transactions, withdrawals, chunk access lists. - Generating inclusion proofs for these objects is not as straight forward as in previous case, but it's doable It's worth mentioning that withdrawals, since present only in the last chunk, don't need to be included (they can be extracted from the State of the previous block). But this might complicate things a bit. ## Execution Payload validation Since Execution Payload no longer contains transaction, it can't be validated in the same manner as before. This would likely require larger refactoring. Once BeaconBlock is received (and `ExecutionPayloadHeader` with it), we can start validating and processing chunks and chunk access lists. Once they are validated, we can "finalize" the block and validate the entire execution. Only then can we consider the EL block valid. This might became simpler when done on top of ePBS ([EIP-7732](https://eips.ethereum.org/EIPS/eip-7732)), as some changes seem to be overlapping.
Last changed by  
 
milos.stankovic@ethereum.org
16

Read more

Payload Chunking

Multiple similar but different approaches are considered for Payload Chunking. The goal of this post is to explain differences, describe trade-offs and analyze how they interact with other EIPs. Motivation While there are many designs for payload chunking, they share some of the common properties: Instead of sending the entire block over the network, we split it in smaller chunks and send them separately Ideally, we would also like to be able to execute chunks as they arrive, even if they arrive out of order (aka chunk execution) In this simplified design, this allows us to go from this model of block propagation and execution (each unit is a block):

3/13/2026
Prototyping EIP-8101 (Semantic Payload Chunking)

Summary The proof of concept implementation of EIP-8101 was done in Geth and Prysm, on top of Fusaka fork. Running Devnet can be run with the following command: kurtosis run github.com/ethpandaops/ethereum-package \ --image-download always \ --args-file eip8101.config.yaml \ --enclave eip8101

3/3/2026
Implementing Semantic Payload Chunking (EIP-8101) in EL

While working on prototyping Semantic Payload Chunking (EIP-8101) in Geth, I noticed several things that I would like to highlight in order to help other developers while implementing the EIP. BAL vs CAL BlockAccessList needs very little modification in order to support ChunkAccessList use cases. In addition to already existing logic, we need to add following functionality: Tracing The AccessListTracer should for reads also keep track of the first tx that created the read. The reads shouldn't be removed if write happens in the later tx (but it's safe not to keep reads if write happened during the same or earlier tx). Buliding Chunk Access List (CAL) With the tracing modification and already existing data, we have enough data to build CAL. One just has to make sure that reads are removed from the CAL if there is a write inside the same chunk (or in any earlier chunk).

3/2/2026
Prototyping EIP-7782 (6 second slots)

Summary The basic implementation of EIP-7782 was built in Geth and Prysm on top of Fusaka fork. In order to run devnet, we modified several other projects: Genesis generator Kurtosis package Dora Devnet can be run with following command using kurtosis:

9/7/2025
Read more from milos.stankovic@ethereum.org
Published on HackMD