2024 年 2 月 28 日，以太坊開發人員聚集在 Zoom for All Core Developers Execution (ACDE) Call #182 上。

ACDE 電話會議是每兩周一次的系列會議，開發人員在會上討論和協調對以太坊執行層 (EL) 的更改。

本周，這次電話會議由以太坊基金會（EF）研究員 Danny Ryan 主持。

開發人員討論了 Dencun 升級的測試更新以及 Pectra 的幾個候選 EIP。

討論納入 Pectra 中最具爭議的 EIP 是與賬戶抽象相關的代碼更改。

賬戶抽象（AA）是為了向外部擁有的賬戶（EOA）引入更高級別的可編程性，這些賬戶是由用戶控制的以太坊上的賬戶，而不是智能合約代碼。

鄧存更新

EF 開發人員運營 (DevOps) 工程師 Barnabas Busa 分享了 Dencun 升級最終測試的最新情況。

EF 于 2 月 27 日星期二宣布，升級現已正式計劃于 2024 年 3 月 13 日在以太坊主網上激活。正如上周 ACD 電話會議中所討論的，開發人員正在主網影子分叉上測試客戶端軟件的最終版本，該分叉將在是一種測試網，反映了以太坊主網的區塊鏈狀態和活動。

Busa 表示，開發人員已經在主網影子分叉上進行了不同類型的“垃圾郵件測試”。

通過這些測試，節點仍然保持極強的彈性，網絡參與率穩定在接近 100% 的參與率。

盡管沒有出現任何問題，但 Busa 指出，垃圾郵件測試確實對計算機資源（特別是 RAM 和 CPU 開銷）造成了節點的嚴重壓力。

Busa 隨后在電話中提醒大家，Goerli 測試網絡（testnet）很快就會被棄用。

任何使用該測試網絡的人都應該在 4 月 17 日之前將其操作轉移到另一個以太坊測試網。Busa 表示，他已經注意到 Goerli 上的一些大型驗證器節點運營商已經退役了他們的機器。

這導致 2 月 28 日 Goerli 網絡最終確定延遲，但 Goerli 網絡似乎已恢復。

Ryan指出，Goerli的網絡參與率已經很低，徘徊在70%左右。

“說實話，我預計 [參與率] 不會持續到 4 月 17 日，”Busa 說。

“盡管如此，這還是很有趣的事情。”

Busa 詢問他的團隊何時應該停用 Devnet 12，這是去年 11 月推出的專用測試網絡，供客戶團隊測試其 Dencun 升級實施。

如果有任何最后一刻的客戶端版本需要針對 Dencun 進行測試，開發人員同意在 Dencun 升級在以太坊主網上上線后不久關閉 Devnet 12。

Pectra 的追溯 EIP

然后，開發人員討論了兩項針對 Pectra 升級的追溯以太坊改進提案 (EIP)。

追溯性 EIP 是一種代碼更改，可追溯性地向以太坊協議添加約束，這些約束基本上已經存在，但需要澄清以考慮特定的邊緣情況。

第一個追溯 EIP，EIP 7610，將限制智能合約創建的規則擴展到具有預先存在存儲的地址。

有關此代碼更改的更多背景信息，請參閱此處之前的通話記錄。

關于EIP 7610的擔憂之一是代碼更改是否會影響Verkle，這是開發人員在Pectra之后準備升級的代碼更改。

Geth 開發人員 Gary Rong 解釋了 EIP 7610 如何不會對未來的 Verkle 升級造成任何問題。

Hedera Hashgraph 工程師和 Besu 客戶端維護者 Danno Ferrin 對 EIP 7610 可能如何影響 Verkle 表達了一些突出的擔憂，他表示將在 EIP 7610 以太坊魔術師線程中以書面形式分享。

開發人員討論的第二個追溯 EIP 是 EIP 7523，它將正式禁止以太坊和以太坊測試網狀態中的空賬戶的規則。

Ryan 表示，他將仔細檢查是誰在進行分析，以確保任何以太坊網絡、主網或測試網上的帳戶都不會受到此規則的影響（如果實施），并在下一次 ACDE 電話會議上再次重新討論這一問題。

Pectra 的賬戶抽象 EIP

Next, developers discussed potential account abstraction EIPs for inclusion in Pectra. On February 28, a subset of developers gathered for a dedicated meeting on AA where they discussed the broad objectives for the initiative and the various EIPs that could be implemented in the short vs. long-term to achieve these goals. Speaking to the goals of AA, cofounder of Ethereum Vitalik Buterin said, “So the longer term [goal is] this fundamental desire that eventually we have to have some kind of account system that is one, allows key rotations and [two], key deprecations, to allow us quantum resistance. Three, allows batching … [and] allows sponsor transactions and a couple of other smaller things and out of those of course, the first two goals are very clearly not satisfiable with EOAS and so presents a pretty clear case for moving the ecosystem to a place where it's beyond EOA centric, but then this brought the discussion to what are actually the means to get there and what are some of the specific details that are less resolved and what actually is a shorter term roadmap that gets us goals that people want in the short term, but is at the same time compatible with those longer term [goals].”

In the short-term, developers are evaluating three main EIPs for AA, EIP 3074, 5806, and 7377. Developers on the call were divided on the advantages and disadvantages between EIP 3074 and 5806. The main sources of confusion were on the extent to which EIP 3074 would require users to double sign transactions and rely on the out-of-protocol AA standard ERC 4337 for sponsoring transactions in a decentralized way, among other debates on the relative complexity and security of EIP 3074 compared to 5806. EIP 7377 was largely agreed on by developers to be the least controversial AA EIP as it is orthogonal in terms of use case to the other two AA EIPs. EIP 7377 is designed to help users easily migrate their assets in an EOA to a new smart contract wallet while the other two EIPs focus primarily on creating new AA functionalities that would support batched transaction authorization and gas sponsorship.

Developers did not come to a consensus about these three EIPs and agreed to continue the discussion on them over the next few weeks.

Other EIPs for Pectra

Developers briefly discussed a few other candidate EIPs for Pectra including:

EIP 7623, increase calldata cost: The proposal recommends increasing the cost for regular transactions on Ethereum that primarily use the blockchain for data availability. By adjusting the gas cost for calldata on Ethereum, the EIP reduces the number of call data transactions that can feasibly fit into one block and thereby reduces the maximum size of blocks. A reduction in block size could allow for a higher number of blob transactions instead. Danny Ryan recommended that developers on the call review the EIP over the coming weeks.

EIP 2537, precompile for BLS12-381 curve operations: This proposal which introduces new cryptographic signature schemes to Ethereum has already been approved for inclusion in the Pectra upgrade. One of the authors of the proposal, Antonio Sanso, raised a question about its implementation. Danny Ryan recommended that the question be put down in writing and circulated to developers for further discussion outside of the call.

EIP 5920, PAY opcode: This proposal creates a new operation that would allow users to send ETH to an address without triggering any of the address’ functions. Geth developer Marius van der Wijden said that from further discussion about this EIP with other teams, the testing for the proposal is more complicated than expected. Van der Wijden also noted that the proposal is underspecified. Ferrin added that the PAY opcode is currently specified to use the same code number as a different opcode, the AUTH opcode, so that will need to be rectified by its authors.

EIP 7609, reduce transient storage pricing: This proposal recommends reducing the price of the transient storage opcodes for common use cases by smart contracts such as maintaining a reentrancy log. Van der Wijden and Ryan were in favor of first collecting data on how transient storage opcodes are used after the Dencun upgrade goes live and then resurfacing the discussion on its pricing.

EIP 7639, cease serving history before proof-of-stake: This proposal creates a timeline for EL clients to stop serving historical data from before the Merge upgrade. The motivation for this code change is to reduce the amount of data Ethereum nodes need to store in perpetuity. The proposal also commits to a standardized way for nodes to structure historical pre-Merge data and retrieve it from an external source. Teku developer Mikhail Kalinin noted that this EIP has a dependency on another EIP, EIP 6110, which was approved for inclusion in the Pectra upgrade on a prior ACD call. Developers agreed to review EIP 7639 over the next few weeks in more detail.

Engine API & JSON RPC Changes

Kalinin raised a few questions related to the implementation of the confirmation rule, which is a CL mechanism that confirms over the period of one slot, roughly 12 seconds, whether a block under certain assumptions will remain in the canonical chain and be finalized. This is a powerful feature as many applications built on Ethereum could utilize the information of early block confirmations in their operations. However, to expose the data about early block confirmations, there needs to be a few changes made to the Ethereum Engine API and JSON RPC. Due to a lack of time on the call, Ryan recommended going over these changes in more detail either on next week’s ACD call or the one the week thereafter.

Light Clients Breakout Room

Ryan提醒開發者，下周三，3月6日，將會有一個專門的會議來討論Pectra升級的輕客戶端路線圖。

有關輕客戶端討論的背景信息，請參閱此處之前的電話會議記錄。

最后但并非最不重要的一點是，van der Wijden 提出了構建新的以太坊客戶端版本的提案，以在初始同步期間節省節點 550GB 的帶寬。

Van der Wijden 表示，他正在為新版本準備正式的 EIP，但可以在此處找到他的規范草案。

Ryan 鼓勵開發者審查草案并跟進 Discord 上的任何問題。

熱點：以太 以太坊 太坊 加密 開發者