Ethereum All Core Developers Execution Call #172 Writeup
On October 12, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #172. Chaired by the Ethereum Foundation’s 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 progress on:
Cancun/Deneb (Dencun) testing
Ethereum Virtual Machine (EVM) Object Format development.
Dencun Testing
Barnabas Busa, a DevOps Engineer for the Ethereum Foundation, shared a number of updates about Devnet #9, which developers launched on Friday, September 29.
Devnet #9 now has a 93% participation rate, which means 93% of validators are actively participating in network consensus.
The 7% of validators that are not operational are comprised primarily of Geth (EL)/Teku (CL) validator nodes.
There are also issues with the Erigon (EL)/Prysm (CL) client combination, as well as the EthereumJS (EL) client.
The Flashbots team is testing an MEV-Boost relay and builder on Devnet #9. Busa encouraged other relay and builder operators to reach out to him so that more MEV infrastructure can be tested on Devnet #9.
Blob transactions are not yet being tested through MEV-Boost builders. Blobs are being dropped by builders, and developers are unsure if this is because the blobs are actually invalid, that is not meeting the minimum base fee requirement, or being dropped for some other reason.
Busa and his colleague at the Ethereum Foundation Parithosh Jayanthi also shared updated about the forthcoming launch of Devnet #10:
Devnet #10 will not be ready this week but hopefully next week.
For Devnet #10, developers expect to test the trusted set up file from the EIP 4844 KZG ceremony.
Devnet #10 will feature a large validator set, 330,000 active validators. At the genesis of the devnet, there will be an influx of validator deposits and exits to trigger a change to the validator entry churn limit from 5 to 4 roughly a day or two after network launch. The actual maximum entry churn limit that will be imposed on mainnet is 8, but developers will use a limit of 4 for ease of testing EIP 7514 on Devnet #10.
Busa emphasized that right now developers are still working through “big questions” in the process of testing Dencun. Until these questions are answered, developers will not move forward with the launch of Devnet #10, possibly the final devnet for Dencun before the upgrade is activated on public Ethereum testnets like Goerli. Summarizing what developers are looking for before launching Devnet #10, Jayanthi wrote in the Zoom chat box:
Updated trusted setup files from the EIP 4844 KZG ceremony
Better visibility for blob transactions
MEV pipeline
Network stability
Jayanthi encouraged client teams on the call to add support for this Beacon API to support better visibility for blob transactions. Beiko asked whether developers would feel comfortable upgrading the Goerli testnet after the launch of Devnet #10. Busa recommended waiting to see the results of Devnet #10 before deciding about next steps for upgrade testing.
As an aside, Jayanthi confirmed that some time after Devnet #10, possibly in parallel with testing efforts on public testnets, developers will conduct a shadow fork of Ethereum mainnet to further test the Dencun upgrade. However, Jayanthi noted the utility of a shadow fork may be limited as most bugs found during Dencun testing so far have been discovered on the peer-to-peer networking layer.
Geth (EL) developer Marius van der Wijden shared that one of his colleagues, Péter Szilágyi, had managed to operate his own node on Devnet #9 and was seeing major issues related to blob spam. To prevent his node from crashing, Szilágyi has reportedly implemented a transaction handler to limit the number of blobs his node will see on the devnet. Van der Wijden recommended CL teams re-discuss the 3/6 maximum blob target/limit in EIP 4844, and EL teams carefully consider node bandwidth requirements and ways to address blob spam. For further discussion about these issues, Beiko encouraged developers to join the Dencun Interop Testing Call on Monday, October 16.
EVM Object Format Development
Then, developers discussed the latest developments for EVM Object Format (EOF). EOF is a bundle of EIPs focused on changes to the EVM, which is the virtual machine built atop Ethereum that executes smart contract code. One of the champions for EOF, Danno Ferrin, presented a high-level summary of the work that has been done for EOF in the last several months.
Ferrin began his presentation by emphasizing the desire to have EOF be the main code change included in the upgrade after Cancun/Deneb, called Prague/Electra. Ferrin said that there are four main teams working on EOF:
Team Ipsilon - an Ethereum Foundation-funded team of developers focused on improvements to the EVM,
EL client teams - such as Geth, Besu, and Nethermind,
High-level language compiler teams – such as Solidity and Vyper,
Smart contract developers – such as champions of the SSTORE2 opcode.
The main purpose of EOF is to create a new container format for EVM code. The container format would clearly delineate between code and data, which is not currently possible, and allow new opcodes that would help smart contract developers design their applications more efficiently and with higher guarantees of code security. EOF requires the creation of a new container format for EVM code whilst still maintaining the current format. For ease of implementation and testing around these changes to the EVM, Ferrin detailed ways that developers could reduce the dependencies between smart contracts utilizing new EOF EVM code and legacy smart contracts that do not. Though client teams would have to maintain two versions of the EVM, Ferrin argued that the newer version would be easier to update than the current EVM. He also said that over time the current EVM could slowly be deprecated as more smart contract developers adopt EOF.
The EOF EIPs mentioned in Ferrin’s presentation included:
EIP 3540: The new container format for EVM code.
EIP 4200: Three new EVM jump instructions introducing static jump.
EIP 4750: Two new opcodes that would remove the need and disallow dynamic jumps.
EIP 663: Two new instructions to allow access to a stack depth of 256, instead of 16.
EIP 7480: Four new instructions to enable read capabilities to the data section of an EOF container.
EIP 7069: Three new call instructions to simplify semantics about gas usage and fees.
EIP 5450: Introduce validation of EOF formatted smart contracts at contract execution.
EIP 3670: Introduce validation of EOF formatted smart contracts at contract creation.
To summary the list of code changes proposed for EOF, see the following chart on EOF opcode changes from Ferrin’s presentation:
Caption: EOF opcode changes summary.
Source: Danno Ferrin
With regard to testing progress on EOF, Ferrin explained that specifications for EOF are not yet finalized which is why there are no client implementations for the upgrade yet. However, he foresees testing for EOF to be extremely “self-contained” and relatively simple because the scope of EOF only makes changes to EVM execution. “We don’t need to worry about network interactions. We don’t need to worry about pairing with different CL/EL combinations. I don’t think we’re going to need the same level of devnets [and] testnets and that’s because of the way we’re going to be able to test it,” said Ferrin, adding, “We’re going to write explicit reference tests. … [Also], the big advantage we have is this differential EVM testing that has been going on.”
To conclude his presentation, Ferrin reiterated that he would like to see EOF included as the main code change in the Prague/Electra upgrade. He also said that he thinks it is feasible for the series of code changes for EOF to be tested and executed on mainnet three to six months after the Dencun upgrade is completed. The latest specifications for EOF can be found here. Open questions about these specifications have been compiled by the Ipsilon team here. There are components of EOF specifications that have not yet been fleshed out. Developers on the call were encouraged to chime in with their thoughts about the latest developments and specifications for EOF in the “#EVM” channel of the Ethereum Research and Development Discord.
EVM Object Format Debate
Ferrin’s presentation sparked lots of debate among developers. The main concerns shared by developers on the call about EOF were:
Timing: Several developers including Tim Beiko were hesitant about the three-to-six-month timeline for EOF implementation after the Dencun upgrade.
Urgency: The other main code change that developers are weighing for inclusion in Prague/Electra is Verkle. In early August, Ethereum Foundation developer Guillaume Ballet shared an update on progress for Verkle. Ballet emphasized on this week’s call that Verkle is a more urgent upgrade for Ethereum than EOF and therefore, should be prioritized ahead of EOF. Ballet did also mention that if the complexity of EOF could be reduced and the number of code changes simplified such that their implementation does not impact the timeline for Verkle, then he would be in favor of the upgrade.
Benefits: Developers such as Van der Wijden and Nethermind (EL) developer Lukasz Rozmej questioned the direct benefits of EOF weighed against the upgrade’s complexity. To concerns about the lack of a strong need for this large of a change to the EVM, Ferrin said the EVM was “written over the weekend” by Ethereum’s original team of developers and could use lots of improvement to ensure that the EVM remain competitive against new alternative Layer-1 blockchains such as Sui. “It’s not a security risk,” said Ferrin. “It’s more of an existential deal.”
Increase complexity and risk: Van der Wijden emphasized the ways in which EOF would increase protocol complexity and risk. There would be an increased burden on client teams who would have to maintain essentially two versions of the EVM and ensure the interdependencies between them are accounted for during future hard forks. Wijden argued that Layer-2 teams should not try to “push” the work of maintaining the EVM and EOF in parallel to client teams but rather work on implementing improvements to the EVM on their own protocol.
Backwards-compatibility: Another major concern about EOF is the way that EOF may introduce backwards-compatibility issues for legacy smart contracts. The way EOF has been designed will ensure that legacy smart contracts that do not use the EOF container will continue to be supported. However, there were suggestions from developers like Ferrin and Ethereum Foundation Researcher Ansgar Dietrichs to potentially deprecate legacy smart contract features over time and introduce upgrades exclusively to EOF moving forward.
EVM governance: Dietrichs also raised concerns about the implications of EOF on the governance of the EVM. Ethereum is evolving to support smart contract execution on alternative networks called Layer-2’s. Assuming a future where most user activity and smart contract execution occurs off-chain, and Ethereum is primarily used as a data availability layer, changes to the EVM should matter most to Layer-2 protocols, not Ethereum mainnet. Dietrichs recommended that developers carefully consider and discuss how changes to the EVM should be decided considering an expanding Layer-2 ecosystem.
Ferrin and others have been working on EOF since as early as 2021. EOF was rejected from the Shanghai hard fork earlier this year due to its multi-staged roadmap, which EOF champions have addressed by creating an updated design for the upgrade that would introduce all EOF-related changes in one large upgrade. However, the complexity of this upgrade is one of the major concerns about EOF that was raised on this week’s call. Rather than continuing to delay decisions about EOF, van der Wijden stressed that this time developers should carefully consider whether EOF should be implemented on Ethereum at all. “I know the Ipsilon team and Danno have spent a lot of time working on this and it’s quite harsh to say that after all this time we might not be shipping it but I think it’s even worse to say, ‘Let’s see,’ and then we push it another two years and we say, ‘Oh, we’re not going to ship it after all.’ So I think we should make a decision at Devconnect,” said van der Wijden, adding, “If it’s something we want, then we are going to do it except for like technical challenges, and if we’re saying this is something we don’t think is going to happen, it’s just fair for the team that has been working for all this time to have a clear decision from everyone.”
Rozmej added that alongside EOF and Verkle, developers should perhaps reconsider code changes like EIP 4444, to address the growing problem of historical chain data growth, which is growing at a rate of 20GB/month, according to Rozmej. Beiko agreed that developers should continue conversations about EOF, Verkle, and Prague/Electra at Devconnect. Beiko also highlighted that there will be a dedicated call for EVM-like Layer-2 protocols to encourage collaboration between these teams on Wednesday, October 18. There will also be EOF Implementor’s Call the same day. Finally, Beiko mentioned a dedicated Layer-2 day event at Devconnect organized by L2Beat.
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.