Author: Christine Kim

Translation: Luccy, BlockBeats

In addition to preparing for Pectra Devnet 0, developers also discussed new EIP proposals, discussions and analysis of existing EIPs, and impact analysis on smart contracts and transactions. Among them, the discussion on EIP 7702 has attracted widespread attention from participants, as the proposal is seen as a potential alternative to EIP 3074.

Christine Kim, Vice President of Research at Galaxy Digital, detailed the key points of the meeting, which BlockBeasts has translated as follows:

On May 9, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) call #187 meeting. The ACDE call is a bi-weekly series of meetings where developers discuss and coordinate changes to the Ethereum Execution Layer (EL), hosted by Tim Beiko, the Ethereum Foundation's protocol support manager. This week, developers discussed the preparation for Pectra Devnet 0, updates to EIP 3074 implementation, and the urgency of transitioning EL's serialization method from MPT to SSZ.

Pectra Devnet-0 Update

Barnabas Busa, Ethereum Foundation's Developer Operations Engineer, stated that his team is testing the first Pectra developer-focused test network's client configuration and will strive 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 code specifications.

During the call, Besu developer Justine Florentine mentioned that all Pectra EIPs have been implemented on Besu, but his team is still debugging the code. Erigon developer Andrew Ashikhmin mentioned that his team has started working on all EIPs except EIP 7002, which is EL-triggered withdrawals. The Reth team shared a link to their implementation tracker in the Zoom chat, showing that their work on EIP 7002 is still pending, similar to the Erigon team.

Regarding the CL client, Grandine developer Saulius Grigaitis mentioned that all EIPs have been implemented, but his team encountered some errors when running with the EL client. Representatives from the Lighthouse team stated that they are about to prepare a complete implementation for Pectra Devnet 0 and noted that specifications in the engine API need updating. Teku developer Mikhail Kalinin mentioned that he is working on adding these updates to the engine API specifications.

Mario Vegas from the EF testing team mentioned 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 Pectra Devnet 0 specification, an alternative EIP has been discussed to replace it, namely EIP 7702. Geth developer "Lightclient" summarized the latest subgroup meeting on EIP 3074, where participants discussed which changes to prioritize in the Pectra upgrade related to enhancing user control over account programmability. According to Lightclient, all participants agreed that full local account abstraction on Ethereum is still years away. However, there is a divergence on whether this means prioritizing changes to external owned accounts (EOAs) functionality or migrating EOAs to smart contract wallets. The 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 allow EOAs to operate like smart contract wallets within a single transaction. Lightclient mentioned that participants from the EIP 3074 subgroup meeting were generally positive about EIP 7702. However, he later added that there are still important details to be resolved regarding EIP 7702. For example, details on how to revert EIP 7702 transactions and how to scale the gas costs of such transactions are still unclear.

If EIP 7702 is accepted and included in the Pectra upgrade, it would be considered to replace EIP 3074 as it achieves similar outcomes without creating new opcodes on Ethereum and enhances the convenience of static analysis for new EOA behaviors. EF researcher Ansgar Dietrichs suggested considering incorporating EIP 7702 into Pectra and formally deciding whether to replace 7702 with EIP 3074 in about 2 to 4 weeks. It is evident from developers' discussions on EIP 7702 during the call that further work is needed before considering the proposal ready for implementation. Nethermind developer Ahmad Mazen Bitar pointed out that the work done for EIP 3074 may be unlikely to be reused for implementing 7702. Beiko confirmed that developers should continue to push forward with the implementation of EIP 3074 for Devnet 0 and revisit the Devnet-1 specification later.

EIP-7685, SSZ, and EIP-6110

Next, developers discussed some concerns raised by Nimbus developer Etan Kissling regarding EIP 7685, which involves general execution layer requests. In the GitHub comments under this week's call agenda, Kissling questioned the need for the proposed design of general execution layer requests and whether this opportunity could be better utilized for transitioning to SSZ, a serialization format that developers have been wanting to update on the execution layer since the merge upgrade. Most execution layer client teams on the call supported keeping EIP 7685 in Pectra, with a reevaluation of the design if any obstacles arise from including the EIP in operations, such as optimistic synchronization of clients.

On the topic of transitioning to SSZ, Kissling explained that the new design format for general execution layer requests is based on traditional serialization formats MPT and RLP, so it will need updating when developers transition to SSZ. He noted that continuing to create new MPT/RLP data structures while delaying the transition to SSZ would only create more work for developers. However, there was not strong support from execution layer client teams to include EIP 7495, namely SSZ Stable Containers, in Pectra. A developer named "Dustin" in the Zoom chat wrote that delaying the SSZ transition decision was "crazy," and the issues with SSZ libraries in EL were "a serious problem."

Regarding EIP 6110, which involves validator deposit verification on-chain, Kissling raised concerns about deposit ordering. Kalinin agreed that this issue is "a major concern," and he will collaborate with major staking pools for further investigation.

EOF Update

Independent Ethereum protocol developer Danno Ferrin and EF Solidity Research Lead Alex Beregszaszi shared updates on the implementation work for EOF. Background-wise, EOF consists of a series of code changes to improve the Ethereum Virtual Machine (EVM), and developers are considering incorporating it into the Pectra upgrade. The core EIP for EOF has been finalized. Developers have also streamlined the transaction creation process in EOF and are working on client implementations for EOF.

EIP-7623 Update

A developer with the screen name "William Morris" raised concerns during the call about gas cost changes in calldata storage in EIP 7623. He explained that these changes would allow some users to lower fees by batching their transactions, encouraging the creation of a gas discount market for trading, enabling Layer 2 rollups (L2s) and other participants to transact more cheaply on the network. He recommended another EIP, EIP 7703, which increases calldata costs at a fixed rate to address these issues.

Buterin mentioned that while Morris's concerns are valid, the likelihood of creating a calldata secondary market due to EIP 7623 is not high, as the number of users opting into such a market would be extremely limited. Buterin pointed out that the main participants affected by EIP 7623 are the Layer 2 development teams Starkware and the creators of Mingling. He added that while the total addressable market for a secondary calldata market is small, increasing calldata limits has a high upside in raising the maximum block size, as it can allow developers to raise blobgas limits, expanding Ethereum's support for L2. Vitalik also stated that, as suggested by Morris, a flat increase in calldata costs would have a more severe impact on L2 and other stakeholders than the current EIP. Buterin shared more thoughts on blob gas pricing in a blog post before the call.

Co-author of EIP 7623, Toni Wahrstätter, agreed with Buterin's views, stating that he believes from a practical standpoint, most L2s would not create calldata.In the secondary market. "From a practical perspective, this is not very feasible, especially considering that such a market requires trust and high coordination among participants. Imagine, 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 practical perspective, you need to customize indexes and so on. So, I don't think this is very feasible," Wahrstätter said.

Reth developer Georgios Konstantopoulos asked if EIP 7623 is included in Pectra, whether developers are considering the possibility of increasing the blob gas limit. If the blob gas limit is not increased along with EIP 7623, Konstantopoulos stated that the EIP "won't solve too many problems." EF researcher Dankrad Feist suggested raising the blob gas limit to the extent of Ethereum's maximum block size remaining constant, which means the space released as calldata costs increase will be filled with blobs (binary large objects). EF researcher Ansgar Dietrichs stated that this EIP is not only useful when combined with an increase in blob gas limits but also useful from a security perspective, as it may ensure that the network does not become unstable due to blocks containing the maximum number of transactions and blobs.

Regarding the analysis of the impact of EIP 7623 on smart contracts and transactions, Wahrstätter stated that his proposal would not affect 98% of users. Beiko also mentioned that EF developer operations engineer Parithosh Jayanthi may be conducting a more in-depth analysis of the specific extent of increasing the blob gas limit, considering EIP 7623.

New Alternative Proposal for EIP 7609

During a conference call, a developer using the screen name "Charles C" proposed a new EIP to prevent reentrancy attacks in smart contracts. Charles stated that the proposal introduces two new opcodes to protect smart contracts, serving as an alternative to his previous proposal named EIP 7609, which aimed to reduce the basic costs of TLOAD/TSTORE in Pectra. Charles mentioned that he is unsure why EIP 7609 was not considered for inclusion in Pectra and is still collecting feedback from developers on cost-effective ways to prevent reentrancy. He pointed out 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 feedback to Charles on this new EIP on the Ethereum Magicians forum.