Ethereum Consensus Layer Call #99 Writeup

https://www.galaxy.com/research/insights/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.