Ethereum All Core Developers Execution Call #186 Writeup
On April 25, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #186. Chaired by Ethereum Foundation (EF) Protocol Support Lead Tim Beiko, the ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers discussed preparations for Pectra Devnet 0 and EIP 3074 implementation. They also debated what other EIPs should be considered for inclusion in the Pectra upgrade and broad thoughts on changes to governance considering Ethereum’s “rollup-centric roadmap”.
Pectra Devnet 0
Beiko asked client teams on the call to share updates on their progress for Pectra Devnet 0. Marek Moraczyński from the Nethermind team said that Nethermind has implemented all Pectra EIPs and is in the process of polishing them and writing tests for them. Justin Florentine from the Besu team said that Besu is in progress for Pectra EIP implementation and anticipate being ready with them all for the launch of Devnet 0. Andrew Ashikhmin from the Erigon team said that he was unsure if Erigon would be ready with the full suite of EIPs for Devnet 0, in part because some of the specifications for these EIPs are still in flux, and because the Erigon client is undergoing a transition to a new major version release, Erigon 3, that is taking up resources and time from the team. Erigon 3 and Pectra EIPs will be finalized and built into the Erigon client together. “Lightclient” from the Geth team said that Geth is “days away” from being ready for Devnet 0. Gajinder Singh from the EthereumJS team said that Ethereum JS will also be “good to go” for Devnet 0. Developers have not yet set a date for the launch of the devnet but based on these client responses, developers will likely decide on a date over the next few weeks.
EIP 7685
Lightclient has merged EIP 7685, which creates a general-purpose framework for storing EL-triggered requests to the consensus layer (CL), and its impacts on EIP 6110 and 7002 into Pectra specifications. Beiko said that developers should include this EIP and its subsequent changes to other Pectra EIPs in their Devnet 0 releases.
On the topic of testing, Mario Vega from the EF Testing Team shared that tests have been completed for EIP 6110 and 2537. Tests for EIP 7002 and EIP 2935 will be completed this week or next. Tests for EIP 3074 will not be ready for Devnet 0. EF Researcher Antonio Sanso said that there have been updates to EIP 2537 specifications and new test vectors added to the GitHub repository. He recommended that all client teams take a look on GitHub. EF Researcher Hsiao Wei Wang flagged there is an error in CL spec test vectors that she will correct shortly and release a new version for.
EIP 3074
Several changes were proposed on this week’s ACDE call to EIP 3074 specifications. Ahmad Mazen Bitar proposed changing the behavior of EIP 3074 to allow DELEGATECALL before AUTHCALL to broaden the use cases for the EIP. Derek Chiang founder and CEO of a blockchain wallet operating system called ZeroDev proposed the creation of a “noncemanager” to facilitate global revocation of AUTH messages if needed, among other changes. Some developers on the call pushed back on changes to EIP 3074 that would greatly increase the complexity of its implementation.
Beiko recommended that developers discuss proposed changes to EIP 3074 in a separate breakout meeting. He noted that to have sufficient time for EIP 3074 implementation in Pectra, developers should try and finalize its specifications “in the next month or two”. Lightclient agreed to organize the EIP 3074 breakout meeting. For Devnet 0, Beiko affirmed that client teams should implement EIP 3074 without any changes, even though developers may decide for future devnets to implement the EIP in a different way or remove it all together from the upgrade.
More than the implementation details of EIP 3074, developers earnestly debated whether there was sufficient community support for the EIP. A developer on the call with the display name “Siri” voiced concerns that EIP 3074 is “bad in principle and something that would slow us down on the path to full account abstraction.” Beiko responded saying that based on Ethereum Magicians and ACD call discussions, client teams appear in favor of EIP 3074 over other account abstraction (AA) related proposals. “It does seem like the proposal with the most consensus in the short term that we could actually improve the state of the EOAs in the next fork,” said Beiko. To this Siri pushed back saying that client teams should not be making this decision in isolation. “We should hear from other stakeholders,” said Siri, adding, “We don't want to veer into the realm of making contentious, hard forks. … I think it would be better to get a feel for what other stakeholders, how they view this proposal.”
The back and forth between Beiko and Siri sparked questions in the Zoom chat about how broader consensus should be established for EIPs outside of the ACD calls. Chiang wrote in the chat, “Unfortunately the fact remains that most people in the 4337/AA community were caught by surprise, … What it actually looked like for most 4337 people was that 3074 basically went from ‘it’s dead’ to ‘oh wait it’s enshrined now.’” Chiang recommended first doing the EIP 3074 breakout meeting to have a deep conversation about the technical specifications of the EIP and then deciding on whether it should remain in the Pectra upgrade. EF Researcher Ansgar Dietrichs agreed and said that developers should also spend the time to sketch out a concrete plan for enabling other AA-related EIPs after the Pectra upgrade. “We should make the understanding that 3074 will be pulled out unless we make enough progress there that by the time we make a decision, everyone is happy,” said Dietrichs.
Co-founder of Ethereum Vitalik Buterin added that developers should discuss how best to alert Ethereum users in advance through informational EIPs and the like of forthcoming changes to the functionality of their accounts, specifically externally owned accounts (EOAs), in the coming years with the activation of account abstraction related EIPs like EIP 3074 and others.
Other Pectra Proposals
Then, developers moved on to discuss what other code changes should be considered for inclusion in the Pectra upgrade. Geth developer Marius van der Wijden said that this should depend on whether EIPs with high complexity like EOF are going into the Pectra or not. “If we were to include EOF, then the fork is definitely full. If we’re not including EOF, maybe we could include something more,” said van der Wijden.
Siri raised concerns about the inclusion of EIP 3074 in Pectra without a security audit. Beiko recommended tabling this discussion until specifications for EIP 3074 are finalized and there is a “reasonable concern” based on those specifications that could be addressed through an audit.
Bitar said that he would like to see the addition of EIP 7212 in Pectra. EIP 7212 would create a new precompile that performs signature verification in the secp256r1 elliptic curve. This could be used in tandem with hardware devices that support biometric identification of users. According to Bitar, supporting biometric identification to sign Ethereum transactions would be a major improvement for the user experience. Ashikhmin said that he was also in favor of this proposal. Dietrichs noted that it is the only one that has been approved for implementation by Layer-2 rollups through the “Rollup Improvement Proposal” (RIP) process.
Other developers including Dietrichs, van der Wijden, and Moraczyński voiced their support for EIP 7623, which would increase the cost of call data and thereby limit the maximum block size. Beiko recommended labelling EIP 7623 and EIP 7212 as “Considered for Inclusion” or CFI’d into Pectra and revisiting the bandwidth of client teams to support these two after the launch of Devnet 0.
About the bundle of EIPs related to updating the serialization method of the EL to SSZ, van der Wijden expressed concerns that these were too difficult to ship in Pectra. His colleague on the Geth team Guillaume Ballet agreed with this assessment. Buterin jumped in saying that at the least updating the serialization method for transaction receipts would have “significant value” beyond Ethereum itself by removing the next for extra security auditing overhead for Layer-2 rollups built atop Ethereum. The primary champion for SSZ related EIPs, Etan Kissling from the Nimbus team, was not present for the call but he has written up a detailed explanation on GitHub for why these code changes are important and should be considered for inclusion in Pectra.
Developers also re-discussed EOF. Independent Ethereum protocol developer Danno Ferrin shared that the EOF team is working on EL spec tests for the code changes. EVMOne and Reth are two EL client teams that have reportedly finished their EOF implementations. Ferrin said that the Geth team is making “good progress” on their implementation. Ferrin added that Ballet is working with “Daniel” from the Solidity team to address concerns about the compatibility of EOF and Verkle.
Ballet noted that based on his conversations with Daniel and other developers like Dietrichs it will be difficult to reduce the scope of EOF without defeating its purpose and creating more work for developers down the road to implement another set of EOF-like code changes.
Instead of choosing between a small or big EOF upgrade, a developer on the call with the screen name “Charles C” recommended finding a way to easily implement EOF iteratively through side car mechanisms, such as the ones used for blob transactions. Dietrichs asked in the chat whether client teams would have a greater appetite for EOF in Pectra if its complexity was reduced. The Ipsilon team noted that new proposed opcodes in EOF causing the highest amount of complexity such as “TXCREATE” has already been addressed and specific requests to remove functionality like “EOFCREATE” would not greatly reduce overall EOF complexity. As background, Ipsilon is the name of the EVM research and development team funded by the EF. Beiko recommended that developers continue to discuss EOF implementation during the recurring EOF breakout calls.
ACD/EIPs & L2/RIPs
As a final topic of discussion on ACDE #186, developers discussed changes to Ethereum’s EIP process considering the new RIP process. Dietrichs noted that it has been six months since developers launched the meeting series for rollup coordination, RollCall, and the RIP process. There are outstanding questions about how these processes will and should impact the Ethereum EIP process down the road. An ongoing research question among L2s is whether long-term equivalence to the Ethereum Virtual Machine (EVM) is desirable for rollups or not, said Dietrichs. He also added that an open question is to what extent changes implemented on L2s will or won’t eventually impact protocol decisions on Layer 1 Ethereum.
Geth developer Péter Szilágyi said that some features shipped on L2s may not be appropriate to ship on L1 and that in certain situations even following the features shipped on L2s may differ among L2s, which may cause confusion for Ethereum protocol developers. EF Researcher Carl Beekhuizen noted that the RollCalls and RIP process would not require Ethereum protocol developers to ship any features on L2s but rather improve communication between rollups and Ethereum developers so that confusing scenarios like the ones described by Szilágyi can be avoided. Van der Wijden raised concerns about being in a situation where protocol developers take the time to support changes implemented on an L2 that eventually become obsolete or unnecessary because the L2 itself shuts down or stops being used.
To these concerns, Dietrichs said, “I think the impression has always been that Layer 2s can just experiment and go more wild. I think in practice what we've seen is that most of them decided to not do this or even or at least maybe started doing this and then over time, mostly stopped. So now they're really following mostly Layer-1 specs. And I think at least given the rollup centric roadmap or something where we kind of all decided this is the best way for the ecosystem to go, we at least owe Layer 2s clear guidance and communication about like the best path forward here.”
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.