Ethereum Consensus Layer Call #99 Writeup
On December 1, 2022, Ethereum developers gathered for their 99th Consensus Layer (CL) call. Chaired by the Ethereum Foundation’s Danny Ryan, the CL calls are one of two bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the protocol of Ethereum. This week, developers reaffirmed decisions made on last week’s All Core Developers (ACD) call. Namely, developers agreed to work on enabling staked ETH withdrawals for Ethereum’s next upgrade, Shanghai, separately from their work on proto-danksharding (EIP 4844), which will likely be activated in a separate upgrade after Shanghai. Developers also discussed a slew of ongoing research topics and initiatives related to Ethereum’s Consensus Layer specifications. Finally, near the end of the call, developers celebrated the 2nd anniversary of the Ethereum Beacon Chain, which launched on December 1, 2020.
Staked ETH Withdrawals and EIP 4844
To kick off the call, Danny Ryan reiterated the discussion from ACD Call #150 where CL client teams came to consensus about focusing exclusively on staked ETH withdrawals for Shanghai. “I think crucially what was made clear by Consensus Layer teams is that they believe that EIP 4844 is not nearly in the same readiness as [staked ETH] withdrawals and coupling them would significantly delay withdrawals. We will not couple them. We will work full steam ahead on Capella in its current form,” said Ryan on the call. Capella is the name of the dedicated test network where core developers are testing out code changes for staked ETH withdrawals.
Barnabas Busa, a devops engineer at the Ethereum Foundation, gave an update about progress for enabling staked ETH withdrawals. Busa mentioned that there are two multi-client developer networks testing withdrawals, one that mimics a pre-Merge environment and another that mimics a post-Merge environment. Neither of these devnets currently support all EL and CL clients. The newer one testing withdrawals in a post-Merge environment supports the Prysm, Lighthouse, and Teku CL clients, as well as the Geth and Nethermind EL clients. Once the implementation from other clients such as Nethermind (EL) and Besu (EL) are ready, developers will spin up a longer-lived, multi-client testnet for withdrawals.
Then, Alex Stokes, a researcher at the Ethereum Foundation, gave a short update on his pull request implementing bounded sweeps. In short, this is a mechanism to prevent an edge case scenario where the protocol is required to scan through the entire validator set for partial and full withdrawals. Stokes proposal limits the scan to a maximum of 1,024 validators. There were no objections to Stokes’ proposal and developers agreed to move forward with more withdrawals test cases around the bounded sweep by the end of next week.
Even though development for EIP 4844 will happen separately from the development work going into Shanghai and staked ETH withdrawals, developers still discussed some of the open discussion items related to implementing proto-danksharding. Sean Anderson, a software engineer Sigma Prime which builds the Lighthouse (CL) client, mentioned that there was an open question around how the network will handle syncing blobs. Blobs are a new type of transaction that will be introduced in EIP 4844 that exclusively commits transaction data from Layer-2 rollups to the base layer of Ethereum. Ryan recommended that further discussion around the edge cases for blob syncing be taken to the open GitHub issue.
Trent Van Epps, an ecosystem person for the Ethereum Foundation, gave an update about progress for the trusted setup ceremony required for EIP 4844 implementation. The ceremony, which is designed to generate a secure piece of code that will be used in EIP 4844, is close to being ready for a public contribution period. Van Epps said that he hopes the ceremony will be one of the largest ever conducted in the crypto space, gathering between 8,000 and 10,000 contributions. The public contribution period for the ceremony will last roughly 2 months and begin sometime in December. For more information, read this website and join this Twitter Spaces session on December 2, 2022.
Research Discussions
Developers ran through several discussion items related to potential optimizations and changes to the Ethereum CL specifications. First, Adrian Manning, co-founder of Sigma Prime, highlighted two proposals, both of which are backwards compatible, meaning they wouldn’t require a system-wide hard fork upgrade to implement. The first detailed here aims to improve peer discovery between staking nodes on Ethereum. The second enables support for CL nodes that are running the latest internet communication protocol known as IPv6. This latter discussion item was raised by the Sigma Prime team back in May. Call notes from that prior CL call can be found here.
A checkpoint sync refers to an operation that lets new nodes connecting to the Beacon Chain sync quickly to the head of the chain by fetching the latest block state from a trusted node. Checkpointz is a tool that the Ethereum Foundation DevOps team built to make it easy for trusted nodes expose a checkpoint sync endpoint. On the call, Mikhail Kalinin, Lead Researcher at ConsenSys, explained there is some concern around Checkpointz becoming a central point of failure for nodes and pointed to a few proposals to help diversify reliance away from Checkpointz to other tools.
Then, Oisin Kyne, co-founder of Obol Technologies which is a company building distributed validator technology (DVT) solutions, highlighted an issue with the validator assignment of aggregation duties. Kyne explained that the duties are not designed for execution by a distributed validator set. As such, he proposed two new endpoints for CL clients to better support the operation of distributed validators. More information about Kynes’ proposal here and high-level background on DVT here.
Finally, Kalinin raised two questions around the Ethereum Engine API specifications. The first was a housekeeping item to help simplify Engine API specifications by removing an outdated method for retrieving capabilities supported by the EL client called “engine_getCapabilities.” Developers agreed to give feedback on this suggestion asynchronously on GitHub. The second question by Kalinin was around which structure to use for Engine API specification documents. One of the approaches documents changes to the Engine API by fork, meaning by system-level hard fork upgrades. The other structure documents change by Engine API functionality. The pros and the cons for each approach are explained in more detail here. No developers on the call had a strong bias towards either, but Ryan did mention he was more comfortable with the fork-approach, and Kalinin mentioned that he thought the pros of going with a functionality-approach were strong.
Miscellaneous Items
Developers agreed to review the discussion on GitHub around engine_getCapabilities and think more about the structure for documenting Engine API changes in lead-up to Shanghai. Before ending the call, independent Ethereum developer Micah Zoltu asked a quick question around the data behind the website clientdiversity.org. Zoltu explained that the website gets their data from two different sources, and this is resulting in wildly different results. Ryan responded saying that one of these methods calculates the distribution of clients by staked ETH. The other records data about the distribution of clients by using a crawler that identifies nodes and their peers. To Ryan’s knowledge, the data gathered by the node crawler is inaccurate and the method relying on block print and staked ETH distribution, while not perfect, is significantly more reliable.
Jacek Sieka, also known as “Arnetheduck,” Head of Research Development at Status who is building the Nimbus (CL) client, mentioned that his team has pushed out a new client release. The release officially graduates the Nimbus client from beta to a production-ready status. More details about the improvements in this release can be found here. Before ending the call, Ryan notes that the next CL call on December 15, 2022, will be the last call of the year. Developers will resume calls sometime in January in the new year.
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.