skip to content

Ethereum All Core Developers Consensus Call #104 Writeup

Ethereum All Core Developers Consensus Call -104 Writeup

On March 9, 2023, Ethereum developers gathered for their 104th All Core Developers Consensus (ACDC) call. Chaired by the Ethereum Foundation’s Danny Ryan, the ACDC calls are a bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the consensus layer of Ethereum. This week, developers discussed preparations for Capella, Deneb, and Electra.


As background, upgrades to the consensus layer (CL) of Ethereum are named alphabetically after stars in major constellations. This naming convention started with the first upgrade on the Beacon Chain which was called Altair. The second upgrade was called Bellatrix and Capella is the name for the Beacon Chain’s third upgrade, which will be activated simultaneously with the Shanghai upgrade on the execution layer (EL) of Ethereum.

Shanghai/Capella, sometimes referred to by Ethereum developers as Shapella, will be activated on the Goerli test network on March 14, 2023. Tim Beiko said that the official blog post announcing this upgrade was released on the Ethereum Foundation’s website on March 8, 2023. The post features the latest software releases from all client teams, except the Nimbus (CL) team. The Nimbus team said they would put out a release for the Goerli testnet in less than 24 hours on March 9th and Beiko agreed to update the blog post to feature the latest Nimbus release once its published.

Beiko also mentioned that the second community call for the Shapella upgrade had been scheduled for March 13, 2023, a day before the activation of the upgrade on Goerli. These community calls are meant to be a resource for Ethereum community members to ask questions about the upgrade and learn how they will be impacted by upcoming code changes to the Ethereum protocol. Speaking of community-focused initiatives to raise awareness about the upcoming Shapella upgrade, Beiko highlighted that the ETHStaker project will be hosting a livestream for the public to watch the Goerli upgrade in real-time.

Teku developer Ben Edgington asked whether developers plan on spamming the network with a large number of BLS withdrawal credential changes at the time of the Goerli upgrade to help test network functionality for processing a high volume of credential changes and thereby mimic what will likely happen during mainnet activation of Shapella. Paritosh Jayanthi, a DevOps Engineer for the Ethereum Foundation, said there were no plans to do this and that this type of activity had already been tested on prior testnets, where developers did not find any issues with how the network processed credential changes. For context of what BLS withdrawal credential changes are, read this Galaxy Research report.

Prysm developer Terence Tsao mentioned he had a few questions about the readiness of MEV builders and relays for the Goerli upgrade. However, he said that he would raise his concerns on the MEV Boost community call which had been scheduled for shortly after the ACDC call this week. Full recording of the latest MEV-Boost community call and agenda can be found here. On the topic of MEV Boost testing, Jayanthi said that the circuit breaker functionality for clients, that is the fall back mechanism to local block production in the event that MEV boost software fails, had been tested on a prior mainnet shadow fork and confirmed they were working.


Moving on to discussions about Deneb, the fourth upgrade to the CL of Ethereum, which will be activated after Cancun and focus on the implementation of EIP 4844, a developer from the Lighthouse (CL) client team who goes by the pseudonym “realbigsean” gave an update on changes to the Beacon Chain API for blob signing. Blobs are a new type of transaction that will be introduced in the Deneb upgrade which is optimized for settling and temporarily storing Layer-2 transaction data. According to Sean, the thinking of developers around the workflow for signing blob transactions and propagating them to other nodes on the network was to make all blobs blinded by default, meaning nodes would not be able to see the entirety of transaction data contained in a blob immediately. As explained by Jim McDonald, CTO of Attestant, in a discussion thread about blob signing endpoints, “Blinded [blobs] introduce state in the [block] proposal process, with the beacon node holding back information and responding with a ‘promise’ that the full data will be made available at a future date.”

Holding back information about a block is a key functionality that is already used in the design of Ethereum today in order to support MEV-Boost software. Validators commit to a block from a third-party block proposer without knowing the full details of the contents of the block they are receiving. Similarly, there is a need for blinding information about the contents of blobs until the block in which the blob is contained has been proposed and finalized on-chain. However, as discussed by developers, there are advantages to unblinding blob data at certain points in the blob signing workflow. McDonald adds: “Blinding the blob data would reduce the reliability of the network, unless the blinded data was available from an independent source. Even then, it would be preferable to provide unblinded information wherever possible to keep state within the proposing entity, that is the validator client.”

Danny Ryan suggested that Sean open a new GitHub issue summarizing the latest thinking around blob signing endpoints for merging and testing as part of the larger Deneb code specifications. Related to planning for Deneb, Nimbus developer Etan Kissling gave an update on his efforts around upgrading Ethereum’s data structures to an SSZ serialization format. For more background on this issue, read prior Ethereum developer call notes here. Kissling said that he would raise this issue as an agenda item on next week’s ACDE call. Finally, a Nimbus developer who goes by the pseudonym of “arnetheduck” requested comments and feedback on a pull request (PR) he created on GitHub to address a recurring problem when validating blocks and attestations. The full PR can be read here.


Guillaume Ballet, a Geth developer for the Ethereum Foundation, presented early specifications for the upgrade after Deneb, which will focus on a major improvement to Ethereum data structures sometimes called “the Verge.” At present, data about Ethereum accounts, transactions, and the blockchain state as a whole are stored using a structure known as the Merkle Patricia tree. The Merkle Patricia tree data structure allows users to easily verify a large amount of data by relying on a single cryptographic proof, representing the root of the tree. A Verkle tree data structure functions similarly to Merkle Patricia trees, however, they are “much more efficient in proof size,” according to a blog post by Vitalik Buterin. Buterin writes, “If a tree contains a billion pieces of data, making a proof in a traditional binary Merkle tree would require about 1 kilobyte, but in a Verkle tree the proof would be less than 150 bytes - a reduction sufficient to make stateless clients finally viable in practice.”

Ballet presented a draft of the code changes necessary to taking the first steps to replacing Ethereum’s reliance on Merkle tree data structures to that of Verkle trees. The draft of Ballet’s code specifications can be found here. Developers anticipate activating these code changes in the upgrade after Deneb. Ballet suggested naming the upgrade for the Verge to Electra. Danny Ryan appreciated the enthusiasm but recommended against planning the specifics around the upgrade too far in advance, saying there may be other EIPs combined with what Ballet presented in the upgrade after Deneb. Ballet agreed to continue his work on Verkle trees starting with more client implementations of his proposed code changes.