Learn about the potential updates of the Ethereum Shanghai upgrade in one article
Original title: "Ethereum All Core Developers Call #149 Writeup》
Author: Christine Kim
Compilation of the original text: Overnight Porridge
Original title: "
Author: Christine Kim
On November 10, 2022, Ethereum developers gathered for the 149th All Core Developers (ACD) conference call. This ACD conference call was moderated by Tim Beiko of the Ethereum Foundation. Object Format (EOF) and proto-danksharding related code changes progress to enable the first major upgrade of the merged Ethereum network (called Shanghai). During this call, the developers also discussed four other EIPs that could be included in the Shanghai upgrade. While each proposal does bring some unique advantages and benefits to Ethereum, there is still considerable debate among developers about which EIPs to prioritize for inclusion. In addition to the discussion of the Shanghai upgrade, the developers briefly touched on the topic of censorship resistance and the potential tradeoffs of ethereum’s censorship-resistant features for network scalability.hereShanghai upgrade plan
In a previous ACD call, ethereum developers agreed to include the core list of EIPs in the Shanghai upgrade. The full transcript of the call from ACD Call #148 is at
here
. It is worth noting that from this list of core EIPs, the developers agreed to include the pledged ETH withdrawal proposal into the Shanghai upgrade, but did not commit to include EOF or proto-danksharding in the same upgrade until the latter two proposals. Code changes were further fleshed out. Especially on the topic of EOF, developers have been hesitating whether to implement EOF through a small part of the EIP part of the Shanghai upgrade, or try to bundle the entire vision of EOF into the Ethereum upgrade after Shanghai.
Proto-danksharding
EOF implementationEIP 4844Danno Ferrin, Principal Software Engineer at Hedera, provided an update on this week's conference call regarding the progress of the EOF implementation in Shanghai. He explained that developers tend to bundle most of the EIPs related to EOF implementations into one large upgrade as early as possible. The EIPs related to EOF implementation considered by developers in the Shanghai upgrade include EIP 3540, EIP 3670, EIP 4200, and EIP 4750. There is still disagreement among developers as to whether EIP 5450 should be included in the list of code changes related to EOF.GithubAndrew Ashikhmin of the Erigon Execution Layer (EL) client team also expressed concern about whether the Solidity smart contract language team will be able to fully support and implement all four (or possibly five) EIPs. Ashikhmin emphasized that before committing to upgrading and activating these EIPs in Shanghai, it is necessary to first confirm that the Solidity team is ready for these EIPs to be implemented. Ashikhmin said on the call that this is "a necessary sanity check," which was echoed by Marius van der Wijden of the Geth EL client team.
The developers then went on to discuss the latest developments in proto-danksharding. Unlike the EOF implementation, only one EIP is associated with proto-danksharding code changes, namely
. According to Diederik Loerakker (often referred to as "Protolambda"), a researcher at OP Labs, there are still some matters under discussion related to EIP 4844. Ansgar Dietrichs of the Ethereum Foundation added that some of these matters have to do with setting a minimum price for blob transactions and reducing blob transaction throughput for the Shanghai upgrade. These to-dos are in
1、EIP 4758There is a summary.
2、EIP 1153Disable Self-Destruct opcode, and other potential EIPs
3、EIP 2537While the developers are preparing for EOF and proto-danksharding work for the Shanghai upgrade, the developers have tentatively agreed to continue working on the other four EIPs for inclusion in the next upgrade of Ethereum.
4、EIP 2294, disabling the 'selfdestruct' opcode on Ethereum: Developers revisit conversations from the last ACD call about disabling an opcode widely considered by developers to be useful in smart contracts and decentralized applications (dapps) Bad practice used in . This opcode is one of the few legacy opcodes that have a fixed gas cost to deploy but potentially unlimited storage costs for the network. Independent developer Micah Zoltu reiterated that some active smart contracts on ethereum are still using the selfdestruct opcode, and disabling it would break functionality. For these special edge cases, there may be some workarounds and more community outreach by the Ethereum Foundation, Tim Beiko said.
, Addition of Ephemeral Storage Opcodes: Representatives of the Uniswap and Optimism teams made a compelling case to introduce an ephemeral storage opcode that behaves the same as regular storage opcodes on Ethereum, except for these two new opcodes The values of TLOAD and TSTORE will be discarded after each transaction. There are many motivations for ephemeral storage, one of which, as Optimism's Mark Tyneway explains, is to save gas costs. On Uniswap alone, this EIP has the potential to save users $3 million in annual gas costs. Additionally, using ephemeral storage instead of regular storage will help reduce Ethereum’s technical debt. The Uniswap and Optimism teams have done a lot of work to help create implementations of this code change in several different Ethereum software clients and build a comprehensive test suite for the EIP. Daniel Lehrner of the Besu (EL) client team thanked external developers for their calls to prepare for the implementation of EIP 1153. Even so, not all developers find the additional testing load of incorporating EIP 1153 worthwhile. 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 remains "wait and see" about increasing testing efforts on code changes. The developers agreed to continue testing EIP 1153 with the help of external developers from the Uniswap and Optimism teams for inclusion in the Shanghai upgrade.
, Adding BLS Precompilation: Alex Stokes of the Ethereum Foundation describes the advantages of adding BLS precompilation to Ethereum. There are a number of reasons for this, Stokes explained, 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 agrees that adding BLS precompilation is an important code change that may even take precedence over the 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 Shanghai's 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 work on EIP 2537 and started reducing the number of different BLS precompiles to possibly incorporate the Shanghai upgrade.
: Finally, Zainan Victor Zhou, a software engineer at Google, introduced EIP 2294, whose code change is relatively simple, but simply limits the byte size of Ethereum's chain ID field, which is traditionally used to help node discovery after hard fork . Victor Zhou said in the conference call that due to the possibility of sharding and multi-chain in Ethereum in the future, the use case of chain ID will become larger and more important. To prevent people from trying to exploit the chain ID field by storing other types of data in it, Victor Zhou called for an explicit binding on the chain ID size. All developers agree 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 changes on their own timelines without having to coordinate a specific block height for the change. There was also some discussion among the developers about whether to limit the chain ID size to 64 bits or 256 bits at the end of the call. Tim Beiko encourages 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 on which EIPs to prioritize for inclusion outside the core list. An Ethereum Foundation developer under the pseudonym "lightclient" proposed sticking with open withdrawals and prioritizing only another major EIP, be it proto-danksharding, an EOF implementation, or one of the four proposed on the call . Tim Beiko thinks it's unrealistic to try to bundle EOF implementation, proto-danksharding, BLS precompilation, and adding ephemeral storage opcodes in the next upgrade. Due to the lack of meeting time, Beiko brought up the discussion of the Shanghai upgrade plan and encouraged developers to prepare to discuss the highest priority of the Shanghai upgrade besides pledged ETH withdrawals during the next ACD conference call.
How to reduce the operating cost of Ethereum nodes (increase censorship resistance)?
In a talk about the Shanghai upgrade, independent Ethereum developer Micah Zoltu brought up an important discussion item regarding Ethereum's censorship resistance. Few ethereum users run their own nodes to execute transactions, Zoltu explained, and people rely on centralized services like Infura or Alchemy that actively censor users from specific countries and censor decentralization on ethereum. application (dapps), such as Tornado Cash. While developers are working to improve ethereum's scalability through EIP 4844, there has been a lack of effort to reduce the cost of running an ethereum node and encourage greater assurance of ethereum's censorship resistance. Mikhail Kalinin, a developer on the Ethereum Teku (CL) client team, proposed to focus on reducing the cost of running an Ethereum node after the implementation of 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.
The view of Dankrad Feist, a researcher at the Ethereum Foundation, is that EIP 4844 has a negligible marginal increase in the operating costs of node operators and will not cause substantial damage to Ethereum's anti-censorship characteristics. Feist also added that most ethereum users don't run their own nodes not because of cost, but because of poor user experience. Diederik Loerakker said that in order to create a higher level of decentralization, scaling should be a priority for Ethereum developers, as code changes like EIP 4844 will make Ethereum less expensive to use and more accessible to more people around the world. People lower barriers to entry.
In addition to the above, there are a few things that Ethereum developers have not discussed on this call, including:Engine API Specification Improvement Proposal
: Teku developer Mikhail Kalinin has created a proposal for improving Ethereum's Engine API specification. As background, the Engine API is software that enables easy communication between EL and CL clients of an Ethereum node. The proposed changes to the Engine API are likely to be discussed at the Ethereum CL conference next Thursday.Shanghai "Core" vs Prototype Developer Testnet
