# 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: ```console kurtosis run github.com/ethpandaops/ethereum-package \ --image-download always \ --args-file eip8101.config.yaml \ --enclave eip8101 ``` Where `eip8101.config.yaml` is given below: ```yaml participants: - el_type: geth el_image: morphdev1803/geth:eip8101 cl_type: prysm cl_image: morphdev1803/prysm-beacon-chain:eip8101 vc_type: prysm vc_image: morphdev1803/prysm-validator:eip8101 count: 5 network_params: genesis_delay: 20 electra_fork_epoch: 0 fulu_fork_epoch: 0 gloas_fork_epoch: 1 additional_services: - tx_fuzz snooper_enabled: true ``` ### Fork logic The fork used to triger the logic is Gloas, but other than EIP-8101, it doesn't have any additional eip (part of the Block Access List logic is implemented on EL side). Since this is unorhtodox fork, kurtosis can't be created with this fork enabled on genesis. Instead fork has to happen later (e.g. epoch 1). At the moment of writting, several components are not fully implemented: - synching doesn't work - blobs, withdrawals and execution requests weren't tested - dora and other tools likely don't work ## Complexity ### EL client - low/medium complexity Overall, I would classify changes in EL client (assuming BAL is implemented) as low/medium complexity. Some of the main changes: - creating CALs is not very different from creating BAL (we need to keep track of one or two more things) - BAL already allows independant tx execution, so executing chunks is simple - new logic for keeping track of which parts of the block were received, processed and their statuses - new logic that triggers once some conditions are met - start calculating StateRoot when all CALs are received - once all chunks are validated, confirm that together they make a valid block - additional complexity might arise when non-implemented functionality is added (e.g. synching, reverts, etc.) Branch: https://github.com/morph-dev/go-ethereum/tree/eip8101 Detailed writing on changes is available [here](https://notes.ethereum.org/@miloss/eip8101_el). ### CL client - medium complexity Since prototype is built on top of Fulu, and Gloas introduces `BeaconBlockBody` structure and slot timing changes, it's hard to accurately evaluate the complexity if Semantic Payload Chunking is added to the protocol in the future. Implemented prototype could be considered as medium/high complexity. Because **ePBS** removes `ExecutionPayload` from `BeaconBlockBody` (it's replaced with `ExecutionPayloadBid`), it should be simpler to implement Semantic Payload Chunking on top of Gloas, than it was for prototype. CL client has to primarily: - keep track of CALs and chunks that were received, their validity and timing - orchestrate calls to EL client, e.g. - CL should wait with engine API call to verify chunk until all prior CALs are received - validate and propagate CALs and chunks independently on the networking layer Overall, if built on top of **ePBAS**, I would consider implementation complexity as medium. Branch: https://github.com/morph-dev/prysm/tree/eip8101 Detailed writing on changes is available [here](https://notes.ethereum.org/@miloss/eip8101_cl).