Original title:Ethereum All Core Developers Consensus Call #107 Writeup
Original title:
On April 20, 2023, Ethereum developers came together for the 107th Core Developers Consensus Conference Call (ACDC). ACDC is a bi-weekly conference series, moderated by Danny Ryan, a researcher at the Ethereum Foundation, where Ethereum developers discuss changes to the Ethereum Consensus Layer (CL), update progress around Deneb, and discuss What other proposals besides Ethereum EIP-4844 are included in the next Cancun upgrade.
Deneb Devnet #5
first level title
Since the successful activation in Shanghai on April 12, Ethereum developers have turned their attention to the preparations for Cancun for the first time. 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, the developers discussed the final scope of the Cancun/Deneb upgrade, which will center around EIP 4844, the implementation of the blob transaction type, and Deneb's readiness, starting with the launch of devnet #5.
Developers have launched multi-client testnets, also known as devnets, for EIP 4844 since last October. The fifth devnet for EIP 4844 will launch sometime next week, according to Tim Beiko, chair of the ACDE conference call. Paritosh Jayanthi, a DevOps engineer at the Ethereum Foundation, said he is running pilots for clients such as Ethereum JS (EL) and Lodestar (CL) in preparation for next week's devnet launch.
Among other things, there is a small change to the engine API that merges 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 will be done 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.ETHTokyoThe developers then discussed how to reinsert blob transactions into blocks in case of a chain reorganization. This question was asked by Geth (EL) developer Péter Szilágyi in hisPPTproposed in the presentation above (available at Szilágyi's
Find more information in ). Ryan said that due to the separate nature 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 transactions that bypass the mempool) is to have the CL pass each block's blob data to EL , then EL can cache it until the block is complete. Alternatively, the network could require users who submitted transactions that skip the mempool to resubmit their transactions in a chain reorganization event.
Szilágyi said he prefers the former, which is transferring blob data into EL so that transactions can be reinserted when reorganized, even transactions that bypass the mempool. In Szilágyi's view, this is not much additional load on the EL, and if the process becomes too cumbersome for a node to support, developers can tune the messages between EL and CL to lighten the load. “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 further breaks the abstraction between the EL and CL layers. Furthermore, this solution will enforce the assumption that nodes store complete data, which may be broken in future upgrades implementing Data Availability Sampling (DAS).
Due to the lack of participation from the EL client group, this question will be brought up again on the next ACDE conference call.
Deneb Add-Ons
first level title
In addition to EIP-4844, the Deneb upgrade also considered other code upgrades.
1. The first one is EIP-4788, which can expose the status of CL Beacon Chain in EL. This will allow smart contracts executing on EL to have trust-minimized access to CL, which is relevant for staking pools, restaking protocols, MEV, etc. Ethereum Foundation researcher Alex Stokes, one of the authors of the EIP, said the feature is a "lightweight" change to the CL. There was no objection to including EIP 4788 in Deneb on the call. Support for this EIP will be sought from the EL client team at the next ACDE conference call.
2. EIP-6914, this proposal can reuse validator numbers that have completely withdrawn from the network and have not been active for a period of time. This EIP will help reduce the infinite growth of the validator list as validators exit and new validators join the network. Stokes said that the complexity of EIP 6914 is relatively high, and code changes should be postponed until the next hard fork after Deneb. After discussing the complexities of EIP-6914, the developers agreed to continue honing in on the details of the code update, but leaving the final implementation until Deneb.
4、PR 3175 3. Ryan proposed a potential code change that involves backfilling data from the Beacon Chain genesis block and creating a new "historical summary" content. Details about this code change have not yet been specified in the EIP. Ryan agreed to contact the proposer of this change, Jacek Sieka (Head of Research Development at Status, who is building the Nimbus (CL) client) for more details.
, the proposal would prevent penalized validators from proposing blocks when dequeued. If more than 50% of validators are penalized for malicious behavior, those validators will still be able to propose blocks while being forcibly removed from the network. Ryan stated that changing this logic is a relatively small CL layer change that provides protection against "high failure modes".5. EIP-6493, which will address how nodes should handle blob transaction types that are formatted in SSZ on CL but encoded differently on EL. This EIP is part of updating the Ethereum serialization format to achieve cross-layer consistency. More background information on the Ethereum serialization format can be read previously。
developer records
