Ethereum All Core Developers Consensus Call #107 Writeup
On April 20, 2023, Ethereum developers gathered for their 107th All Core Developers Consensus (ACDC) call. Chaired by Ethereum Foundation Researcher Danny Ryan, the ACDC calls are a bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. This week, developers gave updates on their progress around Deneb and discussed what other code changes in addition to Ethereum Improvement Proposal (EIP) 4844 should be included in Ethereum’s next upgrade.
Deneb Devnet #5
Since the successful activation of Shanghai last Wednesday, on April 12, Ethereum developers have wasted no time switching their focus on preparations for Cancun. As background, Cancun is the name for the next upgrade on the execution layer (EL) of Ethereum while Deneb is the corresponding upgrade name for the CL. Last week, during ACDE call 159, developers began discussing the final scope of the Cancun/Deneb upgrade which will be centered around EIP 4844, the implementation of blob transaction types. This week, after a brief acknowledgement around the success of Shanghai, developers promptly moved on to discussing preparations for Deneb, starting with the launch of devnet #5.
Since as early as October, developers have launched multi-client test networks, also called devnets, for EIP 4844. Tim Beiko, chair of the ACDE calls, said that the fifth devnet for EIP 4844 will be launched sometime next week. Paritosh Jayanthi, a DevOps Engineer for the Ethereum Foundation, said that he is in the process of doing trial runs for clients like Ethereum JS (EL) and Lodestar (CL) to prepare them for the devnet launch next week.
There is a minor change to the Engine API that merges the “getPayloadV3” and “getBlobsBundleV1” calls into one. Beiko emphasized that this change has not yet been merged into specifications for EIP 4844 on GitHub but will be in the next few days so that the change can be live for testing on devnet #5. Beiko urged client teams to review the change as soon as possible.
Developers then discussed concerns around how blob transactions should be reinserted into blocks in the event of a chain reorganization. This issue was raised by Geth (EL) developer Péter Szilágyi during a presentation he gave at ETHTokyo. Slides from Szilágyi’s presentation can be found here. Ryan said that due to the decoupled nature of blob transactions from regular transactions, reconstructions of blobs after a chain reorg may only be available from transactions seen in the public mempool. Given that there are plenty of transactions that bypass the mempool, that is MEV transactions and bundles, one way to guarantee all blobs can be reconstructed even the ones that bypass the mempool is to have the CL pass along blob data for every block to the EL, which the EL can then cache until block finalization. Alternatively, the network could simply require users that have submitted transactions bypassing the mempool to resubmit their transactions in the event of a chain reorg.
Szilágyi said that his preference was for the former, to have the blob data communicated to the EL so that in the event of a reorg transactions can be reinserted, even the transactions that bypass the mempool. In Szilágyi’s view, the additional load on the EL is not large and if the process becomes rather excessive for nodes to support, developers can tweak the message between the EL and CL to lighten the load. “The simplest solution would be for consensus clients to give the blobs to execution clients essentially when they send a new payload,” said Szilágyi. Ryan responded saying that while the proposed solution was simple it would further break down the abstraction between the EL and CL layers. In addition, the solution would reinforce the assumption that nodes will store full copies of blob data, which may be an assumption that is broken in a future upgrade implementing data availability sampling (DAS).
About the implementation of DAS, Szilágyi said that there would be other expectations around data availability that would have to change anyways for this upgrade and recommended that developers “try to cross that bridge once we get there.” Ryan agreed and asked what other developers thought around the edge case of chain reorgs and blob transaction reinsertions. Gajinder Singh, a developer for the Lodestar (CL) client, said that since MEV transactions are the most common type that bypass the public mempool and the execution of MEV transactions are highly dependent on a specific chain state, dropping then after a chain reorg would not matter since the chain state will have changed and MEV transactions will likely need to be re-executed anyways.
Due to the lack of EL client team representation on the call, Ryan recommended surfacing this issue again during next week’s ACDE call. Szilágyi agreed to continue thinking on this topic in light of MEV activity and future upgrades like DAS.
In addition to EIP 4844, there are a handful of other code changes under consideration for the Deneb upgrade.
The first is EIP 4788, which exposes the CL Beacon Chain state in the EL. This will allow for trust-minimized access to the CL by smart contracts executed on the EL, which is relevant for staking pools, restaking protocols, MEV mitigations, and more. Ethereum Foundation researcher Alex Stokes who is one of the authors of the EIP said that the feature is a “lightweight” change to the CL. No one on the call was opposed to including EIP 4788 in Deneb. Ryan said that he would get a temperature check on support for the EIP from EL client teams on the next ACDE call.
The next EIP developers discussed for Deneb was EIP 6914, which would reuse the validator index numbers of validators that have fully exited the network and have not been active for some time. This EIP would help reduce the unbounded growth of the validator list, as validators exit and new validators join the network. Stokes said that the complexity of EIP 6914 is enough to make him think the code change should be pushed to the next hard fork after Deneb. A developer from the Lighthouse (CL) client team who goes by the pseudonym “realbigsean” agreed that the EIP was useful but not urgent for the next upgrade. After some more discussion around the complexities of EIP 6914, developers agreed to continue hammering out the details of the code change but leave its implementation for a hard fork after Deneb.
Ryan then raised a potential code change around backfilling data from Beacon Chain genesis and creating new “historic summaries.” The details around this code change have yet to be specified in a pull request or EIP. Ryan agreed to link up with the proposer of this change, Jacek Sieka, Head of Research Development at Status who is building the Nimbus (CL) client, for more details.
Then developers discussed PR 3175, which would prevent slashed validators from proposing blocks while in the exit queue. In the event where more than 50% of validators are slashed for malicious behavior, these validators would still be able to proposer blocks while being forcefully ejected from the network. Changing this logic is a relatively minor change from the CL layer that provider protection against “a high failure mode,” said Ryan. Realbigsean was in favor of including it in Deneb. Enrico Del Fante from the Teku (CL) client team was also in favor.
Finally, Etan Kissling, a developer of the Ethereum Nimbus (CL) client team, urged developers to consider EIP 6493 which would address how nodes should handle blob transaction types formatted in SSZ on the CL but encoded differently on the EL. This EIP is part of a larger push to update Ethereum’s serialization formats for consistency across layers. Kissling did mention that EIP 6493 primarily impacts the EL and so Ryan suggested they raise the topic again on next week’s ACDE call. For more context around Ethereum serialization formats, read prior developer call notes here.
From this discussion on Deneb scope, developers were most keen on including EIP 4788 and 3175 alongside EIP 4844.
Moving on from discussions around Deneb, Ryan raised a pending change in the Engine API that was proposed last week by Mikhail Kalinin from the Teku (CL) client team. The change was prompted by a bug initially discovered in the Nimbus/Besu (CL/EL) client combination but also impacting other clients such as the Nethermind (EL) client. The proposed change clarifies logic around stating block payload IDs as unique values for each instance of the “payloadattributes” field. For more information on this change, read the GitHub pull request here. Developers plan on merging the change to Engine API specifications on GitHub over the next few days.
During the last ACDC call, developers discussed creating a standardized RPC endpoint for nodes to validate blinded blocks. Blinded blocks refer to blocks where the transaction contents cannot be seen. Realbigsean said that he was still in support of the standardization of this endpoint across clients and would work on creating formal specifications for its implementation.
Then, developers discussed revamping Beacon Chain attestation subnets (attnets). Attnets help connect validators to the Beacon Chain so that they can quickly publish and propagate their attestation messages. There is a concern that validators are oversubscribed to attnets, which is resulting in significant bandwidth use. To reduce the density of attnets and help prevent unnecessary information leaks about validating nodes, Adrian Manning from the Lighthouse (CL) client team has proposed a solution for subscribing validator nodes to long-lives attnets. The full details of Manning’s proposal can be read here. Manning explained that the change does not have to be executed through a hard fork. CL client teams can implement the change ad hoc over time. Ryan and Manning called for more eyes reviewing the changes proposed to Beacon Chain attnets.
Guillaume Ballet, a Geth developer for the Ethereum Foundation, who is working on research around migrating Ethereum data structures away from Merkle Patrica trees to Verkle trees, raised a cosmetic change to create a number field in the JSON of the execution payload. Ballet said that his main motivation for creating this field would be to avoid using hex strings for numbers, which is “wasteful,” and instead use regular JSON numbers. Developers did not have a strong opinion around this change. Ryan encouraged Ballet to create a pull request on GitHub to get more feedback on his proposal.