EIP 实施进展分享 /b >

Nimbus 开发者 Etan Kissling 把 EIP 7688 和 EIP 7495 的实施工作进展进行了分享。在以太坊的发展历程里，数据序列化方法的升级是极为重要的，而这两个提案在这方面有着重大意义。它们就如同以太坊升级大厦当中的重要基石一样，对未来以太坊的性能以及功能会产生深远的影响。

这两个提案当前的进展引起了业界的关注。开发者团队始终在积极地进行推进工作，以此为以太坊的升级做好准备。尽管具体的时间还不能确定，但是每一次的推进都在促使以太坊朝着更加完善的方向不断发展。

Pectra 升级数据获取方式 /b >

Pectra 升级有要求，CL 客户端获取数据有两种方式。其一，从执行层（EL）去请求所需的状态转换数据；其二，在本地存储区块的关键部分。这样的设计旨在提高数据获取的效率以及稳定性。

在一个信息仓库里，用户有两种选择。一种是可以直接从仓库管理员那里获取信息，另一种是自己保存一部分常用信息，以便在需要的时候能够使用。这两种方式将会为以太坊升级后的运行提供稳固的数据支持。

性能影响警告 /b >

Lighthouse 项目的开发者 Mark Mackey 发出了警告。他表示，如果不进行相关的变更，那么 CL 客户端在 Pectra 测试网的性能可能会受到影响。并且在测试阶段，性能方面的问题会被进一步地放大。

如果不及时进行处理，在正式上线之后有可能会引发一连串的问题，进而对以太坊的正常运行产生影响。这就如同盖房子一般，倘若基础不够牢固，那么房子迟早是会出现问题的。而性能的稳定，是以太坊升级能够取得成功的关键因素之一。

协议变更质疑 /b >

Teku 项目的开发者 Mikhail Kalinin 对此持谨慎态度。他提出疑问，是否真的有必要通过对协议进行改变来处理 Pectra 中 EIPs 所实现的复杂性。因为改变协议不是一件小事情，很可能会产生牵一发而动全身的影响。

或许存在更简便且有效的办法来处理当下的问题，而不是随意去改变协议。就如同修理一台复杂的机器，是不是一定要对其核心设计进行大规模的改动，或者存在更温和的修复手段值得去探讨？

请求统一提议 /b >

Lightclient 提出把所有请求都整合为引擎 API 中的一种单一类型，EL 能够把它传递给 CL 去进行解释。这样做的目的是为了规避引用过去升级时间表所产生的开销。不过，Nimbus 开发者“Dustin”对该提议持反对态度。他觉得此提议没有很好地处理 EL 和 CL 上区块解释的复杂性。在以太坊这个复杂的系统里，任何提议都需要全方位地考虑各种问题。就如同拼图一样，一块位置放错了可能就会致使整个图案不完整。这个提议尽管有着它的初衷，但在实际应用中可能会存在不足之处。

EIP 添加担忧与建议 /b >

开发者们对 EIP 何时能被添加到 Pectra devnet 表示担忧。Pectra devnets 还没有纳入像 PeerDAS 和 EOF 这样的许多 EIP。Jayanthi 建议先弄清楚开发者是否应该在升级中包含这些 EIP。Mackey 提及应用开发者由于这两个 EIP 缺乏清晰度而受到阻碍。Lighthouse 开发者 Sean Anderson 建议从应用开发者那里获取更多意见，以确定这些 EIP 对应用程序的关键程度。共识层（CL）客户端团队正在修复 PeerDAS devne 的问题，并保证其稳定性。Stokes 提出在主网激活 PeerDAS 时，可能会省略抽样功能以降低复杂性。开发者们纷纷发表自己的看法，目的是让以太坊升级更加顺利，就如同一群工程师在精心打造一艘巨轮，每个细节都需考虑周全。

你认为在以太坊的 Pectra 升级当中，哪种观点是最为可行的？赶快去点赞，去分享，并且发表出你自己的看法！