Ethereum All Core Developers Call #150 Writeup

On November 24, 2022, Ethereum developers gathered for their 150th All Core Developers (ACD) call. Chaired by the Ethereum Foundation’s Tim Beiko, the ACD calls are one of two bi-weekly meeting series where Ethereum developers discuss and coordinate changes to the protocol of Ethereum. This week, developers debated at length timing for Shanghai and what major EIPs should be included in Shanghai. Developers ultimately did not reach a consensus about whether other EIPs like EIP 4844 and the five EIPs related to EOF implementation should go into Shanghai at the expense of delaying the upgrade by a few months. At a minimum, developers did agree that without the inclusion of other major code changes, the core EIPs for Shanghai which include staked ETH withdrawals (the core Shanghai EIPs are listed here) could be activated on Ethereum as early as March 2023.

Ethereum Testnet Lifecycles

Former release manager at Parity Technologies, Afri Schoeden, presented his proposal to limit the lifetime of a public Ethereum test network to four or five years. Schoeden explained sticking to a predictable timeline for deprecating public testnets would help application developers and infrastructure providers by guaranteeing availability of public testnets for at least four years from genesis before being deprecated. In preparation for the Merge upgrade, several Ethereum testnets were launched and deprecated on an ad hoc basis. This has created frustration for application developers and infrastructure providers that according to Schoeden need around six months’ notice to migrate their code to a different testnet.

The discussion around testnets is particularly pressing for Ethereum developers right now because of the supply issues on a popular Ethereum testnet known as Goerli. Applying Schoeden’s timetable for Ethereum testnets would mean that Goerli is shutdown by the end of 2023 and a new testnet is launched around that same time. Similarly, Sepolia, which is a testnet with a permissioned validator set that launched in 2021, would be deprecated by Q4 2026. Schoeden urged Ethereum core developers on the call to speak up if the cadence he proposed for launching and deprecating testnets should be modified.

On the topic of Ethereum testnets, Chair of the ACD calls Tim Beiko proposed shutting down the Ropsten testnet for good over the holiday break. Since this call, Beiko has published a blog post announcing the deprecation of Ropsten more formally. The post includes a link to Schoeden’s proposed lifecycle for Ethereum testnets moving forward and encourages readers to weigh in about the future of public Ethereum testnets. Finally, Mario Havel from the Ethereum Foundation’s Protocol Support team mentioned he is working on building a new Ethereum testnet that automatically restarts back to genesis after a set period. Havel encouraged developers on the call to contribute to the project and provide feedback.

Shanghai organization

After the discussion on testnets, Beiko steered the conversation towards planning for Ethereum’s next major upgrade dubbed Shanghai. Beiko’s goal for the conversation during this call was to clearly outline which Ethereum Improvement Proposals (EIPs) should be “Considered for Inclusion” (CFI’d). However, Beiko also noted that the meaning behind an EIP being CFI’d does not guarantee the EIP’s inclusion in Shanghai. It simply means that developers are seriously considering the code change for a potential upgrade in Ethereum’s future and are testing the code change on devnets, developer-focused test networks. By this definition, multiple EIPs could be automatically considered CFI’d then including the EIPs related to EOF implementation and proto-danksharding, which are explained in more detail here.

It is unclear how debating which EIPs are CFI are helpful to scoping out Shanghai given that there is no clear intention to include all CFI’d EIPs into Shanghai. Founder of Ethereum Vitalik Buterin argued that the CFI label is a strong signaling mechanism that could help the broader Ethereum ecosystem better prepare for upcoming changes. Senior Director of Engineering at Coinbase, Jesse Pollak, echoed this sentiment explaining that many people who do not regularly listen to the developer calls are unaware about the roadmap and priorities for Ethereum. A clear delineation of which EIPs are ready to be executed against through the CFI label is helpful, Pollak argued, for companies like Coinbase to know how to best dedicate resources to help the Ethereum development roadmap.

Throughout the call, there was still confusion around the exact definition of CFI and pushback to broadening the definition of CFI to mean a code change that developers are seriously considering for a potential upgrade in the future. What some core developers proposed on this call was to create a CFI list for Shanghai and a CFI list for Cancun. Cancun is the name of the Ethereum upgrade scheduled for after Shanghai. Doing this would help differentiate what code changes are being tested for inclusion in Shanghai and which are being tested for a future upgrade after Shanghai. Ultimately, Beiko wrangled consensus for making EIP 4844, the five EOF-related EIPs, and EIP 2537 as CFI primarily based on the fact that these EIPs are already being tested on devnet and client teams are dedicating resources to testing these code changes already.

The meaning behind CFI is no longer that a code change is final and ready for implementation in the next Ethereum upgrade. The meaning behind CFI now remains unclear and likely unhelpful for Shanghai planning. That said, developers still discussed planning for Shanghai intermittently throughout the discussion around what is and is not considered CFI.

EOF Implementation

First, developers discussed EOF implementation for Shanghai. As background, EOF stands for Ethereum Virtual Machine Object Format and essentially introduces a new version of the Ethereum Virtual Machine. During prior conversations, developers had agreed that the EIPs related to EOF should be introduced all at once, instead of piecemeal. As for all five EOF-related EIPs has progressed, developers like Andrew Ashikhmin from the Erigon (EL) client team have emphasized the need for the Solidity language team to implement these code changes so that application developers and infrastructure providers can take advantage of the EVM-related changes. Given the work that still needs to be done for EOF implementation by client teams and the Solidity team, Ashikhmin was in favor of delaying EOF to Cancun.

Ethereum Foundation developer that goes by the pseudonym of “lightclient” was opposed to delaying EOF to Cancun arguing that if the code change was not going to be included in Shanghai, there is little chance of it going into Cancun. “If it doesn’t go in Shanghai, it’s increasingly unlikely it goes into a future fork. I think we have big upgrades that we want to do in many of the next forks and it’s always going to be this debate of this is the important thing, we want to make the fork small, we want that thing to go in because it’s important for the roadmap, whatever,” said lightclient. Marius van der Wijden of the Geth (EL) client team pushed back on lightclient’s comment saying that if there was little confidence for EOF to make it into Cancun, there shouldn’t be greater reason to include it in Shanghai.

The Solidity team represented on the call also expressed frustration at Ethereum core developers trying to delay EOF implementation because the Solidity team had not yet fully completed their implementation of the five EIPs. Alex Beregszaszi, Lead of the Solidity team at the Etheruem Foundation, explained that the Solidity team is working on an implementation that is slated for completion before December 25, 2022. “At the same time, the core developers have said that [EOF implementation] wouldn’t break anything and that this should work. Now, you’re basically doubting the understanding of both the compiler and the EVM and just generally, when there’s zero agreement about whether something is useful or not from this group, that is a signal for people like Solidity not to do anything with it because also their time is very limited,” said Beregszaszi on the call, adding, “That’s why Solidity hasn’t implemented it because they also have a lack of people and they have to prioritize things.”

Disabling Self-Destruct

Developers also discussed EIP 4758, which deactivates the “selfdestruct” opcode on Ethereum. Rob Montgomery, CEO of Revest Finance, explained how deactivating this opcode would break his application and others like it. “The proposed change unfortunately bricks our contracts and results in hundreds of thousands to millions of dollars being permanently locked,” said Montgomery. Montgomery added that if developers can create an edge case to protect the functionality of his contract and others like it, he would be in favor of the EIP. Going back to the discussion around CFI, Ansgar Dietrichs, Ethereum Foundation Researcher, said that EIP 4758 should not be considered CFI until the edge case for protecting contracts like the one Montgomery built is properly scoped out.

Dankrad Feist, Ethereum Foundation Researcher, was wary about changing EIP 4758 to address edge cases like the one presented by Montgomery. “I think this will be much more complicated than people imagine,” said Feist. Ashikhmin pushed back on Feist’s comment saying that even if it is complicated, backward-compatibility should be prioritized on Ethereum. Lukasz Rozmej of the Nethermind (EL) client team also agreed with Ashikhmin saying that scoping out this edge case for EIP 4758 is complicated but makes Ethereum more reliable in the long term. “That’s the life of supporting a low-level system that a lot of higher-level systems are built upon,” said Rozmej.

Shanghai Timing

After the prolonged discussion on which EIPs should be considered CFI, developers started to discuss in earnest timing around Shanghai and what EIPs should be considered for Ethereum’s next major upgrade. Terence Tsao from the Prysm (CL) client team re-emphasized the importance of shipping staked ETH withdrawals as soon as possible. To that end, Tsao said that EIP 4844 should not be included in Shanghai and that other client teams should not redirect resources away from preparing withdrawals to prepare EIP 4844 or other major EIPs. Other core developers such as Teku’s Ben Edgington agreed with Tsao, saying that EIP 4844 in his opinion would “inevitably delay Shanghai” and therefore should be pushed to a separate upgrade after staked ETH withdrawals are enabled.

If staked ETH withdrawals are the only major code change included in Shanghai, developers agreed that Shanghai could be shipped as early as March 2023. The consensus among developers representing Ethereum Consensus Layer clients was to exclude EIP 4844 so as not to delay withdrawals in the next Ethereum upgrade. The consensus among other developers on the call was not as clear. Lightclient and van der Wijden were in favor of including EOF implementation in Shanghai along with withdrawals. Diederik Loerakker, more popularly known as “Protolambda”, who is a developer for OP Labs, pushed back on the consensus to delay EIP 4844 to an upgrade after Shanghai. “By basically creating a zero-sum game between EIP 4844 and EOF EIPs, we basically ruin the roadmap of Ethereum by not listening enough to outsiders of this call and by setting priorities based on development, rather than based on the pressures of the Ethereum network.” Ansgar Dietrichs agreed with Proto, saying that he was in favor of having one combined fork if the delay to adding EIP 4844 was only around three months.

To be clear, developers had already discussed in a prior call the merits of planning one big upgrade on a longer timeline than multiple smaller upgrades on a relatively faster cadence. At the time, developers leaned towards executing a larger upgrade as the realities of testing and reaching consensus around an upgrade, no matter how small, is still extremely difficult. During this call, developers backtracked and argued that there has been one time when Ethereum successfully executed two upgrades in quick succession. Beiko pointed out that the Berlin and London upgrades were executed less than four months apart from each other. By this logic, van der Wijden agreed that the capabilities of Ethereum core developers to ship upgrades faster have “improved quite a bit” over the years especially in the testing department.

Ultimately, developer did not make a clear decision about whether to bundle staked ETH withdrawals with other major EIPs, be it EIP 4844 (this does not seem likely anymore), EOF implementation, BLS signatures, or disabling self-destruct. However, most developers did agree that the addition of another major code change in addition to withdrawals would mean that Shanghai does get delayed beyond March 2023. The question remains whether a delay to Shanghai, that is effectively the activation of staked ETH withdrawals, is acceptable in the eyes of the Ethereum community for a faster implementation of other major network changes. Speaking to the importance of EIP 4844, CEO of OP Labs Liam Horne said, “EIP 4844 is not just a win for rollups. It’s a win for Ethereum because all these projects and these users that are going to other ecosystems will have no reason to because Ethereum’s ecosystem will offer the exact same price at the Ethereum security that we’re already familiar with. I’m saying the obvious, but I think it matters quite a lot.

Because the ACD call ran over the usual duration of an hour and a half, Beiko mentioned that a few other agenda items would have to be pushed to the next call. Namely, the discussion around improvements to Ethereum’s Engine API and updates to the testing around staked ETH withdrawals, which van der Wijden quickly noted at the end of the call is now being tested on a devnet with five different clients. Finally, one housekeeping item that Beiko mentioned at the beginning of the call is that the next ACD call, scheduled for December 8th, 2022, will be the last one of the year. The ACD calls will resume sometime in January 2023.