Ethereum All Core Developers Execution Call #192 Writeup

On July 18, 2024, Ethereum protocol developers met virtually over Zoom for All Core Developers Execution (ACDE) Call #192. 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 had a lengthy discussion on the inclusion of EOF in Pectra. Geth developer Marius van der Wijden expressed strong opposition to EOF code changes due to their complexity and implementation risk. Developers also debated the merits of new proposed changes to EIP 7702. No decisions were made on either of these topics.

Developers agreed to continue working through the issues presented about EOF and EIP 7702. Near the end of the call, Beiko highlighted three additions to Pectra that he'd like developers to review over the next few weeks. There were no updates on EIP 4444.

Pectra Devnet 1

A developer with the screen name "pk910" representing the EF Developers Operations team shared updates on Pectra Devnet 1. Since the launch of Devnet 0 in May, client teams have faced setbacks preparing new implementations for Devnet 1. Pk910 said that all client teams are now ready with new implementations. Each of these implementations have been tested locally by the EF DevOps team. Most issues identified from testing have since been resolved. The Prysm and Erigon teams are still working on fixes. Developers aim to launch Devnet 1 next Thursday, July 25 with all clients.

EOF Concerns

EOF stands for Ethereum Virtual Machine Object Format. As discussed in prior notes, EOF represents a bundle of code changes that will improve the functionality of smart contract code execution. It is the first major change to the Ethereum Virtual Machine (EVM) that developers have prioritized in an upgrade since Ethereum was launched in 2015. However, in lieu of incremental changes to the EVM over the past nine years, EOF bundles together 11 different code changes in one upgrade.

On Friday, July 12, Geth developer Marius van der Wijden shared a written statement on his concerns about EOF and its complexity. He raised his concerns again in this week's developer call. He said, "I would like to make it very clear that I'm not for this change. I think it's risky, and I think the risks outweigh the benefits, and if we decide to do it then I don't want to be held responsible for anything. … If we decide to do it, I will provide the code for Geth, but I don't want to be involved in anything. If anything breaks or if mainnet goes to a shit, I have a clear conscience."

Daniel Kirchner, a developer on the EF Solidity team, pushed back on Van der Wijden's comments, saying that he was strongly in favor of EOF and that EOF is a "superior design by orders of magnitude" to the current version of the EVM. When asked by Van der Wijden how the Solidity team would handle supporting two versions of the EVM, Kirchner replied that initially, his team would maintain support for both the legacy compiler version and EOF, but over the long-term he would prefer to support only the EOF version once "the community has caught up with the change."

Kirchner added that in his view implementing EOF on Ethereum could have major benefits for Layer 2 rollups (L2s). He said, "If you want to have layer 2 innovation and want to facilitate that, putting EOF on layer one is probably the missing link that actually makes it possible to import the entire ecosystem to layer two while still innovating on it without losing the entire infrastructure that's built for L1."

Kirchner's comments on the impact of EOF on L2s sparked debate on the role of Ethereum in a rollup-centric future. EF Researcher Ansgar Dietrichs wrote in the Zoom chat that leaving innovations like EOF for L2s to implement on their own is problematic given that the "L1 still sets the defaults for the ecosystem." Prysm developer "Potuz" agreed with Dietrichs saying that L2s are "skeptical" of adopting code changes that would be incompatible with the EVM.

Geth developer "Lightclient" wrote in the chat, "Ultimately, I think L1 should be as simple as possible and EOF is not compatible with that." He added that in his view L1 and L2 infrastructure must diverge eventually. Later in the call, he said, "I would rather us focus at L1 on doing things that are necessary to the survival of Ethereum, [like] reducing the size of L1 clients, making it easier for people that run L1 clients. We as a core [developer] group said that we want to focus on being a settlement layer and allowing L2s to take the baton on developing execution layer for Ethereum. Yet, we are trying to essentially plan the future for them. I don't think that's our place. I don't think that is useful for the future, for Ethereum."

Then, independent Ethereum protocol developer Danno Ferrin argued that making improvements to the EVM was necessary to Ethereum's survival. He pointed out that Ethereum has a moat to defend when it comes to the adoption of the EVM. Lightclient pushed back saying that the adoption of other virtual machines should not be discouraged. Van der Wijden also chimed in saying that no number of EOF-like changes to the EVM in his view would prevent the adoption of other more performant virtual machines. Even so, Dietrichs asserted that in the short-term, Ethereum "sets the default for L2s" and that supporting new features like EOF would have major benefits not only on the L1, but also on L2s. Representatives from the Besu, Reth, Erigon, and Nethermind client teams also chimed in to the discussion to express their support for EOF and its continued testing in the Pectra upgrade.

Nethermind developer Lukasz Rozmej said that developers could reassess their confidence in EOF in a few months after more time to test the code changes. On the topic of supporting multiple versions of the EVM in client software, Geth developer Péter Szilágyi said that finding a path forward to deprecate use of the legacy EVM before implementing EOF would be ideal to avoid added complexity to the Ethereum codebase.

There was continued disagreement on the call, primarily between Geth and the other client teams. Beiko recommended time boxing the discussion and simply moving forward with the inclusion of EOF in Pectra for now. "If we get to the point where we're close to shipping the fork and we feel uncomfortable with the safety of EOF, we keep finding bugs that we don't think we're going to fix in time, then we should reconsider having it in the fork," said Beiko.

EIP 7702 Proposed Changes

Ankit Chiplunkar, a researcher for Frontier Tech, proposed changes to the design of EIP 7702. These changes were workshopped at WalletConnect, a conference for wallet developers hosted during the week of EthCC 2024. They aim to extend the use cases for EIP 7702 and enhance the EIP's security by introducing a new opcode to the design, the CODERESET opcode. The proposal was shared last Thursday, July 11 and since then, other developers have chimed in on the changes to EIP 7702.

Otim Labs, a crypto project in stealth mode, wrote in a post expressing their opposition to the proposed changes, "As much as it would make sense from a business standpoint, we do not want EIP-7702 tailored to our specific needs. We want these changes to be open-ended enough such that people can innovate and new things can be built. … Adding a new set of requirements at this late stage jeopardizes this EIP's inclusion in Pectra. Adding restrictions narrows the design space unnecessarily."

Julian Rachman, COO of Otim Labs, reiterated the above sentiments on the call. Agreeing with them, Elias Tazartes, CEO of Kakarot zkEVM, wrote in the Zoom chat, "We have no idea what users like and will adopt. It's weird to ship a UX improvement top down, without any feedback from users or iteration loop." Chiplunkar said that his proposal was meant to surface the concerns of many wallet developers about the current design of EIP 7702 and offer one suggestion. He emphasized that he was not trying to push a change to EIP 7702 specifications post haste and that he would be happy to continue discussing paths forward for the EIP on Discord or through another EIP 7702 break out meeting.

Lightclient also chimed in to explain the rationale behind the current EIP 7702 design. As background, user-controlled accounts on Ethereum are called externally owned accounts (EOAs). "This is something that just reopens the concerns we had around EOA migration, specifically, like, how do you deal with the fact that a user might think that they've migrated their wallets to a more secure access control policy, yet the private key still is able to sign messages that are accepted on chain. … It felt like the right thing to do would be to give users the sort of hybrid ability to both be a smart contract as a smart contract wallet, in some cases, but always have the EOA private key as the master control for the account," said Lightclient, adding that the proposed changes unnecessarily add complexity to the EIP and for "business use cases" that are not critical to the motivation behind the EIP in the first place.

Developers on the call could not reach a consensus about Chiplunkar's proposed changes to EIP 7702. Beiko recommended that the discussion continue asynchronously from the call on Discord. Before moving on from the discussion, Richard Meissner, co-founder of Safe, expressed his concerns about the changing specifications of EIP 7702. "I come from the smart account perspective, so actually, I would be happy with this [EIP], but I'm more concerned about the timeline. Actually, for me, it's really like moving specs and changing the specs constantly makes it very hard to build tooling. … It's very hard to reason how the current EIP would turn out," said Meissner.

To this, Beiko reiterated the next Pectra devnet, Devnet 1, which could go live next Thursday, will feature a version of EIP 7702 that application developers can reference. However, he admitted that the specifications could change on future devnets after testing and further discussion. "I know that's not like ideal in terms of just building tooling on it, but I think in terms of shipping the fork as a whole, that's the best we can do," said Beiko.

Additions to Pectra

Due to limited remaining time on the call, which is usually capped at an hour and half, Beiko recommended that presenters for the remaining agenda topics share their ideas or asks and follow-up asynchronously for discussion on Discord.

First up, Lightclient resurfaced the idea of deploying system contracts with an event log for Pectra devnets moving forward. More information on this change can be found here. Second, Beiko highlighted a new EIP for inclusion in Pectra. EIP 7742 updates how the blob target per block is calculated such that the target value is dictated by the consensus layer, as opposed to being hard coded on the execution layer. Third, Ulas Erdogan, founder of Clave, proposed the inclusion of RIP 7212 in Pectra. RIP 7212 is a proposal to create a new precompile that performs signature verifications in the "secp256r1" elliptic curve. It has already been implemented on various L2s and Ethereum client teams. Beiko noted that before a decision is made on either EIP 7742 or RIP 7212, developers should focus on shipping Pectra Devnet 1 and working on both EOF and EIP 7702.

There were no updates on EIP 4444.

Public link

Please use the above public link if you want to share this noodl on another website.