以太坊Pectra升级启动与PeerDAS进展

以太坊核心开发者最新会议摘要：Pectra 升级启动、PeerDAS 实现进展探讨

以太坊的核心开发者们又开会了，这次是第 138 次全核心开发者共识（ACDC）会议。会议在 2024 年 7 月 25 日通过 Zoom 进行，由以太坊基金会（EF）的研究员 Alex Stokes 主持。这次会议主要讨论了几个重要议题，包括 Pectra Devnet 1 的启动情况、信标区块体和引擎 API 的变更，以及一些关键的以太坊改进提案（EIP）的进展和 PeerDAS 的最新动态。

免费的交易所推荐：

• 欧易交易所 >>>进入官网<<< >>>官方下载<<<
• 币安交易所 >>>进入官网<<< >>>官方下载<<<

Pectra Devnet 1 的启动

Pectra Devnet 1 在 7 月 23 日上线了，但情况不太稳定。Erigon 客户端在启动后不久就出现了问题，导致网络分裂成三个状态。开发者们正在努力修复这些问题，以确保网络的稳定性。

引入 ExecutionPayloadEnvelope

Prysm 开发者 Potuz 提出了一个建议，旨在简化信标链区块执行负载结构和引擎 API 的设计。这次改进是为了提升共识层（CL）客户端处理状态转换数据的效率。Potuz 提出引入一个新的结构「binded_execution_payload_envelope」，来集中存储执行状态转换所需的关键信息。这个改进不仅能提升 CL 客户端的性能，还能确保与未来的网络升级兼容。然而，Lighthouse 项目的 Mark Mackey 警告说，如果不实施这些变更，CL 客户端在 Pectra 测试网的表现可能会受到影响。Teku 项目的 Mikhail Kalinin 对此表示谨慎，认为是否需要通过改变协议来解决 Pectra 中 EIPs 的复杂性值得商榷。Stokes 鼓励开发者在 GitHub 上继续讨论这个提议。

Devnet 2 的引擎 API 更新

Geth 开发者 Lightclient 提出了另一个关于引擎 API 的变更建议，旨在简化执行层（EL）客户端的区块转换过程。由于 Prague 的 EIP 7685 可能导致 EL 客户端无法区分区块版本，Lightclient 建议将所有请求统一为引擎 API 中的单一类型，由 CL 进行解释。然而，Nimbus 开发者 Dustin 对此表示反对，认为这只是将复杂性从 EL 转移到 CL，并没有真正解决问题。Stokes 认为 CL 更适合处理请求的解释，并建议开发者仔细审查 Potuz 和 Lightclient 在 GitHub 上提出的变更建议。

Pectra 中的 EIP 7688 和 7495

Nimbus 开发者 Etan Kissling 一直在推动以太坊序列化方法的更新，以实现 SSZ。为此，他提出了两个中间 EIP，7688 和 7495，以引入与未来的 SSZ 变更兼容的数据结构。Kissling 表示，他已经得到了 Rocketpool 等流动质押池和 Teku、Lodestar 等客户端团队的支持。然而，Stokes 警告 CL 客户端团队不要在 Pectra 中添加新的 EIP，因为 Pectra 已经非常庞大，特别是如果最终包含了 PeerDAS。开发者们对这些 EIP 是否能及时纳入 Pectra devnet 表示担忧，因为许多 EIP 如 PeerDAS 和 EOF 尚未纳入。Jayanthi 建议首先明确决定是否在升级中包括这些 EIP，并警告说在测试 CL 和 EL EIP 时存在瓶颈。Mackey 提到，像 EigenLayer 团队这样的应用开发者正在努力了解 Pectra 中计划激活的内容，而这两个 EIP 的不确定性对他们的工作造成了障碍。Stokes 建议稍后再讨论这个话题，以便开发者集中精力解决 Pectra Devnet 1 的问题。

PeerDAS 更新

开发者们深入讨论了 PeerDAS 的最新进展。Sean Anderson 报告说，CL 客户端团队正在积极修复上一轮 PeerDAS devnet 中发现的问题，以确保实现的稳定性。Gajinder Singh 表示，根据最近一次 PeerDAS 实现者会议的反馈，社区有意向在下一个 Pectra devnet 中集成 PeerDAS。Stokes 提出，初步在主网上激活 PeerDAS 时可能需要省略抽样功能，以降低实现的复杂性。他解释说，PeerDAS 的完整实现涉及分发、抽样和重建三个关键功能，抽样可能是最大的复杂点。如果抽样确实带来了挑战，可以考虑在 Pectra 中增加 blob 的数量，同时减少或调整 PeerDAS 的范围。Stokes 承诺将就此想法制定一个正式的提议，并与开发者社区进一步探讨。Jayanthi 询问这是否意味着需要重新定义 PeerDAS 规范，并指出合并 PeerDAS 和 Pectra devnets 可能会使调试工作复杂化。他建议在规范稳定之前，应保持两个工作流程的独立性。Enrico Del Fante 也赞同 Jayanthi 的看法。Stokes 注意到，许多专注于 PeerDAS 实现的开发者未能参加此次会议，并提议在下一次 PeerDAS 实现者会议上继续探讨 PeerDAS 的未来步骤。

添加 BeaconBlocksByRange V3

Lighthouse 项目的 Dapplion 提出了一项改进方案，旨在帮助客户端在发生长时间链分裂的情况下，能够更有效地同步至主链。他指出，现有的 BeaconBlocksByRange V2 RPC 协议在同步长分叉区块时存在局限性。虽然目前主网上尚未出现严重的分叉情况，但如果未来发生类似事件，这将是一个需要解决的问题。Dapplion 认为他的解决方案相对简单，甚至有可能被纳入即将到来的 Pectra 升级中。尽管这些改进并非迫在眉睫，Stokes 还是鼓励与会的开发者们仔细审查这一提议，并在 GitHub 上分享他们的看法和建议。

免责声明

游乐网为非赢利性网站，所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系youleyoucom@outlook.com。

同类文章