Ethereum All Core Developers Consensus Call #114 Writeup
On July 27, 2023, Ethereum core developers gathered over Zoom for their 114th All Core Developers Consensus (ACDC) call. Chaired by Ethereum Foundation Researcher Danny Ryan, the ACDC calls are a bi-weekly meeting series where developers discuss and coordinate changes to the consensus layer (CL) of Ethereum. This week, developers discussed general updates on Deneb testing efforts and updates to two EIPs that may be considered for inclusion in the next CL upgrade after Deneb, now dubbed Electra.
Deneb Testing
Last week, developers conducted a shadow fork of the Sepolia test network. Parithosh Jayanthi, a DevOps Engineer for the Ethereum Foundation, said the shadow fork went smoothly and was retired yesterday on Wednesday, July 26. Jayanthi and his team are now working on updating tooling in preparation for the launch of Devnet #8. Devnet #8 is expected to launch late next week or early the week after. Ethereum Foundation Researcher Hsiao-Wei Wang is preparing a new release of CL code specifications for Devnet #8 which will be ready for client teams by Monday, July 31.
As developers look forward to a dedicated testnet that will feature all Deneb and Cancun related EIPs, Danny Ryan highlighted the importance of testing MEV-Boost related software along with CL and EL client releases. To this end, Ethereum Foundation Researcher Alex Stokes said that Jayanthi and another DevOps engineer are working on various hive tests specifically designed for MEV-Boost. As of July 27, updates to builder specifications have yet to be merged into a new release for testing on Devnet #8 or other Cancun/Deneb testnets. The sooner CL and EL specifications are frozen for the Cancun/Deneb upgrade, the more quickly new specifications for MEV-Boost software can be finalized, said Stokes.
While not a blocker for the launch of Devnet #8, Hsiao-Wei Wang pointed out there were naming inconsistencies between the EIP 4844 document and Deneb specifications implementing EIP 4844. Wang has opened an issue on GitHub to resolve these inconsistencies. She said she would open a pull request (PR) by Monday, July 31 on the EIP 4844 document to suggest updates to the language. Ryan encouraged developers to look at the PR in advance of next Thursday’s ACDE call.
Deneb-Related Code Changes
Last week, Gajinder Singh from the Ethereum JS (EL) client team proposed a minor change to CL specifications to simplify the construction of EL blocks and improve debugging efforts around EL payloads. Over the week, CL developers such as Enrico Del Fante and Mikhail Kalinin, both from the Teku (CL) team, as well as “Lightclient” from the Geth (EL) team, shared that they were not in favor of the change due to the ways in which it would unnecessarily duplicate data. Developers agreed to reject the code change following further discussion on this call.
For the past several months, Ethereum developers have been working on building a new algorithm known as the confirmation rule. Nodes can use this rule to calculate whether a block is confirmed based on certain assumptions such as network synchrony and the percentage of honest validators. A block is considered confirmed when it cannot be changed or replaced with another block. The confirmation rule primarily aims to improve the user experience as it could help provide confirmation of Ethereum blocks in under a minute. It currently takes 12.8 minutes for Ethereum to reach chain finality. The confirmation rule would not be used to replace finality guarantees, but it could be used for network stakeholders to track the head of the Ethereum blockchain. For more information about the confirmation rule and its related security analysis, read this document.
A few changes to the CL fork choice specification are required to implement the confirmation rule. Developers discussed how to best roll out changes to CL fork choice rules in lead-up to the Deneb upgrade. Ben Edgington from the Teku (CL) client team said that his team was in favor of implementing the changes in lead-up to Deneb but wanted to avoid having to support two version of CL fork choice at the time of the upgrade. Ryan agreed with this sentiment. Kalinin asked whether the upcoming changes to CL fork choice specifications should be documented in a formal EIP. Developers did not lean strongly either way so Kalinin said he would create a GitHub issue under Deneb specifications for these changes.
Electra Updates
Given developers’ focus on Deneb testing and code changes, Danny Ryan suggested tabling discussions about which EIPs to include in the next upgrade after Deneb until a future date. However, Ryan welcomed updates on EIPs that could be considered for inclusion over the next few weeks to prepare developers for the eventual discussion on what to prioritize for Electra. The following are three ongoing initiatives that Ethereum developers are working on outside of Deneb:
1. EIP 6914: This code change creates a way to reuse the validator index numbers of validators that have fully exited the Beacon Chain. This would prevent unnecessary computational burden on CL nodes by ensuring that there are no large gaps in the validator index when the nodes are processing withdrawals and scanning through the validator set. Proposed by “Dapplion”, a pseudonymous developer for the Lodestar (CL) client, EIP 6914 is being updated to address attack vectors and edge cases around the behavior of slashed validators.
2. Spec compliance: Roberto Saltini and Alex Vlasov, Researchers at Consensys, along with Aditya Asgaonkar, a Researcher at the Ethereum Foundation, have started work to improve the spec compliance of Ethereum clients through more comprehensive test coverage. In a Google document outlining the motivation for their work, Saltini, Vlasov, and Asgaonkar wrote: “A client implementation is spec compliant if, from the point of view of an external node on the network, it behaves like the Ethereum Python specification, that is, it sends the same messages in response to messages received and exposes the same value … The beauty of performing security analysis on the specification is that if implementations are spec compliant, then they automatically inherit the guarantees provided by the security analysis performed. However, the flip side of this is that if an implementation is not spec compliant, then it is completely unknown whether such guarantees are inherited.”
Saulius Grigaitis, CTO of blockchain infrastructure company Sifrai, was enthusiastic about the initiative and shared thoughts around different approaches to improve spec compliance through written specifications and test vectors. Grigaitis also shared thoughts on this matter on Twitter shortly after the call. Ryan encouraged other developers to read Saltini, Vlasov, and Asgaonkar’s Google document and share their thoughts asynchronously.
3. EIP 6110: The code change appends new validator deposits to EL blocks so that the responsibility of deposit inclusion and validation is done on the EL instead of the CL. Shifting the responsibility would achieve several benefits including:
Reduced complexity in Ethereum client software design
Increased security of deposits from validators
Improved validator UX
Mikhail Kalinin presented a comprehensive document outlining the first end-to-end prototype of EIP 6110. With help from the Ethereum Foundation DevOps, Besu (EL), and Lighthouse (CL) teams, Kalinin was able to set-up several multi-peer devnets for stress testing this code change.
Source: Mikhail Kalinin, HackMD
A few outstanding questions from the prototyping of EIP 6110 include:
Potential to implement the design without using validator queues
Further performance analysis on CL nodes
Sig verification optimization during deposit processing
Ryan encouraged developers on the call to read Kalinin’s document and chime in with questions over the coming weeks.
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 2023. All rights reserved.