Ethereum All Core Developers Execution Call #181
On February 15, 2024, Ethereum developers gathered over Zoom for All Core Developers Execution (ACDE) Call #181. Chaired by Ethereum Foundation (EF) Protocol Lead Tim Beiko, the ACDE calls are a bi-weekly meeting series where developers discuss and coordinate changes to the execution layer (EL) of Ethereum. This week, developers shared updates on their preparations for the mainnet activation of the Dencun upgrade. They also discussed a variety of Ethereum Improvement Proposals (EIPs), the majority of which were proposed for inclusion in the Pectra upgrade, while others were proposed as “retroactive” EIPs, meaning changes to protocols rules that would be retroactively applied to all Ethereum transactions since genesis. Developers also agreed to include EIP 2537, the addition of the BLS12-381 curve precompile, in Pectra.
Dencun Updates
EF Developer Operations Engineer Barnabas Busa said that his team is syncing nodes to Ethereum mainnet in preparation for a shadow fork. As background, a shadow fork is a type of test network that developers use to deploy upgrades in an environment that mimics the activity on an existing blockchain. Developers plan on executing an Ethereum mainnet shadow fork for the Dencun upgrade once all final client versions for Dencun have been released. Client teams are aiming to release final versions for Dencun by late next week. Busa said that his team will upgrade their nodes to these versions shortly thereafter and aim to complete the mainnet shadow fork by Friday, February 23. Beiko chimed in saying that once the results of the shadow fork are in and if they are positive, he will go ahead and publish the official EF blog post announcing a mainnet activation date of March 13 for the Dencun upgrade.
So far, on the EL side, Reth, Geth, and Besu client teams have released their final software for Dencun. Nethermind and Erigon teams are planning on releasing their versions tomorrow or early next week. On the CL side, the Prysm team plans on releasing their final version next Thursday, February 22. Prysm developer Terence Tsao mentioned that his team’s work is blocked by a pending CL specifications release. EF Researcher and Chair of the All Core Developers Consensus (ACDC) calls Danny Ryan said that he would check in with this team and try to release the latest version of CL specifications for Dencun by tomorrow. The other CL client teams on the call including Lodestar and Teku said that they were similarly in the final stages of releasing their mainnet-ready Dencun software. Regarding Layer-2 (L2) rollup readiness for Dencun, EF Researcher Carl Beekhuizen said that from the conversation on the latest RollCall, a meeting series for L2s, many L2 teams do not have a release ready for Dencun mainnet activation. Aside from the Polygon team, the rest are still working on their releases, which may be ready for March 13 or some time thereafter. As expressed on prior ACD calls, Ethereum protocol developers will not be adjusting the timing of the Dencun upgrade based on L2 team readiness.
Retroactive EIPs
Then, developers discussed two retroactive EIPs, EIP 7610 and 7523. As explained by Hedera Hashgraph engineer and Besu client maintainer Danno Ferrin, EIP 7610 amends smart contract creation rules such that if a contract is created at an address with pre-existing storage, the creation will fail. Already, there are rules on Ethereum to prevent the creation of contracts at addresses that have a nonzero nonce. EIP 7610 would extend the rule and retroactively apply it to all prior Ethereum blocks. Rules to restrict contract creation under certain conditions were initially applied by developers in 2016 to address spam attacks on Ethereum, also called the “Shanghai Attacks.” While these attacks are near impossible to execute on mainnet today, Ferrin said that EIP 7610 would help “make a lot of client code simpler when it comes to the [contract] create process.” EIP 7610 requires a hard fork upgrade to implement but it would only require changes on the EL.
Geth developer Guillaume Ballet raised concerns about how EIP 7610 would impact the Verkle code change, which is a code change that developers are anticipating for implementation in the upgrade after Pectra. Developers agreed to ponder the final design of EIP 7610 in light of the Verkle upgrade over the next two weeks and re-discuss this EIP on the next ACDE call.
EIP 7523 is another retroactive EIP that would prohibit the state of any post-merge network from containing empty accounts. Technically, this rule is already achieved on Ethereum and Ethereum test networks as there are no empty accounts that exist on these networks. However, as the EIP document states, “an explicit ban reduces technical debt going forward.” The EIP author EF Researcher Peter Davies wrote in a Discord message that while he was quite certain that there were no empty accounts left on Ethereum and its testnets, there may be some use in another developer independently verifying this fact. Beiko said that he would try and find someone to double check Davies’ analysis of empty accounts and finalize the EIP thereafter.
Pectra EIPs
Then, developers discussed several EIPs proposed for inclusion in the Pectra upgrade.
EIP 5806
The first Pectra EIP that was discussed on this week’s call was EIP 5806. It was presented by Open Zeppelin Smart Contract Engineer Hadrien Croubois as an alternative to EIP 3074. Both EIP 5806 and 3074 aims to introduce smart contract functionality to externally owned accounts (EOAs). Croubois said that the advantage of 5806 over 3074 was primarily security. “Unlike EIP 3074, where you sign a hash, and you rely on a smart contract to tightly associate that hash with an intention … in 5806, the transaction that is being signed is very explicit about its entire context,” said Croubois, adding that EIP 5806 would leave less room for bugs and user error than 3074. He also mentioned that since the EIP was transaction-based, rather than hash-based, it would enable greater predictability in terms of gas estimations for the execution of smart contract EOAs.
Erigon developer Andrew Ashikhmin was in favor of including EIP 5806 in Prague with the caveat that it should be accompanied by the disabling of the SSTORE opcode, which calculates the cost of saving smart contract data to storage. Geth developer “lightclient” noted that the EIP is narrower in functionality than EIP 3074. He wrote in a comment on the Zoom chat that EIP 5806 “does not allow for any type of account recovery mechanism, so EOAs still can’t have social recovery” and “does not allow bundling of txs from different users, which is highly demanded by wallet developers as it further reduces the cost of user operations.” Croubois agreed with these sentiments, saying that the EIP sacrifices these features for the benefit of enhanced security.
EIP 7557
The second Pectra EIP that developers discussed on the call was EIP 7557, which proposes a mechanism for distributing the gas costs associated with accessing smart contract addresses and storage slots across multiple transactions trying to access the same data in the same block. Alex Forshtat, an EF developer working on account abstraction, presented the EIP. “In EIP 2929 and 2930, Ethereum added the concept of warm and cold storage. Accessing cold storage was made obviously way more expensive than the warm one. However, this distinction is only made on a transaction level,” said Forshtat. Though accessing cold storage is a more expensive operation, block producers only need to lookup the data for accessing cold storage once, even if there are multiple transactions in a block requesting the same data. Therefore, users could save on gas if the cost for accessing cold storage once was distributed equitably across all transaction senders requesting the same data, rather than duplicating the cost of accessing the data across these senders.
Ashikhmin and other client developers on the call were concerned about this EIP’s implications on gas calculations and estimations. Nethermind developer Lukasz Rozmej questioned whether the strategies used by block builders to build blocks containing MEV would be disrupted because of this EIP. Beiko also mentioned that simulations to measure roughly how much users could save in gas costs due to this EIP would be helpful. Ballet recommended tabling this EIP until after the Verkle code change due to concerns that the EIP would complicate Verkle if implemented in the Pectra upgrade. It was unclear why this upgrade would complicate Verkle.
EF Researcher Dankrad Feist questioned why the gas cost of accessing cold storage should be equally distributed across relevant addresses if the EIP’s implementation could be made simpler if the gas cost is born by one address and not replicated across the other addresses. Rozmej argued that equally distributing the gas costs would be simpler to implement given that the implementation would not need to keep track of transaction order within a block, simply the number of transactions trying to access the same data in a block. EF Security Fellow Yoav Weiss emphasized that this EIP should not complicate gas estimations given that the gas refunds would only occur once the contents of a block are finalized, not before, and therefore should not be factored into initial gas estimations for a block.
EIP 2395
The third Pectra EIP that was discussed on ACDE #181 was EIP-2395. Ballet presented this proposal, which would store historical block hashes in a smart contract and enable the BLOCKHASH opcode to read the data from this contract. The EIP was initially proposed back in 2020 by Ethereum founder Vitalik Buterin and Nethermind developer Tomasz Kajetan Stanczak to remove the need for clients to store blockchain state history older than a certain period and thereby help free up node disk space. Ballet said that the EIP was needed for stateless clients, which are nodes that can verify blocks on Ethereum without storing or retaining copies of the full blockchain state. Enabling stateless clients is one of the goals of Verkle. Verkle allows nodes to verify Ethereum state using smaller cryptographic proofs, and this then opens the design space for achieving stateless clients.
Danny Ryan and Lodestar developer Gajinder Singh were both in favor of including this EIP in Pectra. Ferrin questioned why this EIP removes the use of a ring buffer for accessing historical block hashes. As background, a ring buffer is a data structure that restricts the stream of information into a circular queue such that data can be stored in a continuous loop of fixed length. EIP 4788 which is a code change going into Dencun that exposes beacon block roots in the EVM makes use of a ring buffer. In response to Ferrin, Ballet said that the use of a ring buffer would reduce the cost of certain types of attack on the contract. However, upon further questioning, developers were able to gather that the attack Ballet was describing, if feasible, would present risks to all high use smart contracts on Ethereum. “My point really is that if this attack is realistic, then we have to rethink big things. If it’s not realistic, then the ring buffer is not relevant,” said Geth developer Péter Szilágyi.
EIP 5920
Vyper smart contract language developer Charles Cooper presented EIP 5920, which introduces a new opcode, PAY, to send ETH to an address without calling any of the recipient address’ functions. The motivation for the PAY opcode is primarily UX-related. Currently, to send ETH to an address, the addressed must first by called using the CALL opcode. This opens potential reentrancy attack vectors on the sender and is at times needlessly expensive for users wanting to make simple transfers of ETH. Ashikhmin was in favor of including this code change in Pectra.
Decrease Base Cost of TLOAD/TSTORE
Cooper also presented a draft EIP to reduce the cost of two new opcodes, TLOAD and TSTORE, which will be activated through the Dencun upgrade. After doing some benchmarking on the computational resources required to execute these opcodes, Cooper said that they can be priced “10 times cheaper”. To address the issue of potential DoS attack vectors through the reduction in cost of these opcodes, Cooper proposed a new tiered pricing model based on the number of slots in which the opcodes are called. Ashikhmin was not in favor of implementing this EIP given that it was not a pressing change to Ethereum. Szilagyi agreed that the EIP was “a micro-optimization” that would not present much benefit to users. However, he said that if the EIP is simple to implement, it would be fine to include it in the Prague upgrade. Szilagyi questioned the simplicity of implementing a tiered pricing model for the transient storage opcodes.
Inclusion Lists
EF Researcher Mike Neuder mentioned inclusion lists as another code change for consideration in Pectra. He highlighted a new document that he wrote that details what specification changes are needed to implement inclusion lists. Inclusion lists are a list of transactions that block builders would be required to include in the blocks they propose to validators. It is aimed at preventing block builders from censoring transactions from blocks. Neuder also highlighted that developers will be gathering over a Zoom call tomorrow February 16 to discuss inclusion lists in more detail.
EIP 2537
Beiko asked developers on the call if anyone objected to including EIP 2537, a precompile for BLS curve operations, in the Pectra upgrade. It was raised for discussion on a prior ACD call. No developers objected to including EIP 2537 in Pectra. Ferrin mentioned that the gas cost analysis for the EIP needs to be revisited by developers. EF Researcher Alex Stokes mentioned in the Zoom chat that he will be doing this analysis over the next few months.
Finally, developers agreed to schedule a breakout meeting to discuss in more detail all the account abstraction and EVM related code changes presented for the Pectra upgrade. Beiko said that he would propose a time for the meeting after the call once he has had a chance to confirm the availabilities of wallet providers. The call will be scheduled sometime before the next ACDE meeting.
Pectra Upgrade Timing
Before ending the call, Szilagyi stressed that developers should try to agree on the general timing for the Pectra upgrade and adjust the fork scope iteratively to be able to meet the proposed deadline. “We usually suck at estimating when hard forks should ship and what we should cram in and not to cram in because obviously everybody wants to cram in as much as possible,” said Szilagyi, adding, “Perhaps it would be helpful to try to at least guesstimate what we want in a hard fork to ship, pinpoint a date, and then based on that try to cram in as much as possible but try to enforce that date.”
To this Beiko said that in his view people on the call were in favor of shipping the Pectra upgrade sometime this year, which would mean that after the Dencun upgrade in March, developers have roughly nine months to ship the next upgrade. “[The upgrade] should be something we think we can probably get done in like six months or less,” said Beiko.
Legal Disclosure:
This document, and the information contained herein, has been provided to you by Galaxy Digital Holdings LP and its affiliates (“Galaxy Digital”) solely for informational purposes. This document may not be reproduced or redistributed in whole or in part, in any format, without the express written approval of Galaxy Digital. Neither the information, nor any opinion contained in this document, constitutes an offer to buy or sell, or a solicitation of an offer to buy or sell, any advisory services, securities, futures, options or other financial instruments or to participate in any advisory services or trading strategy. Nothing contained in this document constitutes investment, legal or tax advice or is an endorsementof any of the digital assets or companies mentioned herein. You should make your own investigations and evaluations of the information herein. Any decisions based on information contained in this document are the sole responsibility of the reader. Certain statements in this document reflect Galaxy Digital’s views, estimates, opinions or predictions (which may be based on proprietary models and assumptions, including, in particular, Galaxy Digital’s views on the current and future market for certain digital assets), and there is no guarantee that these views, estimates, opinions or predictions are currently accurate or that they will be ultimately realized. To the extent these assumptions or models are not correct or circumstances change, the actual performance may vary substantially from, and be less than, the estimates included herein. None of Galaxy Digital nor any of its affiliates, shareholders, partners, members, directors, officers, management, employees or representatives makes any representation or warranty, express or implied, as to the accuracy or completeness of any of the information or any other information (whether communicated in written or oral form) transmitted or made available to you. Each of the aforementioned parties expressly disclaims any and all liability relating to or resulting from the use of this information. Certain information contained herein (including financial information) has been obtained from published and non-published sources. Such information has not been independently verified by Galaxy Digital and, Galaxy Digital, does not assume responsibility for the accuracy of such information. Affiliates of Galaxy Digital may have owned or may own investments in some of the digital assets and protocols discussed in this document. Except where otherwise indicated, the information in this document is based on matters as they exist as of the date of preparation and not as of any future date, and will not be updated or otherwise revised to reflect information that subsequently becomes available, or circumstances existing or changes occurring after the date hereof. This document provides links to other Websites that we think might be of interest to you. Please note that when you click on one of these links, you may be moving to a provider’s website that is not associated with Galaxy Digital. These linked sites and their providers are not controlled by us, and we are not responsible for the contents or the proper operation of any linked site. The inclusion of any link does not imply our endorsement or our adoption of the statements therein. We encourage you to read the terms of use and privacy statements of these linked sites as their policies may differ from ours. The foregoing does not constitute a “research report” as defined by FINRA Rule 2241 or a “debt research report” as defined by FINRA Rule 2242 and was not prepared by Galaxy Digital Partners LLC. For all inquiries, please email [email protected]. ©Copyright Galaxy Digital Holdings LP 2024. All rights reserved.