Original title: "Ethereum All Core Developers Execution Call#187Writeup" Original author: Christine Kim Original translation: Lucy, BlockBeats
Editor's note: The Ethereum All Core Developers Consensus Call (ACDE) is held every two weeks to discuss and coordinate changes to the Ethereum Execution Layer (EL). This is the 187th ACDE call. At this meeting, developers discussed the preparations for Pectra Devnet 0, the implementation updates of EIP 3074, and the urgency of converting the serialization method of the execution layer from MPT to SSZ. In addition to preparations for Pectra Devnet 0, developers also discussed new EIP proposals, discussions and analysis of existing EIPs, and analysis of the impact on smart contracts and transactions. Among them, the discussion on EIP 7702 attracted widespread attention from participants, and the proposal was seen as a potential solution to replace EIP 3074. Christine Kim, vice president of research at Galaxy Digital, took detailed notes on the key points of this meeting, and BlockBeasts translated the original text as follows:
On May 9, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #187. The ACDE call is a bi-weekly series of meetings hosted by Tim Beiko, head of protocol support at the Ethereum Foundation, where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week, developers discussed preparations for Pectra Devnet 0, updates to the EIP 3074 implementation, and the urgency of converting the serialization method on the EL from MPT to SSZ.
Pectra Devnet-0 Update
Barnabas Busa, developer operations engineer at the Ethereum Foundation, said his team is testing client configurations on the first Pectra developer-focused testnet and will work to ensure a stable configuration for Pectra Devnet 0 by Monday, May 13. According to the Pectra Devnet 0 readiness tracker, the Geth, Nethermind, and EthereumJS client teams have fully implemented the Pectra coding standards.
During the call, Besu developer Justine Florentine said that all Pectra EIPs have been implemented on Besu, but his team is still working on debugging the code. Erigon developer Andrew Ashikhmin said his team has started working on all EIPs except EIP 7002, EL triggerable withdrawals. The Reth team posted a link to their implementation tracker in the Zoom chat, showing that their work on EIP 7002 is still pending like the Erigon team.
On the CL client side, Grandine developer Saulius Grigaitis said that all EIPs have been implemented, but his team encountered some errors when running with the EL client. Representatives from the Lighthouse team said that they are close to having a complete implementation ready for Pectra Devnet 0, and noted that the specification in the engine API needs to be updated. Teku developer Mikhail Kalinin said that he is working to add these updates to the engine API specification.
Mario Vegas from the EF testing team said that developers are working on adding test cases for EIP 3074, AUTH and AUTHCALL opcodes, and several other EIPs.
EIP-3074 Update
Although developers agreed to keep EIP 3074 in the spec for Pectra Devnet 0, an alternative EIP has been discussed to replace it, EIP 7702. Geth developer "Lightclient" summarized the latest breakout session on EIP 3074, in which participants discussed which changes to prioritize in the Pectra upgrade related to improving user-controlled account programmability. According to Lightclient, all participants agreed that full local account abstraction is still a few years away from being implemented on Ethereum. However, there is disagreement on whether this means prioritizing changes to the externally owned accounts (EOAs) functionality, or migrating EOAs to smart contract wallets. A day before this ACDE call, on May 8, Ethereum co-founder Vitalik Buterin proposed a new EIP, EIP 7702, which would enable Ethereum to support a new transaction type to support EOAs to operate like smart contract wallets during a single transaction. Lightclient said that participants from the EIP 3074 breakout session were generally positive about EIP 7702. However, he later added that there are still important details to be worked out about EIP 7702. For example, details about how to rescind EIP 7702 transactions and how to scale the gas costs for such transactions are still unclear.
If EIP 7702 is accepted and included in the Pectra upgrade, it will be considered to replace EIP 3074, as EIP 7702 achieves similar results to EIP 3074, but does not create new opcodes on Ethereum and improves the convenience of static analysis of new EOA behaviors. EF researcher Ansgar Dietrichs suggested in a Zoom chat that EIP 7702 be considered for inclusion in Pectra, and a formal decision on whether to replace EIP 3074 with 7702 will be made in about 2 to 4 weeks. It is clear from the developers' discussion of EIP 7702 on the call that further work is needed before the proposal can be considered ready for implementation. Nethermind developer Ahmad Mazen Bitar pointed out that it is unlikely that the work already done for EIP 3074 will be reused to implement 7702. Beiko confirmed that developers should still move forward with the implementation of EIP 3074 for Devnet 0 and revisit the specification for Devnet-1 later.
EIP-7685, SSZ, and EIP-6110
The developers then discussed some concerns raised by Nimbus developer Etan Kissling about EIP 7685, generic execution layer requests. In a GitHub comment under the agenda for this week’s call, Kissling asked if the proposed design for generic execution layer requests was needed, and if the opportunity could be better used to switch to SSZ, a serialization format that developers have been looking to update on the execution layer since the merge upgrade. Most of the execution layer client teams on the call supported keeping EIP 7685 in Pectra and revisiting the design if any impediments to including the EIP in operations arise, such as optimistic sync on clients.
On the topic of moving to SSZ, Kissling explained that the newly designed format for generic execution layer requests is based on the traditional serialization formats MPT and RLP, so it will have to be updated when developers transition to SSZ. He noted that delaying the move to SSZ will only create more work for developers if they continue to create new MPT/RLP data structures. However, there has not been strong support from the execution layer client team to include EIP 7495, SSZ stable containers, in Pectra. A developer named "Dustin" wrote in a Zoom chat that the decision to delay the SSZ transition was "crazy" and that the problem of poorly working SSZ libraries in EL was "a serious problem."
Regarding EIP 6110, on-chain supply validator deposits, Kissling raised questions about deposit ordering. Kalinin agreed that the issue is “a significant concern” and that he would be working with major staking pools to investigate more deeply.
EOF Update
Independent Ethereum protocol developer Danno Ferrin and EF Solidity research lead Alex Beregszaszi shared an update on the EOF implementation work. The background is that EOF is a series of code changes that improve the Ethereum Virtual Machine (EVM) that developers are considering for inclusion in the Pectra upgrade. The meta EIP for EOF has been finalized. Developers have also simplified the transaction creation process in EOF and are working on the client implementation of EOF.
EIP-7623 Update
A developer who went by the screen name "William Morris" on the call raised concerns about the changes to gas costs for calldata storage in EIP 7623. He explained that these changes would allow some users to trade at a lower rate by consolidating their transactions, thereby encouraging the creation of a secondary market for gas discounts so that layer 2 rollups (L2s) and other participants can transact on the network more cheaply. He recommended an alternative EIP, EIP 7703, which increases calldata costs at a fixed rate to address these issues.
Buterin said that while Morris’s concerns are valid, the likelihood of a secondary market for calldata being created as a result of EIP 7623 is not actually high, as the number of users who would choose to participate in such a market would be extremely limited. Buterin noted that the main players affected by EIP 7623 are the layer-2 development team Starkware and Inscription creators. He added that while the total addressable market for a secondary calldata market is small, the upside to capping the maximum block size via a calldata increase is extremely high, as it could allow developers to raise the blob gas limit, thus expanding Ethereum’s ability to support L2. Vitalik also said that a flat increase in calldata costs, as Morris suggests, would also have a harsher impact on L2 and other stakeholders than the current EIP. Buterin shared more thoughts on gas pricing for blobs in a blog post prior to the call.
Toni Wahrstätter, co-author of EIP 7623, agreed with Buterin, saying he doesn’t think most L2s will create secondary markets for calldata from a practicality standpoint. “From a practicality standpoint, it’s not very feasible, especially given that such a market would require trust and a high level of coordination between participants. Imagine that as an L2, you want to publish your data to L1, but you don’t know which address will publish the data and where the data will end up. From a practicality standpoint, you’d need custom indexes and so on. So, I don’t think it’s very feasible,” Wahrstätter said.
Reth developer Georgios Konstantopoulos asked if developers were looking into the possibility of increasing the blobgas limit if EIP 7623 is included in Pectra. If the blob gas limit is not increased along with EIP 7623, Konstantopoulos said the EIP "wouldn't solve a lot of problems." EF researcher Dankrad Feist suggested increasing the blob gas limit to the point where Ethereum's maximum block size is constant, meaning that the space freed up with the increase in calldata costs would be filled up with blobs. EF researcher Ansgar Dietrichs said the EIP would be useful not only in conjunction with an increase in the blob gas limit, but also from a security perspective, as it would potentially ensure that the network is not destabilized by blocks containing a maximum number of transactions and blobs.
Regarding the analysis of the impact of EIP 7623 on smart contracts and transactions, Wahrstätter said that his proposal would have no impact on 98% of users. Beiko also mentioned that EF developer operations engineer Parithosh Jayanthi may be conducting a deeper analysis on the specifics of increasing the blobgas limit, taking into account EIP 7623.
New alternative to EIP 7609
During the call, a developer with the screen name "Charles C" proposed a new EIP for preventing reentrancy attacks in smart contracts. Charles said the proposal, which creates two new opcodes to protect smart contracts, is an alternative to a previous proposal he submitted called EIP 7609, which aims to reduce the base cost of TLOAD/TSTORE in Pectra. Charles said he is not sure why EIP 7609 was not considered for inclusion in Pectra and is still gathering feedback from developers on preventing reentrancy in a cost-effective way. He noted that current solutions, such as OpenZeppelin's Reentrancy Guard and TLOAD/TSTORE opcodes, are too costly for decentralized application developers to use by default. Beiko suggested that developers provide Charles with feedback on this new EIP on the Ethereum Magicians forum.
