[加密王]2024年2月28日，以太坊开发者齐聚

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 上的任何问题。

热点：以太 以太坊 太坊 加密 开发者