TL;DR
- Nethermind Updates
- Erigon Updates
- Geth Updates
- Besu Updates
- Proto-Danksharding Updates
- EOF EIPs Discussion
- Lighthouse Updates
- Prysm Updates
- Lodestar Updates
- Teku Updates
- Grandine Updates
- Smaller Vs Less Frequent Larger Hardforks
- SelfDestruct Deactivation
- Goerli Supply Issues
- Conclusion
Tim Beiko started this call. The main agenda of this call was Shanghai Planning and updates from the last month. This was the 2nd Post Merge ACD Call. Here is the quick glance at the agenda of this call:
- Shanghai Planning
- Shanghai Candidate EIPs Discussions
- Goerli Supply Issues
- Shandong Testnet
- Withdrawals
Nethermind Updates
Marek Moraczyński from Nethermind Team told everyone that they have drafted PRs for all Shanghai EIPs currently considered for inclusion. He also added that they have also implemented EIP-1153: Transient Storage Opcodes and EIP-4758: Deactivate SELFDESTRUCT. In addition, they synced Shandong Testnet and passed the existing EOF reference tests. Lastly, he added that the current CFI EIP list is good, and if we add something big to Shanghai, it would delay shipping Withdrawals. Lukasz Rozmej said that the biggest priority is to decide the scope of Shanghai.
Erigon Updates
Andrew Ashikhmin from Erigon Team agreed with the Nethermind Team that the current CFI list is the good one. In addition, he added that deactivating SELFDESTRUCT would help Erigon simplify its codebase significantly and is also a prerequisite to Verkle Trees.
Geth Updates
Péter Szilágyi from Geth Team said that there are two levels of proposals competing in Shanghai:
- the smaller ones, like EIP-1153, EIP-4758, etc.
- the big ones, like EOF EIPs, EIP-4844 & Withdrawals, etc.
He further explained how each of the EOF EIPs and other EIPs are important. Also, each and every EIP will require extensive testing.
Besu Updates
Matt Nelson from Besu Team said that they also agree with the Nethermind team and are happy with the current CFI list. They also have PRs in progress for most EIPs. For EIP-4844, they are still unsure of the actual implementation complexity and would like to have a better view of that. They also agreed with Péter Szilágyi that more discussions need to be done with EOF EIPs.
Proto-Danksharding Updates
Lukasz Rozmej said that there are lot of concerns around EIP-4844:
- Firstly, scope is not finalized and spec is still evolving. So, developers are are afraid that there will be some minor changes at the last moment.
- Secondly, there is a lot of uncertainty among developers. So, they want the spec to be finalized in the next month. This will help developers to take final decision based on the scope.
Also, Péter Szilágyi said thet EIP-4844 is not the full Danksharding. It is about blob transactions.
ansgar.eth gave a quick overview of the current moving pieces on the spec. The two biggest ones are:
He also said that it's reasonable that both these things would be finalized in the next month.
EOF EIPs Discussion
Marius VanDerWijden shared his thoughts on EOFs. He said that he liked the idea of EIPs but in the present state these EIPs don't help them in anything. He stressed that he'd rather see a full EOF implementation rather than a multi-step one because each EOF version must be maintained forever in clients. Because both EOF and non-EOF contracts exist in parallel, we can never deprecate pre-EOF EVM implementations from clients. So if we ship the EOF in two steps, EOFv1 and EOFv2, then clients must maintain the pre-EOF, EOFv1, and EOFv2 EVMs forever. He proposed that EOF should be postponed and done in a separate hardfork after Shanghai. He wanted developers to currently focus on withdrawals and danksharding.
Tomasz K. Stańczak said that he supports EOF, but he doesn't want it to be rushed onto the mainnet. He would rather see a long-lived testnet where developers first iterate on it and get to a final version that they are happy with it and EIPs are fully tested on.
axic.eth one of the EOF EIP authors said that the reason for splitting the EOF EIPs was to make them easier to review by client teams, and agreed that a full feature set would be ideal. He also added that if we can't commit to all of EOF for Shanghai, then a subset is still valuable.
Andrew Ashikhmin like the idea of Marius bundling all EOF changes together and the testnet idea of Tomasz. But, He further had some questions about whether this would affect code chunking for Verkle Trees, which axic.eth confirmed it wouldn't.
Lighthouse Updates
Paul Hauner from Lighthouse Team said that mostly for them Withdrawals and EIP-4844 are the two main priorities right now. He said that we still need more data & testing for EIP-4844.
Prysm Updates
terence.eth from Prysm Team agreed with Paul Haner that Withdrawals are a must but they are less complicated and much easier. But he wants to see a devnet running. He is also extremely bullish about EIP-4844.
Lodestar Updates
Phil Ngo agreed with terence.eth that are fully optimistic about EIP-4844 and Withdrawals.
Teku Updates
Enrico Del Fante from Teku Team said that they think that Withdrawals are much easier compared to EIP-4844. The team is discussing to have withdrawals in prior to EIP-4844. The also want to separate the upgrades in order to do some merge-related cleanups in their codebase.
Grandine Updates
Saulius Grigaitis from Grandine Team said that unless they see something seriously wrong during testing, they'd like to see both Withdrawals and EIP-4844 in the next upgrade.
Smaller Vs Less Frequent Larger Hardforks
There was a discussion initiated by Péter Szilágyi on Smaller Vs Less Frequent Larger Hardforks. While it always seems appealing to have smaller, more frequent upgrades, but the time it takes to get every client to implement things, test extensively, put out releases, fork testnets, and then schedule mainnet, means there's a lot of overhead to each fork. Péter Szilágyi estimated that about 3 months or so each time is needed for this process. This means that in a lot of cases, it's probably worth it to add one more feature to an upgrade rather than to try and split them up.
SelfDestruct Deactivation
Developers spend some time discussing deactivating SELFDESTRUCT, as it does have some implications on existing contracts. EIP-4758 proposes to replace SELFDESTRUCT by SENDALL, which, like SELFDESTRUCT, sends all the ETH to the caller when used, but doesn't actually remove the contract form the state. There are two reasons why client teams think this is desirable:
- Firstly, because
SELFDESTRUCTis currently the only opcode with a fixed (gas) price but unbounded potential (computation) costs. - Secondly, the main reason is that when we move to Verkle Trees, accounts won't be stored in the same way as they currently are, and so it's not as simple to remove something from the state trie.
Goerli Supply Issues
GoETH is becoming too scarce, and so core developers need ways to get it in the hands of developers for free. Goerli only has 115M GoETH total supply. Goerli is the only/main testnet for testing validator setups. 80-90% of the total supply is in circulation or locked in deposit contracts. There is a Goerli Testnet Community Call #6 by Afri Schoeden.
Conclusion
With regards to the Shanghai implementations, Developers agreed to include the following EIPs in Shanghai and launch a devnet:
- EIP-3651: Warm COINBASE
- EIP-3855: PUSH0 Instruction
- EIP-3860: Limit and Meter Initcode
- EIP-4895: Beacon Chain Push Withdrawals as Operations
Developers also agreed to keep working on EOF and EIP-4844 specific devnets in parallel, and have them build on top of this Shanghai Core devnet, to mirror how the CL teams are having EIP-4844 rebased on top of Capella (which is mostly withdrawals).
The Next ACD Call is scheduled on November 10 at 14:00 UTC.
Readers can watch Ethereum's All Core Devs Meeting #148 here:
Related Articles
- An overview of expected changes with the Ethereum Merge upgrade
- MEV in DeFi
- The Evolution of Ethereum Testnets
- Ethereum Testnets after The Merge
- Ethereum Mainnet Shadow Forking: An Overview
Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.
To publish press releases, project updates and guest posts with us, please email at contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Support us at Gitcoin
You've something to share with the blockchain community, join us on Discord!
