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 the impact analysis on smart contracts and transactions. Among them, the discussion of EIP 7702 has attracted widespread attention from participants, and the proposal is seen as a potential solution to replace EIP 3074.
Christine Kim, Vice President of Research at Galaxy Digital, detailed the key points of the meeting, and BlockBeats translated the original text 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 Ethereum Foundation protocol support manager Tim Beiko hosts discussions and coordination of changes to the Ethereum Execution Layer (EL). This week, developers discussed the preparation work for Pectra Devnet 0, the implementation updates of EIP 3074, and the urgency of transitioning the serialization method on EL from MPT to SSZ.
Pectra Devnet-0 Update
Barnabas Busa, a developer operations engineer at the Ethereum Foundation, stated that his team is testing the client configuration for the first Pectra developer-focused test network and will strive to ensure the stable configuration of Pectra Devnet 0 by Monday, May 13. According to the Pectra Devnet 0 preparation tracker, the Geth, Nethermind, and EthereumJS client teams have fully implemented the Pectra code specifications.
During the call, Justine Florentine, a developer of Besu, stated that all Pectra EIPs have been implemented on Besu, but his team is still working on debugging the code. Andrew Ashikhmin, a developer of Erigon, mentioned that his team has started working on all EIPs except for EIP 7002, which is the 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, similar to the Erigon team.
Regarding the CL client, Saulius Grigaitis, a developer of Grandine, mentioned that all EIPs have been implemented, but his team encountered some errors when running with the EL client. A representative from the Lighthouse team stated that they are preparing a complete implementation for Pectra Devnet 0 and pointed out that the specifications in the engine API need updating. Mikhail Kalinin, a developer of Teku, 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, as well as several other EIPs.
EIP-3074 Update
Although developers agreed to retain EIP 3074 in the Pectra Devnet 0 specifications, an alternative EIP to replace it has been discussed, 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 improving user control over account programmability. According to Lightclient, all participants agreed that full local account abstraction is still years away from being implemented on Ethereum. However, there is a divergence on whether this means prioritizing changes to the functionality of externally owned accounts (EOAs) or migrating EOAs to smart contract wallets. On the day before the 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 generally have a positive attitude towards EIP 7702. However, he later added that there are still important details to be resolved regarding EIP 7702. For example, details about how to revert EIP 7702 transactions and how to scale the gas cost 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 EIP 7702 achieves similar results to EIP 3074 without creating new opcodes on Ethereum and improves the convenience of static analysis of new EOA behaviors. Ansgar Dietrichs, an EF researcher, suggested considering incorporating EIP 7702 into Pectra and formally deciding whether to replace 7702 with 3074 in about 2 to 4 weeks. It is clear from the developers' discussion of EIP 7702 during the call that further work is needed before the proposal is considered ready for implementation. Ahmad Mazen Bitar, a developer from Nethermind, pointed out that the work done for EIP 3074 may be unlikely to be reused for the implementation of 7702. Beiko confirmed that developers should continue to push for the implementation of EIP 3074 for Devnet 0 and revisit the specifications for Devnet-1 later.
EIP-7685, SSZ, and EIP-6110
Next, developers discussed some concerns raised by Etan Kissling, a developer of Nimbus, regarding EIP 7685, which is the general execution layer requests. In the GitHub comments under this week's call agenda, Kissling questioned whether the proposed design for general execution layer requests is necessary and if this opportunity could be better utilized for transitioning to SSZ, a serialization format that developers have been hoping to update on the execution layer since the merge upgrade. Most of the execution layer client teams on the call supported retaining EIP 7685 in Pectra, and if any obstacles arise from including the EIP in operations, such as optimistic sync of clients, then the design will be reconsidered.
Regarding the transition 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 to be updated when developers transition to SSZ. He pointed out that if developers continue to create new MPT/RLP data structures, delaying the transition to SSZ will only create more work for developers. However, there was not strong support from the execution layer client teams to include EIP 7495, which is the SSZ stable container, in Pectra. A developer named "Dustin" wrote in the Zoom chat that the decision to delay the transition to SSZ is "crazy," and the issues with the SSZ library in EL are "a serious problem."
Regarding EIP 6110, which is the on-chain validator deposit verification, Kissling raised concerns about the deposit ordering. Kalinin agreed that this issue is "a major concern," and he will conduct further investigations in collaboration with major staking pools.
EOF Update
Independent Ethereum protocol developer Danno Ferrin and EF Solidity research lead Alex Beregszaszi shared updates on the implementation work of the Ethereum Object Format (EOF). The background is that EOF is a series of code changes to improve the Ethereum Virtual Machine (EVM), and developers are considering incorporating it into the Pectra upgrade. The original EIP for EOF has been finalized. Developers have also simplified the transaction creation process in EOF and are working on client implementations for EOF.
EIP-7623 Update
A developer using the screen name "William Morris" raised concerns about the gas cost changes for calldata storage in EIP 7623 during the call. He explained that these changes would allow some users to lower fees by bundling their transactions, encouraging the creation of a secondary market for gas discounts, so that Layer 2 rollups (L2s) and other participants can transact more cheaply on the network. He recommended an alternative EIP, EIP 7703, which increases the calldata cost at a fixed rate to address these issues.
Buterin stated that while Morris's concerns are valid, the likelihood of creating a calldata secondary market due to EIP 7623 is not high in practice, as the number of users choosing to participate in 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 authors of the Mingling. He added that while the total addressable market for a secondary calldata market is small, increasing the calldata limit has a high upside for raising the maximum block size, as it allows developers to increase the blob gas limit, thereby expanding Ethereum's support for L2. Vitalik also mentioned that a flat increase in calldata cost would have a more severe impact on L2 and other stakeholders than the current EIP, as suggested by Morris. Buterin shared more thoughts on gas pricing for blobs in a blog post before the call.
Co-author of EIP 7623, Toni Wahrstätter, agreed with Buterin's viewpoint, stating that from a practical perspective, most L2s would not create a secondary market for calldata. "From a practical perspective, this is not very feasible, especially considering that such a market would require 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 custom indexing, and so on. So, I don't think this is very feasible," Wahrstätter said.
Reth developer Georgios Konstantopoulos asked if developers are considering increasing the blob gas limit if EIP 7623 is included in Pectra. Konstantopoulos stated that the EIP "won't solve too many problems" if the blob gas limit is not increased alongside EIP 7623. EF researcher Dankrad Feist suggested raising the blob gas limit to the extent that it does not change the maximum block size of Ethereum, meaning the space released by the increase in calldata cost would be filled with blobs (binary large objects). EF researcher Ansgar Dietrichs stated that the EIP is not only useful when combined with an increase in the blob gas limit 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 impact analysis of EIP 7623 on smart contracts and transactions, Wahrstätter stated that he believes the 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 the 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 creates two new opcodes to protect smart contracts, as an alternative to his previously submitted proposal, EIP 7609, which aims to reduce the basic cost of TLOAD/TSTORE in Pectra. Charles expressed uncertainty about why EIP 7609 was not considered for inclusion in Pectra and is still collecting feedback from developers on a cost-effective way to prevent reentrancy. He pointed out that current solutions, such as OpenZeppelin's Reentrancy Guard and TLOAD/TSTORE opcodes, are too costly and cannot be used by default for decentralized application developers. Beiko suggested that developers provide feedback to Charles on this new EIP on the Ethereum Magicians forum.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
