Ethereum All Core Developers Execution Call #164 Writeup
On June 22, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) call #164. Chaired by the Ethereum Foundation’s Tim Beiko, the ACDE calls are a bi-weekly meeting series where Ethereum client teams discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed: a new testing repository for recent and upcoming code changes such as Ethereum Improvement Proposal (EIP) 4844; progress on the Cancun/Deneb upgrade; and a proposal to separate Ethereum Request for Comments (ERC) proposals from EIPs and move ERCs to a separate GitHub repository.
Introducing Execution Spec Tests
The execution spec tests repository is a new testing framework implemented in Python for Ethereum EL clients. Unlike the existing “ethereum/tests” repository, the execution spec tests repository is more readable, parametrizable, and modifiable. It also contains a newer collection of tests that target recent and upcoming Ethereum code changes, namely EIP 4844. “Danceratopz” of the Ethereum Foundation testing team presented the new test repository and highlighted that it does not entirely replace ethereum/tests but should be considered a complementary testing tool for EL client teams. The new repository was well-received by developers on the call. “It is very nice,” said Geth (EL) developer Marius van der Wijden. “If everyone implemented this then we could start implementing new EIPs and other plans. Right now, it’s basically only really possible in Geth and maybe Besu to implement a new feature … If all clients also implemented this, it would be really nice so researchers can prototype in their favorite language and don’t need to rely on Geth to do it.
Making Progress on Dencun
The scope of the Cancun/Deneb upgrade, Dencun in short, has been more or less finalized on both the EL and CL side as of the last two ACD meetings. This week, developers gave progress updates on various EIPs and testing efforts for Dencun.
EIP 4844
Developers agreed to update the precompile address for EIP 4844 to utilize the next available address according to a hexadecimal naming convention. Ethereum Foundation researcher Alex Stokes proposed the change after noticing that the precompile address for 4844 was not “tightly packed in the sense of having the one right after the last precompile we’ve added.” The reason for the gap was because the next available precompile address was initially reserved for the BLS precompile, which would have been introduced through EIP 2537. However, as determined on ACDE #163, EIP 2537 will not be prioritized for Dencun. As background, precompiles allow smart contract developers to use cryptographic and signature libraries that would otherwise be prohibitively expensive to execute through the Ethereum Virtual Machine (EVM). So far, Ethereum core developers have added nine precompiles to the EVM and will create two more under the “0xA” and “0xB” addresses through the activation of EIP 4844 and 4788, respectively.
EIP 4788
Alex Stokes presented a proposal for bounding the storage growth of EIP 4788 through the use of two ring buffers. In programming, ring buffers are a common implementation for queuing data that exists as a fixed-length array and removes/adds data in a first in-first out fashion. Developers agreed to implement the proposal. “It’s kind of a funny approach when you first look at it,” said Ethereum Foundation researcher and Chair of the ACDC calls Danny Ryan, adding, “But I do agree that given the constraints it is actually a really solid solution.”
EIP 5656
The test cases for copying memory areas in the EVM have been added to the ethereum/tests repository. All EL client teams are encouraged to test their implementation of EIP 5656 against these cases. Already, Besu, Ethereum JS, and Nethermind (EL) client teams have said their implementations pass EIP 5656 test cases.
Engine API
Teku (CL) developer Mikhail Kalinin is spearheading a few changes to the Engine API. The Engine API is responsible for standardizing communication between EL and CL client software. With the activation of EIP 4844, there are new methods that need to be created for facilitating blob transactions. Additionally, there are certain methods that will soon become deprecated under Engine API Version 3. One of those methods is “engine_exchangeTransitionConfiguration.” Kalinin suggested three steps to “gracefully deprecating” the method. First, EL clients should stop logging an error message when the method is not called. Second, CL clients should remove the method entirely on their end, either in their final Deneb release or earlier. Finally, EL clients should then be free to remove the method handler in its entirety post-Dencun.
Most EL clients have already stopped logging error messages for the engine_exchangeTransitionConfiguration method. Kalinin agreed to move forward with the second step of the deprecation process and bring up the matter again during next week’s ACDC call, which is focused on CL client development.
Devnet 6 & 7
The sixth official multi-client test network for EIP 4844, Devnet 6, launched on Friday, June 16. The network ran into several issues at launch but is now stable. Parithosh Jayanthi, a DevOps Engineer at Ethereum Foundation, said that client teams are working on patching bugs and re-releasing software for Devnet 7 under the same code specifications as Devnet 6. The Geth (EL) team said that some of the issues they ran into on Devnet 6 were due to incorrect identification of transaction formats. The Besu (EL) team said they ran into challenges interacting with the RPC, as well as some formatting challenges. The Lodestar (CL) team said they ran into issues calculating data for gas used correctly. Developers agreed to focus on patching up outstanding bugs in their implementation of EIP 4844 and pass relevant hive tests. Devnet 7 like Devnet 6 will only focus on testing implementations of EIP 4844, no other Dencun EIPs.
Deneb Specifications Release
Given that the scope of both Cancun and Deneb has been finalized, Danny Ryan will release a full featured specifications document including test vectors for the Deneb upgrade in the coming days. The final Deneb spec release will include details for implementing not only EIP 4844, but also EIP 7044, 7045, and 4788.
Moving ERCs to a Separate Repository
The final discussion on ACDE #164 was about moving ERC token standard proposals to a separate repository from EIPs. According to Geth (EL) developer “lightclient”, the change would allow ERC and EIP governance processes to evolve more naturally and independently from one another. Many developers on the call including Justin Florentine from the Besu (EL) team, Danno Ferrin from Hedera Hashgraph, and Tomasz K. Stańczak from the Nethermind (EL) team were in favor of separating out ERCs from EIPs. Greg Colvin, an EIP editor, pushed back on the proposal, saying it was a “premature decision.” Colvin recommended doing more surveys and outreach to different interest groups interacting with the EIP and ERC processes on their pain points before making any changes. Marius van der Wijden agreed with Colvin that the EIP process did need a deeper review and, in his view, had become too “rigid.” However, he emphasized that there already was strong agreement for the separation of ERCs from EIPs and this was a change that would be better implemented sooner rather than later. Florentine agreed with van der Wijden’s sentiment saying, “I don’t think we should interpret advocating for a split as endorsement of a current perfect world of editorial process and EIP authorship in general.”
Pooja Ranjan, Chief of the Ethereum Cat Herders, suggested the creation of an RSS feed for helping track changes in the statuses of EIPs and ERCs. She also highlighted that separating out ERCs from EIPs without enough dedicated ERC editors may be harmful, rather than helpful, to the editorial process. Another point raised by Ranjan was the fact that the separation of ERCs from EIPs is primarily supported by protocol developers, rather than ERC authors themselves. “Had there been a proposal coming out of the ERC team saying that we don’t want to be part of the core EIP system at all because we feel we are different, I think I would have been more in favor of going towards the request,” said Ranjan. Tim Beiko also shared his thoughts on the matter, emphasizing that the split would not sever the close connections between the EIP and ERC approval processes. “It just gives more clarity,” said Beiko, adding, “It just keeps things more encapsulated. It doesn’t seem like a huge deal to have two repos rather than one.”
After more discussion, Beiko pushed to move forward with the proposal to which Greg Colvin again raised concerns. Beiko highlighted that unanimous consent among the people on the call was not required for moving the proposal forward. Colvin pushed back saying that there needed to be consensus to make the change among EIP editors, of which he is one of five. The disagreement between Beiko and Colvin sparked new debate on the merits of the proposal to split ERCs from EIPs and the urgency, as well as relative impacts, reversibility, and consensus process around the change. Ultimately, consensus was not reached and Beiko recommended further discussion of the matter on the next EIP Improvement Process call scheduled for Wednesday, June 28.
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.