What other proposals will be included in the Cancun upgrade besides the highly anticipated EIP4844

Title of the original article:
Ethereum All Core Developers Consensus Call #107 Writeup
Author of the original article: Christine Kim (some deletions in translation)
On April 20, 2023, Ethereum developers gathered for the 107th All Core Developers Consensus Call (ACDC) meeting. ACDC is a bi-weekly meeting series hosted by Ethereum Foundation researcher Danny Ryan. During this meeting, Ethereum developers discussed modifications to the Ethereum Consensus Layer (CL), updated progress around Deneb, and discussed which proposals, other than Ethereum EIP-4844, are included in the upcoming Cancun upgrade.
Table of contents
Toggle
Deneb Devnet #5
Deneb Add-Ons
Since the successful activation in Shanghai on April 12, Ethereum developers have shifted their focus to preparing for Cancun. Cancun is the name of the next upgrade for the Ethereum Execution Layer (EL), while Deneb is the upgrade name corresponding to CL. During the ACDC call, developers discussed the final scope of the Cancun/Deneb upgrade, centered around EIP 4844, the implementation of blob transaction types, and the preparation of Deneb starting with the release of devnet #5.
Since October of last year, developers have initiated multi-client test networks for EIP 4844, also known as devnets. ACDC call chair Tim Beiko stated that the fifth devnet for EIP 4844 will be launched sometime next week. Ethereum Foundation DevOps engineer Paritosh Jayanthi mentioned that he is preparing for the release of devnets next week by running trials for Ethereum JS (EL) and Lodestar (CL) clients.
One small change in the Engine API combines the “getPayloadV3” and “getBlobsBundleV1” calls into one. Beiko emphasized that this change has not been merged into the EIP 4844 specification on GitHub yet, but it will be completed in the next few days for testing on devnet #5. Beiko urged client teams to review this change promptly.
Developers then discussed the issue of reintroducing blob transactions into blocks during chain reorganizations. 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 stated that due to the nature of blob transactions being separate from regular transactions, reorganized blobs can only be obtained from transactions in the public mempool. Considering many transactions bypass the mempool, such as MEV transactions and bundles, a method to ensure all blobs can be reconstructed was discussed, which involves CL passing blob data for each block to EL, allowing EL to cache it until the block is completed. Alternatively, the network can request users who submitted transactions bypassing the mempool to resubmit their transactions during chain reorganization events.
Szilágyi expressed a preference for the former solution of transmitting blob data to EL for reinsertion of transactions during reorganizations, even those bypassing the mempool. In his view, this would not impose a significant additional burden on EL, and if the process becomes burdensome to the point where nodes cannot support it, developers can adjust the messages between EL and CL to ease the load. “The simplest solution is for the consensus client to provide the blob to the executing client when sending a new valid payload,” Szilágyi said. Ryan responded that while the proposed solution is simple, it would further disrupt the abstraction between EL and CL layers. Additionally, this solution would reinforce the assumption of nodes storing complete data, which may be broken in the future with the implementation of the Data Availability Sampling (DAS) upgrade.
Regarding the implementation of DAS, Szilágyi noted that there are other expected changes in data availability in this upgrade and suggested developers “solve the problem when the time comes.” Ryan agreed with his view and asked other developers for their opinions on chain reorganizations and the reinsertion of blob transactions. Gajinder Singh, a developer of the Lodestar (CL) client, mentioned that since MEV transactions are the most common type bypassing the public mempool and heavily rely on specific chain states for execution, it may not be crucial to delete them after chain reorganizations since the chain state has already changed, and MEV transactions may need to be re-executed.
Due to the absence of EL client team participation, this issue will be raised again at the next ACDC call.
In addition to EIP-4844, the Deneb upgrade also considers other code upgrades.
1. The first is EIP-4788, which allows the CL Beacon Chain state to be exposed in EL. This will enable smart contracts running on EL to minimally trust access to CL, which is relevant to staking pools, re-staking protocols, MEV, and more. Ethereum Foundation researcher Alex Stokes, one of the authors of EIP, stated that this feature is a “lightweight” change for CL. No one opposed the inclusion of EIP 4788 in Deneb during the call, and feedback on supporting this EIP will be sought from the EL client team at the next ACDC call.
2. EIP-6914, which proposes reusing validator indices that have been completely exited from the network and inactive for some time. This EIP will help reduce the infinite growth of the validator list during the process of validators exiting and new validators joining the network. Stokes mentioned that the complexity of EIP 6914 is relatively high, and code changes should be postponed to a subsequent hard fork after Deneb. After discussing the complexity of EIP-6914, developers agreed to continue refining the details of the code updates but leave the final implementation to after Deneb.
3. Ryan proposed a potential code change involving backfilling data from the Beacon Chain genesis block and creating new “historical summaries.” Details about this code change have not been specified in the EIP. Ryan agreed to reach out to Jacek Sieka, the proposer of this change and lead developer at Status Research, who is building the Nimbus (CL) client, for more information.
4. PR 3175, which will prevent penalized validators from proposing blocks when exiting the queue. If more than 50% of validators are penalized for malicious behavior and are forcibly expelled from the network, these validators can still propose blocks. Ryan stated that changing this logic is a relatively minor CL layer change that can provide protection against “high fault modes.”
5. EIP-6493, which addresses how nodes should handle blob transaction types formatted in SSZ on CL but encoded differently on EL. This EIP is part of updating Ethereum’s serialization format to achieve cross-layer consistency. More background information on Ethereum’s serialization format can be found in previous developer logs.
In discussions about the scope of Deneb, developers leaned towards including EIP-4788, EIP-3175, and EIP-4844 in the next upgrade.