Learn about the potential updates of Ethereum Shanghai upgrade in one article

Original title: 《 Ethereum All Core Developers Call #149 Writeup 》

Original author: Christine Kim

Original translation: Overnight porridge

On November 10, 2022, Ethereum developers gathered for the 149th All Core Developers (ACD) call, hosted by Tim Beiko of the Ethereum Foundation. This week, developers discussed the progress of code changes related to the EVM Object Format (EOF) and proto-danksharding to achieve the first major upgrade of the merged Ethereum network (called Shanghai). During this call, developers also discussed four other EIPs that may be included in the Shanghai upgrade. While each proposal does bring some unique advantages and benefits to Ethereum, there is still a lot of controversy among developers about which EIPs to prioritize for inclusion. In addition to the discussion of the Shanghai upgrade, developers also briefly touched on the topic of censorship resistance and the potential trade-offs of Ethereum's censorship resistance for the sake of network scalability.

Shanghai Upgrade Plan

In a previous ACD call, Ethereum developers agreed to a core list of EIPs to include in the Shanghai upgrade. The full call transcript from ACD Call #148 is here . Notably, from this core list of EIPs, developers agreed to include the pledged ETH withdrawal proposal in the Shanghai upgrade, but did not commit to including EOF or proto-danksharding in the same upgrade until the code changes for the latter two proposals were further fleshed out. On the topic of EOF in particular, developers have been hesitant about whether to partially implement EOF through a small number of EIPs in the Shanghai upgrade, or to try to bundle the entire vision of EOF in the Ethereum upgrade after Shanghai.

EOF Implementation

Danno Ferrin, Hedera Chief Software Engineer, updated on this week's call regarding the progress of the Shanghai EOF implementation. He explained that developers tend to bundle most of the EIPs related to EOF implementation into one large upgrade as early as possible. The EIPs related to EOF implementation that developers are considering for inclusion in the Shanghai upgrade are EIP 3540, EIP 3670, EIP 4200, and EIP 4750. There is still disagreement among developers on whether EIP 5450 should be included in the list of code changes related to EOF.

Andrew Ashikhmin of the Erigon Execution Layer (EL) client team also expressed concerns about whether the Solidity smart contract language team will be able to fully support and implement all four (or possibly five) EIPs. Ashikhmin stressed that before committing to activating these EIPs in the Shanghai upgrade, it is necessary to first confirm that the Solidity team is ready for these EIP implementations. Ashikhmin said on the conference call that this is "a necessary sanity check," and Marius van der Wijden of the Geth EL client team agreed.

Proto-danksharding

The developers then went on to discuss the latest developments in proto-danksharding. Unlike the EOF implementation, there is only one EIP associated with proto-danksharding code changes, namely EIP 4844. According to Diederik Loerakker (often referred to as "Protolambda"), a researcher at OP Labs, there are still some items related to EIP 4844 that are being discussed. Ansgar Dietrichs of the Ethereum Foundation added that some of these items are related to setting a minimum price for blob transactions and reducing the blob transaction throughput of the Shanghai upgrade. These to-do items are summarized on Github .

Disable the Self-Destruct opcode, and potentially other EIPs

While developers prepare for the EOF and proto-danksharding work for the Shanghai upgrade, developers have tentatively agreed to continue working on four other EIPs to be included in Ethereum’s next upgrade.

1. EIP 4758 , disabling the "selfdestruct" opcode on Ethereum: Developers revisited the conversation in the last ACD call about disabling opcodes, which are widely considered by developers to be a bad practice for use in smart contracts and decentralized applications (dapps). This opcode is one of the few legacy opcodes that have a fixed gas cost for deployment, but the network's storage cost may be unlimited. Independent developer Micah Zoltu reiterated that some active smart contracts on Ethereum are still using the selfdestruct opcode, and disabling it will break functionality. Tim Beiko said that there may be some workarounds for these special edge cases, and more community expansion from the Ethereum Foundation is needed.

2. EIP 1153 , the addition of temporary storage opcodes: Representatives from the Uniswap and Optimism teams made a compelling case to introduce temporary storage opcodes, which behave the same as regular storage opcodes on Ethereum, except that the values ​​of the two new opcodes, TLOAD and TSTORE, will be discarded after each transaction. There are many motivations for transient storage, one of which is saving gas costs, as explained by Mark Tyneway of Optimism. On Uniswap alone, this EIP has the potential to save users $3 million in gas costs per year. In addition, using temporary storage instead of regular storage will help reduce Ethereum's technical debt. The Uniswap and Optimism teams did a lot of work to help create implementations of this code change in multiple different Ethereum software clients and built a comprehensive test suite for the EIP. Daniel Lehrner of the Besu (EL) client team expressed his gratitude for the call for external developers to prepare for the implementation of EIP 1153. Even so, not all developers believe that the additional testing load that comes with incorporating EIP 1153 is worth it. Geth developer Marius van der Wijden warned that EIP 1153 could interfere with ongoing preparations for EOF-related EIPs and create complications. Still, van der Wijden said he was still taking a "wait-and-see approach" about increasing testing work on code changes. The developers agreed to continue testing EIP 1153 with the help of external developers from the Uniswap and Optimism teams for its inclusion in the Shanghai upgrade.

3. EIP 2537 , adding BLS precompilation: Alex Stokes of the Ethereum Foundation introduced the advantages of adding BLS precompilation to Ethereum. Stokes explained that there are many reasons for this, including the ability to create more secure cryptographic proofs, better interoperability with the Ethereum beacon chain, and the added functionality of decentralized staking pools. Van der Wijden agreed that adding BLS precompilation is an important code change that may even take precedence over EOF implementation and EIP 1153. However, due to the extensive testing required to implement EIP 2537, van der Wijden expressed his concern that adding this code change would delay the Shanghai upgrade. Jared Wasinger of the Ethereum Foundation mentioned that he is working on a parallel EIP that could provide a simpler implementation path than EIP 2537. The developers agreed to study EIP 2537 and begin to reduce the number of different BLS precompilations for possible inclusion in the Shanghai upgrade.

4. EIP 2294 : Finally, Zainan Victor Zhou, a software engineer at Google, introduced EIP 2294, which has a relatively simple code change that simply limits the byte size of Ethereum's chain ID field, which is traditionally used to help node discovery after a hard fork. Victor Zhou said on the conference call that the use case of chain ID will become larger and more important due to the possibility of sharding and multi-chain in Ethereum in the future. In order to prevent people from trying to store other types of data in the chain ID field to exploit the field, Victor Zhou called for explicit binding of the chain ID size. All developers agreed that this change is important and easy to implement. Micah Zoltu emphasized that such a code change only requires a soft fork, which means that Ethereum client teams can implement the changes on their respective timelines without coordinating a specific block height for the change. There was also some discussion among developers about whether to limit the chain ID size to 64 bits or 256 bits at the end of the call. Tim Beiko encouraged developers to discuss offline and work out the numbers asynchronously in the Discord chat.

Based on the growing list of EIPs planned for inclusion in the Shanghai upgrade, developers are divided over which EIPs to prioritize for inclusion outside of the core list. An Ethereum Foundation developer who goes by the pseudonym "lightclient" proposed sticking with open withdrawals and prioritizing only one other major EIP, whether it's proto-danksharding, EOF implementation, or one of the four EIPs raised on the call. Tim Beiko believes that it's unrealistic to try to bundle EOF implementation, proto-danksharding, BLS precompile, and adding temporary storage opcodes in the next upgrade. Due to lack of meeting time, Beiko brought up the discussion of Shanghai upgrade planning and encouraged developers to prepare to discuss the highest priorities of the Shanghai upgrade other than staked ETH withdrawals during the next ACD call.

How to reduce the operating cost of Ethereum nodes (increase censorship resistance)?

During the talk about the Shanghai upgrade, independent Ethereum developer Micah Zoltu raised an important topic of discussion about Ethereum censorship resistance. Zoltu explained that almost no Ethereum users run their own nodes to execute transactions, and people rely on centralized services such as Infura or Alchemy, which actively censor users from specific countries and censor decentralized applications (dapps) on Ethereum, such as Tornado Cash. Although developers are working to improve Ethereum's scalability through EIP 4844, there is a lack of effort to reduce the cost of running Ethereum nodes and encourage greater Ethereum censorship resistance. Mikhail Kalinin, a developer on the Ethereum Teku (CL) client team, proposed focusing on reducing the cost of running Ethereum nodes after implementing EIP 4844. Andrew Ashikhmin from Erigon believes that Ethereum developers can focus on both at the same time. And Ansgar Dietrichs said that for pragmatic reasons, Ethereum developers should sacrifice censorship resistance for scalability in the short term and focus on censorship resistance in the long term.

Dankrad Feist, a researcher at the Ethereum Foundation, believes that the marginal increase in operating costs for node operators by EIP 4844 is negligible and will not substantially damage Ethereum's anti-censorship features. Feist also added that most Ethereum users do not run their own nodes not because of the cost, but because of the poor user experience. Diederik Loerakker said that in order to create a higher level of decentralization, expansion should be a priority for Ethereum developers, because code changes like EIP 4844 will make Ethereum cheaper to use and lower barriers to entry for more people around the world.

Lukasz Rozmej from the Nethermind EL client team also questioned whether EIP 4844 would have a negative impact on Ethereum’s censorship resistance, since many transactions would theoretically be executed on L2 rollups. Zoltu explained that while EIP 4844 could make it more difficult for validators to censor individual transactions in the future, currently the operation of L2 rollups is centralized and therefore censorable. Concluding this discussion, Tim Beiko said that improving the user experience of running an Ethereum node should be a focus area for the community moving forward. Beiko suggested that development teams adjacent to Ethereum core developers should help simplify running an Ethereum node and work to make it more accessible to regular users.

Other Miscellaneous

In addition to the above, there are some issues that Ethereum developers have not yet discussed in this conference call. They include:

• Engine API Spec Improvement Proposal : Teku developer Mikhail Kalinin has created a proposal to improve Ethereum's Engine API spec. As background, the Engine API is a piece of software that enables easy communication between EL and CL clients of Ethereum nodes. The proposed changes to the Engine API may be discussed at the Ethereum CL meeting next Thursday.

• Shanghai "Core" vs Prototype Developer Testnet : Testing EIPs for the Shanghai upgrade will require the creation of multiple dedicated testnets. Shandong is a testnet launched by the Ethereum Foundation JavaScript team that has implemented EIP 4895, EIP 3860, EIP 3651, and EIP 3855, in addition to some EIPs related to EOF implementation. In the next few ACD conference calls, developers will coordinate the creation of more dedicated testnets for client teams to test the Shanghai upgrade EIP.

• Ropsten testnet end date : Afri Schoeden, one of the developers maintaining the Ethereum testnet Goerli, has proposed a proposal to launch and deprecate Ethereum testnets on a planned timeline. This is in response to frustration from application developers and infrastructure providers over the deprecation of multiple Ethereum testnets. Developers are encouraged to share their ideas on how to responsibly deprecate public Ethereum testnets like Ropsten in this EthereumMagic forum post.