以太坊核心開發者最新會議摘要：Pectra 升級或將分成兩個硬分叉

撰文：Christine Kim

编译：Luccy，BlockBeats

编者按：以太坊所有核心开发者共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 134 次电话会议，本次会议上，开发者们探讨了多个关键 EIP 的实现细节和技术挑战，包括 EIP 7549、EIP 7251、EIP 6110、EIP 7688 等。

此外，开发者们还深入讨论了 PeerDAS 的实施，这项数据可用性采样技术预计将显著提升以太坊网络支持 Rollups 及其数据可用性需求的能力。会议中提出了将 Pectra 分成两个硬分叉进行升级的建议，并讨论了不同 EIP 的激活时间和相互依赖关系的问题。

Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：

2024 年 5 月 30 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #134 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Alex Stokes 主持，开发人员在会上讨论和协调对以太坊共识层（CL，也称为信标链）的变更。本周，开发者们讨论了 Pectra Devnet 0 启动后的经验和未解决的问题。他们还辩论将 Pectra 升级的范围扩大到包括 peerDAS 和 SSZ 容器代码更改的可行性。

Devnet 0 回顾

根据 Pectra 在 Devnet 0 上的启动情况，客户端团队已同意在硬分叉激活期间保持 EIP 7549 影响的验证行为不变。在之前的一次 ACDC 会议上，开发者们曾考虑过多种方案，以确保在分叉期间 EIP 7549 的影响不会导致大量无效验证。为了避免使升级变得更加复杂，客户端团队决定在与其他 Pectra EIP 相同的纪元激活 EIP 7549，且在分叉前后不改变验证行为。

关于 EIP 7251，开发者们仍然不确定是否应该允许从执行层（EL）触发质押 ETH 的合并。这对于像 Lido 这样的质押池来说将是一个理想的功能，这样质押的合并就不必依赖于节点操作员，而是可以通过智能合约来实现。Stokes 建议在几周后检查客户端实现验证者质押合并的进展，然后再确定它们应该是 EL 操作还是 CL 操作。

然后，开发者们讨论了关于 EIP 6110 下验证者存款最终确认的一些未解问题。Teku 开发者 Mikhail Kalinin 在会议前的一条 GitHub 评论中总结了这些问题的解决方向。Lighthouse 开发者「sean」提出了一个关于 Engine API 中「GetPayloadBodies」请求的版本控制的问题。Stokes 建议开发者们在 GitHub 上针对这个问题创建的 pull request 中发表他们的意见。

EIP 7549 变化

Nimbus 开发者 Etan Kissling 建议对 EIP 7549 的实现进行一个小改动。「这是关于泛化索引的稳定性问题。当我们在容器中间添加一个新字段时，后续字段会被分配一个新的索引，这会打破基于 EIP 4788 在执行层（EL）的证明，并且有些误导性。……因此，我建议将新字段移动到末尾，以避免这两个问题。」Kissling 解释道。对此改动没有人提出反对意见。Stokes 建议开发者在 GitHub 上查看 Kissling 提出的 pull request。

另一个对 EIP 7549 的改动是在会议上提出的，将请求和其他由 EL 触发的请求设计为 EL 区块的附加程序。关于这个改动，Kalinin 表示：「在我看来，这是一个非常不错的设计方案，它简化了 EL……而且这基本上是对执行层区块中泛化请求的一种替代方案。」Stokes 建议在下次 CL 会议上再次讨论这个话题，以便开发者有更多时间审查 GitHub 上的这个提案。

Pectra 范围讨论

有一些聚焦于共识层（CL）的 EIP 尚未正式包含或排除在 Pectra 升级之外。本周会议上，开发者们讨论了是否在 Pectra 中加入 EIP 7688 和 PeerDAS。EIP 7688 采用了「StableContainer」SSZ 数据结构的一部分，以确保 EIP 7549 对证明的更改具备向前兼容性。作为背景介绍，SSZ 是一种在 CL 中使用的数据结构，开发者希望在执行层（EL）中也使用它。有关 SSZ 转变的更多信息，请参阅之前的会议记录。PeerDAS 是以太坊上数据可用性采样的实现，预计将大大增强网络支持 rollups 及其数据可用性需求的能力。实际操作中，PeerDAS 预计将验证者可以附加到区块的 blob 交易数量从每个区块 3 个增加到 64 个或更多。

以太坊基金會開發者營運工程師 Barnabas Busa 表示，開發者已經在一個開發網路上啟動了 PeerDAS 的早期迭代版本。 「我認為很多客戶端已經發現了很多問題，當我們有了實質的進展時，隨時都可以重新啟動一個新的開發網絡，」Busa 說。 Stokes 詢問開發者是否願意在可能導致升級延遲的情況下將 PeerDAS 添加到 Pectra 中。

一位暱稱為「Nishant」的開發者重新提出了將 PeerDAS 活化與 Pectra 中其他 EIP 的活化分開的建議。雖然這是可行的，但另一位暱稱為「atd」的開發者強調，如果開發者打算在短時間內依序啟動這些升級，用戶還是需要同時升級他們的軟體。 atd 說：「我認為，在另一次升級兩個月後進行分叉是有點瘋狂的。如果我們要協調所有人升級客戶端，我們不想在兩個月後再讓所有人升級客戶端。那樣的話，甚至連一個發布週期都不夠。 Stokes 表示，即使這會導致升級延遲，他也希望將 PeerDAS 納入 Pectra 中。 Grandine 用戶端開發者 Saulius Grigaitis 提議從 Pectra 移除 EIP 7549 和 EIP 7688，以便支援 PeerDAS。這引發了對 EIP 7688 實施細節的討論。開發者未能就程式碼變更達成一致，並將在下一次 ACDC 會議上重新討論這項提案。

關於 PeerDAS 的話題，開發者們繼續權衡將 Pectra 分成兩個硬分叉的想法。以太坊基金會開發者選項工程師 Parithosh Jayanthi 警告說，如果開發者將 Pectra 分成兩個升級，他們必須小心不要在未來的 Pectra 第二部分中增加更多的 EIP。 Jayanthi 說：「我想提到的一件事是，如果我們考慮分成兩個分叉，我們必須非常小心，不要在接下來的分叉中加入更多的新EIP。我不知道我們是否能夠做到這一點。想法，Lighthouse 開發者「sean」說，他沒有預見到PeerDAS 與當前Pectra EIP 清單之間有很多相互依賴關係。因此，這兩者可以分別進行，之後在開發者對它們的實現更加自信時輕鬆合併。 Atd 同意這一觀點，認為在分別開發和測試這些內容後，將 Pectra EIP、PeerDAS 和 EIP 7688 合併不會有太大風險。

Busa 建議繼續測試 Pectra EIP 和 PeerDAS，但將程式碼變更設計成 PeerDAS 在開發網路和測試網路上比 Pectra EIP 晚一個 epoch 啟動。他指出，這已經是在 Devnet 0 上進行 Pectra EIP 和 PeerDAS 測試的方式。 Busa 說：「實際上沒有什麼需要改變」，他補充說，如果 PeerDAS 在其他 Pectra EIP 準備好時還未準備好，開發者可以將該程式碼更改從升級中刪除。這引發了幾個關於 PeerDAS 不同激活 epoch 如何影響客戶端團隊工作的疑問。最終，開發者同意繼續開發 PeerDAS 及 Pectra EIP，但前提是 PeerDAS 將在開發網路和測試網路上在不同的 epoch 啟動。

如前文所述，開發者同意將 EIP 7688 是否包含在 Pectra 中的討論留到下一次 ACDC 電話會議。

以上是以太坊核心開發者最新會議摘要：Pectra 升級或將分成兩個硬分叉的詳細內容。更多資訊請關注PHP中文網其他相關文章！