Ethereum All Core Developers Consensus Call #133 Writeup
On May 2, 2024, Ethereum developers gathered over Zoom for All Core Developers Consensus (ACDC) call #133. The ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum, also called the Beacon Chain. This week the call was chaired by Ethereum Foundation (EF) Researcher Alex Stokes. Developers discussed progress on Electra Ethereum Improvement Proposal (EIP) implementations. They also discussed research on a few parallel initiatives including confirmation rules and data availability sampling. Lido co-founder Vasiliy Shapovalov and Lighthouse developer “Dapplion” presented a new EIP, EIP 7684, to strengthen the security guarantees of smart contract-based staking pools.
As a closing remark, Stokes reminded developers that the next ACDC call is cancelled. CL client teams will reconvene for the next ACDC on May 30, 2024.
Confirmation Rule Research
Roberto Saltini, Lead Researcher in Formal Verification of Distributed Systems at ConsenSys, presented research on a confirmation rule for Ethereum that can be used to determine if a block will be part of the canonical chain before the block becomes finalized. The rule relies on a set of assumptions about the network such as the absence of any validator controlling more than 1/3 of ETH staked. Based on the research findings, Saltini has submitted a pull request on GitHub to introduce a confirmation rule that Ethereum nodes can rely on to confirm blocks. He asked for feedback from developers on the rule’s implementation and pointed to the full research paper where developers can get more details about the rule’s motivation and set of assumptions.
Electra
Andrew Coathup, the editor of a weekly Ethereum newsletter called Week In Ethereum News, asked on the meeting agenda if the “Considered For Inclusion” (CFI) for EIP 7547, Inclusion Lists, should be removed given that the EIP will not be included in the Electra upgrade. Stokes was under the impression that the CFI status is not generally removed from EIPs once it is granted by developers. EF Protocol Support Lead Tim Beiko said that in his view the CFI status is removed from all EIPs that do not end up making it into an upgrade once the scope of the upgrade is finalized. Regardless of the meaning or utility of the CFI label, what’s clear is that EIP 7547 will not be included in Electra. Developers may re-discuss the EIP later for a different upgrade.
Then, developers discussed preparations for Pectra Devnet 0, the first developer-focused, multi-client test network implementing client software that supports Prague and Electra EIPs. EF researchers have released a new version of Electra specifications that contains bug fixes from the prior one and new test vectors. EF Researcher Hsiao-Wei Wang said that she has received reports of issues in the latest release and said that a hotfix for the specifications will be ready early next week. In the meantime, she encouraged developers to reach out if they encounter any new bugs.
Developers are aiming to launch Pectra Devnet 0 in roughly two weeks. It was clear from the discussion that CL client teams would not be ready for a launch the following week, but possibly the week after, starting May 13. EF Developer Operations Engineer Barnabas Busa shared a link to the client tracker document for keeping tabs on the readiness of client teams for Devnet 0. On the call, representatives of various client teams shared more detailed updates on their progress.
Lighthouse – Instead of working on the implementation of Electra EIPs one by one, the team is working on implementing all Electra EIPs in tandem according to the area of the client code base these EIPs impact. For example, working on all changes impacting state, then blocks, then networking, and so on. Thus, while the client tracker document may not reflect much progress on each individual EIP, “Sean” from the Lighthouse team assured developers that progress was being made. He noted that most of the time’s focus and energy has been on EIP 7549, Move committee index outside Attestation, which he noted “touches a lot of the code base.”
Lodestar – The team is making progress and working on the implementation of EIP 7549.
Teku – The implementation of EIP 6110 and EIP 7002 are both complete. MaxEB and EIP 7549 are a work in progress.
Prysm – The team is taking a similar approach to Lighthouse for implementing Electra EIPs. James He representing the Prysm team noted that EIP 7549 requires a lot of work and has slowed down the team’s progress.
Grandine - Saulius Grigaitis, representing the Grandine client, said “huge work” still needs to be done for completing the attestation refactoring necessary for EIP 7549.
Nimbus - The team is taking a similar approach to Lighthouse and Prysm for implementing Electra EIPs. “Dustin” from the Nimbus team expressed concerns about the challenges of implementing EIP 7549.
Speaking more to the implementation of EIP 7549, Dustin asked whether there may have been a “process failure” in the way the code change was presented and then approved for inclusion in Electra. Though presented as “a minor change,” the EIP is proving to be more difficult to implement than developers initially expected. Sean agreed with Dustin’s concerns and asked if there was a process through which developers could readjust the scope of a fork after implementation work has started. Stokes said that developers will “make it work” and that in the future, they should “be mindful” of these types of unexpected learnings about EIP complexity. Dapplion also chimed in saying that the original EIP 7549 was a simpler proposal and that developers should be mindful of the consequences of changing the details of an EIP on an upgrade’s overall complexity and scope. “If an EIP mutates, we should be mindful of the consequences even if its already considered for inclusion,” said Dapplion.
EIP-7684
Shapovalov presented EIP 7684, Return deposits for distinct credentials. The main motivation for this code change is to prevent front-running attacks against smart contract-based staking pools. The EIP document states, “Some staking operations feature two distinct entities, one operating the validating key, and one funding the deposit. The funding entity delegates control of the stake operation but must retain ultimate control of funds. If the funding entity naively submits a single deposit with the full stake amount and the other entity's validating key, it is subject to a front-run attack.” While there are workarounds to prevent such attacks, the mitigation techniques are difficult to deploy exclusively through smart contracts and as Shapovalov notes often expensive and inefficient. To offer a more effective solution, the EIP suggests the creation of “a distinct execution withdrawal credential” that can automatically withdraw deposits for validator records.
Shapovalov said that he is presenting the EIP to raise awareness about the code change but not necessarily to have it included in Electra. It is a small enough code change in terms of complexity that he believes developers could include last-minute in Electra if they wanted. However, for now, he is mainly sourcing feedback and review of the proposal. The author of the EIP Dapplion added that the EIP is not “trivial” but is the simplest code change in his mind to address the problem of front running attacks against staking pools. That said, Dapplion encouraged developers to see if an even simpler solution could be found.
PeerDAS
Developers have been making progress on enabling data availability sampling (DAS) on Ethereum. The initiative to greatly enhance Ethereum’s capacity to support blob transactions is called PeerDAS. Stokes said that an initial alpha release for the specifications of PeerDAS has been created. “It's really exciting to see the progress there,” said Stokes. Representatives from the Lighthouse, Prysm, and Teku team all shared updates on their progress with the alpha release specifications. Developers also discussed a few open questions about the specs, specifically assumptions about data synchrony. For initial testnets, developers agreed to use the strategy that works the best for them and come to a consensus about the standard for data synchrony later.
Closing remarks
Due to an Ethereum developer interop event in mid-May, the next ACDC call is cancelled. Developers will reconvene for these meetings on May 30, 2024. All Core Developers Execution (ACDE) #187 is still scheduled to occur next Friday, May 9.
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 2024. All rights reserved.