Ethereum core developers continue to grapple with the scope of the forthcoming Pectra upgrade, specifically the inclusion of EIPs related to the EVM Object Format (EOF).
Thursday’s All-Core Devs call was dominated by debate over the feature set due to concerns raised by Geth developer Marius van der Wijden.
In a recent blog post, van der Wijden laid out his case against EOF, concluding that “the drawbacks strongly outweigh the potential benefits.” In his view, the uncertainty around its efficacy, coupled with unknown security implications and other potential risks resulting from complexity, should merit removal.
It’s a bit of a reversal for the developer, who said in February he was “warming up to EOF,” despite his previous skepticism.
Read more: Ethereum devs consider ‘existential’ upgrade to the EVM
Now, however, van der Wijden says he wants to be on record as opposed to the change. “If we decide to do it, I don’t want to be held responsible for anything that happens,” he said.
Solidity developer Daniel Kirchner defended the upgrade on the call. “EOF is, for us and the stack below us, the superior design by orders of magnitude,” he said.
Layers below Solidity — the smart contract language for Ethereum — include the EVM, the bytecode it executes and, further down, components of the blockchain’s architecture that manage data storage, transaction execution and state changes.
One objection to EOF is that the current EVM will still need to be maintained in perpetuity, unless the Ethereum community can devise some mechanism for deprecating the legacy code.
“I personally would feel a lot better if there was a way to transition out of the legacy EVM,” Geth developer Péter Szilágyi said.
Developers generally rallied around the idea of figuring out a way to discourage contracts’ reliance on the current EVM — on a time horizon of five years or more.
The predominant view was that layer-2 projects such as rollups were not yet ready to take the lead on Ethereum innovation, largely because they still first and foremost value compatibility with Mainnet.
In other words, Mainnet “sets the defaults” for layer-2s, as Ansgar Dietrichs from the Ethereum Foundation put it.
“We have to acknowledge that we have overall responsibility for the EVM ecosystem, so I would still be very much in favor of bringing EOF to [layer-1],” Dietrichs said.
Szilágyi agreed. “It’s kind of the reality we’re in.”
Hope for the best, prepare for the worst
A thorough testing regime has always been a prerequisite for EOF adoption so as to prevent accidental incompatibilities with future upgrades. Developers want to avoid accidentally introducing incompatibilities with future upgrades like Verkle, which is expected to be the core component of the next hard fork, Osaka.
Van der Wijden, despite calling the testing team’s work “quite comprehensive” in his blog post, expressed doubts on Thursday’s call.
“These are incredibly complex changes in a very important part of Ethereum, and I don’t see it being tested super well,” van der Wijden said.
But Danno Ferrin, principal software engineer at Swirlds Labs, retorted that “it’s hard to test it super well when there’s only two complete implementations.” With more such implementations now available, there’s a clear path to more robust testing, he said.
Developers should not fear complex challenges, according to Andrew Ashikhmin, software engineer on the Erigon client team. “The Merge was also complicated, but we managed to pull it off, and I’m sure if we spend enough brain cycles and effort, we’ll pull EOF off as well,” Ashikhmin said.
Read more: Ethereum core devs chart an ambitious 2024
What should Ethereum be?
Pseudonymous Geth developer Lightclient questioned whether the direction of Ethereum Mainnet with EOF is correct in principle. “Should we be making [such] big changes to the EVM?” he asked rhetorically. “Why are we actively making [layer-1] more complicated for a proposal that is clearly not necessary to the survival of Ethereum?”
Others viewed competition in the layer-1 space as a threat to the long-term success of Ethereum.
Competition from other virtual machines necessitates innovation, the argument goes. “These are EVM chains we’re talking about,” Ferrin said. “The recommendation from smart contracting auditors are going to be ‘use a modern VM’ and if [layer-2s] use those modern VMs, then we’re draining a moat that keeps Ethereum being Ethereum,” he added.
Lightclient rejected that framing. “If a good virtual machine comes along that doesn’t start with ‘E’, then we should be very supportive of it,” he said.
This ties into a long-standing debate about the pace of innovation on Ethereum Mainnet. Should feature upgrades remain a priority at all? Or is a focus on simplicity, as a settlement layer with gradual ossification, a better goal?
Most core devs remain sympathetic to the former view. Dragan Rakita, from the Reth client team, said “if Ethereum wants to improve itself [and] improve [layer-2s], change needs to come from [layer-1].”
He argued the complexity is manageable. “EOF adds and extends an opcode set that [is] already present — it’s not introducing new complex logic to the legacy bytecode.”
But Marius, and to a lesser extent, other members of the Geth team, have basically drawn a line in the sand. They won’t block EOF, but warn their support will be limited.
“I’m kind of tired of arguing, to be honest,” van der Wijden said. “I’ve said my grievances multiple times and people still believe this is a worthwhile change that is worth taking the risk.”
What does that mean on a practical level? Ultimately, this dispute represents a real test of Ethereum’s decentralization in terms of how decisions are made, how bugs are found and squashed, and how teams respond when something unexpected happens.
“If it blows up on Mainnet, I will not stand up on Saturday at 2 am and try to fix it,” van der Wijden said.
