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.
Capella
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.
Deneb
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.
Electra
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.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2022. All rights reserved.