skip to content

Ethereum All Core Developers Call #148 Writeup

Ethereum ACD Call -92

After a month-long hiatus, Ethereum developers gathered for their 148th All Core Developers (ACD) meeting. Chaired by the Ethereum Foundation’s Tim Beiko, these ACD calls are one of two recurring meeting series where developers plan and coordinate protocol-level upgrades to Ethereum. This week, developers discussed priorities for Ethereum’s next planned upgrade dubbed Shanghai. Developers agreed that at a minimum, testing for Shanghai would include staked ETH withdrawals and three other minor network optimizations. In addition, developers agreed to continue scoping out Ethereum Improvement Proposal (EIP) 4844 and Ethereum Virtual Machine Object Format (EOF) code changes for potential inclusion in Shanghai as well.

Shanghai Planning

The core EIPs that developers largely agreed should be prioritized for Shanghai were:

  • EIP 4895: Supporting validator withdrawals from the Beacon Chain through the creation of a new system-level operation type

  • EIP 3860: Limiting the maximum size of initcode, which is the code that creates bytecode, and applying extra gas cost for its growth on-chain

  • EIP 3651: Starts the coinbase address, that is the address receiving the block reward, warm such that it does not cost more in gas fees to access the address

  • EIP 3855: Introduces a new instruction called “PUSH0” that pushes the constant value of 0 to help reduce smart contract code size

In addition to these core EIPs, developers agreed that two other potential categories of code changes that may be included in some form for Shanghai are proto-danksharding and the implementation of EOF.


Also called EIP 4844, proto-danksharding introduces a new transaction type to Ethereum for settling batches of transactions from Layer-2 rollups in a cost-effective way. Representatives from the Besu and Nethermind (EL) client teams expressed concern on the call about the readiness of EIP 4844 for implementation, saying that the complexity and scope of the code change had not yet been sufficiently defined. Lukasz Rozmej from Nethermind said the code change may create “a lot of tension and uncertainty” for his team if the specifications for proto-danksharding are subject to change. To this, Ethereum Foundation researcher Ansgar Dietrichs said that final decisions for the scope of EIP 4844 could be made in the next four weeks. Dietrichs emphasized that only small questions remain around the implementation of proto-danksharding and “if there was a desire to, we could make a final call [soon.]”

Implementation of EOF

The implementation of EOF is essentially an upgrade to the Ethereum Virtual Machine, which is the execution environment that deploys smart contracts on Ethereum. It introduces a new version of the EVM that better distinguishes code from data and in this way introduces significant gas savings for contract deployment, among other benefits. Formatting contracts for a new version of the EVM requires several code changes, only two of which, EIP 3540 and EIP 3670, were originally slated for inclusion in Shanghai.

On the call, Geth developer Marius van der Wijden expressed concern about partially implementing EOF through only a subset of EIPs in Shanghai. This would mean that developers must maintain backwards compatibility with several versions of the EVM if the implementation of EOF happens in a piecemeal fashion. “We can very easily shoot ourselves in the foot with this,” said van der Wijden. Tomasz K. Stanczak of the Nethermind team agreed that EOF formatting should not be “rushed to mainnet.” Andrew Ashikhmin of the Erigon team and Dankrad Feist of the Ethereum Foundation also agreed saying that it would be ideal to implement all EOF-related EIPs in one go rather than across multiple hard forks. To this, Alex Beregszaszi, one of the main EIP authors pushing for the implementation of EOF in Shanghai, did agree that only implementing part of EOF in Shanghai would be significantly less valuable than the full set.

Disabling Self-Destruct

There was also some discussion around the addition of EIP 4758 to Shanghai. This code change deactivates the “selfdestruct” opcode on Ethereum. As explained on the call by Geth developer Peter Szilagyi, selfdestruct is one of the last opcodes on Ethereum that has a fixed gas cost but can contain an unlimited storage cost on the network. It has been labelled as an opcode that smart contract developers should avoid using under most circumstances. However, as mentioned by Micah Zoltu, there is a prominent decentralized application that does rely on this opcode and would not be in favor of deactivating the selfdestruct in Shanghai. To this, Ethereum Foundation’s Jared Wasinger said that he would investigate ways in which EIP 4758 could be included in Shanghai in such a way that it addresses concerns of breaking functionality in existing Ethereum smart contracts.

Shanghai Testnets and Timing

Based on the discussion, Tim Beiko suggested the creation of a core Shanghai test network that would include the basic code changes such as staked ETH withdrawals slated for activation in the next network upgrade. Those EIPs include EIP 4895, 3860, 3651, and 3855. For reference, there is already a bare bones test network known as Shandong that has been launched by the Ethereum Foundation JavaScript Team. It implements all five EIPs in addition to a few EIPs related to EOF implementation.

In parallel to these efforts, Beiko suggested the creation of two other test networks: one dedicated to the continued development of EIP 4844 and the other dedicated to the full implementation of EOF. In this way, Ethereum client teams can focus on preparing the core components of the Shanghai upgrade and down the road, after further scoping of proto-danksharding and EOF, the code changes for either of these initiatives can be added to the main Shanghai test network if developers agree that they are ready for implementation on mainnet.

Developers also discussed the approach of splitting up Shanghai and its core components into multiple smaller upgrades, rather than one large one. A representative from the Teku (CL) client team expressed his preference for enabling staked ETH withdrawals first and EIP 4844 in a latter upgrade. This would give time for CL client teams to focus on cleanups and refinements to the Ethereum Beacon Chain post-Merge before focusing on the addition of new several new features. However, Geth developer Peter Szilagyi pushed back on this idea, explaining that developers had been trying to execute smaller hard fork upgrades on Ethereum on a quicker cadence but the realities of testing and reaching consensus for even a small upgrade makes it extremely difficult to shorten the cadence of hard forks on Ethereum meaningfully.

“Sometimes it’s worth cramming one more feature than to wait it out,” said Szilagyi on the call. Echoing the thought, Geth developer Marius van der Wijden explained that executing a hard fork only with staked ETH withdrawals could mean that Shanghai Part One happens in February and Shanghai Part Two, which focusses exclusively on proto-danksharding, happens sometime in September. Bundling these two upgrades together, according to van der Wijden, would mean that Shanghai could happen sometime in June or July. As such, while van der Wijden prefers smaller hard forks in theory, he admitted that a larger upgrade makes more sense on Ethereum for the sake of accomplishing more in the same time frame.

Shanghai Fork Activation

Developers then briefly discussed the activation process of Shanghai. As background, Ethereum hard forks have historically been activated on a predetermined block height. However, for the Merge upgrade in September, Ethereum’s transition to a fully proof-of-stake consensus protocol was activated by a terminal total difficulty threshold. Read more about the activation process for the Merge here. Now that the Ethereum network has fused together with the Beacon Chain, upgrades to the CL of Ethereum will be activated at a predetermined epoch number, which can be calculated and expressed in a timestamp format. As such, for upgrades impacting both the EL and CL of Ethereum, there was discussion about activating upgrades on the EL of Ethereum through timestamps instead of a block height. While some developers were in favor of this, it was clear that more testing around the edge cases for activating upgrades on the EL of Ethereum through a timestamp is needed. As such, Tim Beiko suggested further experimentation on the Shanghai core test networks of this fork activation strategy in the coming weeks.

Beiko also highlighted that EIP authors would be able to join forthcoming ACD calls to present their thoughts on other code changes that client teams should consider for inclusion in Shanghai outside of the ones mentioned on this week’s call.


Finally, developers raised three other minor topics on this week’s call.

  • Marius raised a minor change to the Ethereum Wire Protocol which defines request and response messages for exchanging data between Ethereum clients. Marius proposed the addition of a message standard for communicating new transaction types and sizes between clients. This is an important update to the Ethereum Wire Protocol for enabling proto-danksharding.

  • Tim Beiko made a call for client teams to review a change to Ethereum’s Engine API, which dictates communication between EL and CL clients. This change would enable validators to easily compare the value of a locally built block with the value of a block built by a third-party block builder. This is a code change that will be discussed in more detail during next week’s CL call.

  • Afri Schoeden, one of the developers maintaining the Ethereum test network Goerli, expressed concern over the supply of Goerli testnet ETH. Schoeden explained on the call that at present, it is easier for users to buy Goerli testnet ETH than simply to receive it from a faucet, meaning a dedicated channel for issuing testnet ETH supply. There are a number of solutions Schoeden has proposed to this issue of testnet ETH supply on Goerli that will be discussed during a public community call next Tuesday, November 1. Schoeden encouraged client teams to review his post and attend the call.