What else will the Cancun upgrade include besides EIP-4844?

On April 20, 2023, Ethereum developers gathered for the 107th Core Developer Consensus Call (ACDC). ACDC is a biweekly meeting series hosted by Ethereum Foundation researcher Danny Ryan. In this meeting, Ethereum developers discussed changes to the Ethereum Consensus Layer (CL), updated progress around Deneb, and discussed what proposals to include in the next Cancun upgrade in addition to Ethereum EIP-4844.

Deneb Devnet #5

Since the successful activation of Shanghai on April 12, Ethereum developers immediately turned their attention to the preparations for Cancun. Cancun is the name of the next upgrade of the Ethereum Execution Layer (EL), while Deneb is the name of the upgrade corresponding to CL. During the ACDE call, developers discussed the final scope of the Cancun/Deneb upgrade, which will be centered around EIP 4844, the implementation of the blob transaction type, and the preparations for Deneb, starting with the launch of devnet #5.

Developers have been launching multi-client test networks, also known as devnets, for EIP 4844 since October last year. Tim Beiko, chair of the ACDE call, said the fifth devnet for EIP 4844 will be launched sometime next week. Paritosh Jayanthi, a DevOps engineer at the Ethereum Foundation, said he is running test runs for clients such as Ethereum JS (EL) and Lodestar (CL) in preparation for the devnet launch next week.
Among them, there is a small change in the engine API, merging the "getPayload V3" and "getBlobsBundle V1" calls into one. Beiko emphasized that this change has not yet been merged into the EIP 4844 specification on GitHub, but it will be completed in the next few days so that the change can be tested on devnet #5. Beiko urged the client team to review this change as soon as possible.

Developers then discussed the issue of how blob transactions can be reinserted into blocks in the event of a chain reorganization. This issue was raised by Geth (EL) developer Péter Szilágyi in his presentation at ETHTokyo (more information can be found in Szilágyi’s PPT). Ryan said that due to the separation of blob transactions from regular transactions, reorganized blobs can only be obtained from transactions in the public mempool. Given that there are many transactions that bypass the mempool, namely MEV transactions and bundles, one way to guarantee that all blobs can be reconstructed (even those that bypass the memory pool) is to have the CL pass the blob data of each block to the EL, which can then cache it until the block is completed. Alternatively, the network can require users who submitted transactions that skipped the mempool to resubmit their transactions in the event of a chain reorganization.

Szilágyi said he prefers the former, which is to transfer the blob data into EL so that transactions can be reinserted when reorganizing, even transactions that bypass the memory pool. In Szilágyi's view, this is not a large additional load on EL, and if this process becomes cumbersome enough for nodes to support, developers can adjust the messages between EL and CL to reduce the burden. "The simplest solution is to provide the blob to the execution client when the consensus client sends a new payload." Szilágyi said. Ryan responded that while the proposed solution is simple, it will further undermine the abstraction between the EL and CL layers. In addition, the solution will strengthen the assumption that nodes store complete data, which may be broken in the future implementation of the Data Availability Sampling (DAS) upgrade.

Regarding the implementation of DAS, Szilágyi said that there will be other expectations around data availability that need to change in this upgrade, and suggested that developers "try to solve the problem then". Ryan agreed with him and asked other developers about the chain reorganization and blob transaction reinsertion situation. Gajinder Singh, developer of the Lodestar (CL) client, said that since MEV transactions are the most common type of bypassing the public memory pool, and MEV transactions are highly dependent on a specific chain state to execute, it is not important to delete them after a chain reorganization because the chain state has changed and the MEV transaction may need to be re-executed.

Due to the lack of EL client group participation, this issue was raised again at the next ACDE conference call.

Deneb Add-Ons

In addition to EIP-4844, the Deneb upgrade also considers other code upgrades.

1. The first is EIP-4788, which can expose the state of the CL Beacon Chain in EL. This will allow smart contracts executed on EL to have minimal trust access to CL, which is related to staking pools, re-staking agreements, MEV, etc. Alex Stokes, a researcher at the Ethereum Foundation and one of the authors of the EIP, said that the feature is a "lightweight" change to CL. No one in the conference call opposed the inclusion of EIP 4788 in Deneb. The EL client team will be asked to support this EIP at the next ACDE conference call.

2. EIP-6914, which allows validator index numbers that have completely exited the network and have been inactive for a while to be reused. This EIP will help reduce the unlimited growth of the validator list as validators exit and new validators join the network. Stokes said that EIP 6914 is relatively complex and code changes should be postponed until the next hard fork after Deneb. After discussing the complexity of EIP-6914, developers agreed to continue to hone in on the details of the code update, but leave the final implementation until after Deneb.

3. Ryan proposed a potential code change that involves backfilling data from the Beacon Chain genesis block and creating new "historical summary" content. The details of this code change have not yet been specified in the EIP. Ryan agreed to contact the proposer of this change, Jacek Sieka (Status R&D Leader, who is building the Nimbus (CL) client) for more details.
4. PR 3175, which will prevent punished validators from proposing blocks when they exit the queue. If more than 50% of validators are punished for malicious behavior, these validators will still be able to propose blocks while being forcibly expelled from the network. Ryan said that changing this logic is a relatively small CL layer change that can provide protection against "high failure modes."

5. EIP-6493, which will address how nodes should handle blob transaction types that are formatted in SSZ format on CL but encoded differently on EL. This EIP is part of updating the Ethereum serialization format to achieve cross-layer consistency. For more background information on the Ethereum serialization format, read the previous developer record.

In Deneb-wide discussions, developers are leaning towards including EIP-4788, EIP-3175, and EIP-4844 in the next upgrade.