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

以太坊的核心开发者们每两周举行一次共识电话（ACDC），主要是为了讨论和协调对以太坊共识层（CL）的变更。这次是第138次会议，主要讨论了Pectra Devnet 1的启动、信标区块体和引擎API结构的变更，以及将EIP 7688和EIP 7495纳入Pectra升级的可能性。此外，还探讨了PeerDAS的实现进展和一些未解决的问题。以下是会议的详细内容：

Pectra Devnet 1 的启动

Pectra Devnet 1于7月23日启动，但网络并不稳定。Erigon客户端在启动后不久就遇到了问题，随后一个EIP 7702交易导致网络分裂成三个状态。开发者们正在努力调试客户端并解决链分裂问题。

引入 ExecutionPayloadEnvelope

Prysm开发者Potuz提出了对信标链区块执行负载结构的重大改进，以及对引擎API的相应调整。这一提议旨在简化共识层（CL）客户端存储和处理状态转换数据的过程。随着Pectra升级的实施，CL客户端需要访问执行负载的特定部分来正确执行状态转换。然而，现有设计导致这些客户端忽略了执行负载中的一些非必要信息。

Potuz建议引入名为「binded_execution_payload_envelope」的新结构，集中存储执行状态转换所需的关键信息。这种改进将显著提升CL客户端在计算状态转换时的速度和效率。他还强调，这些调整将确保与未来的网络升级，如简单序列化（SSZ）格式的兼容性。

Lighthouse项目的开发者Mark Mackey警告说，如果不实施这些变更，CL客户端在Pectra测试网的性能可能会受到影响。Teku项目的开发者Mikhail Kalinin对此表示谨慎，他质疑是否真有必要通过改变协议来解决Pectra中EIPs实现的复杂性。Potuz则坚持认为，现有的协议设计存在根本性问题，需要修正。他指出：「目前的设计在理念上就存在缺陷，它将对CL状态转换至关重要的数据与完全无关的数据混合在同一级别、同一消息中。因此，我认为当前的设计是错误的，我们正在努力纠正这一错误。」

会议主持人Alex Stokes鼓励开发者在GitHub上继续讨论这个提议。

Devnet 2 的引擎 API 更新

Geth开发者「Lightclient」提出了对引擎API的另一个变更。这个变更旨在使执行层（EL）客户端更容易进行区块转换。EL客户端通过解释区块中的空字段和空字段来确定区块版本。然而，由于Prague的EIP 7685，如果没有分叉时间表，EL客户端将无法根据这些字段区分区块版本。为了避免引用过去升级的时间表的开销，Lightclient提议将所有请求统一为引擎API中的单一类型，EL可以将其传递给CL进行解释。

Lightclient指出，区块的解释在EL和CL之间有所不同，而在这种情况下，CL更适合表示请求数据。他说：「当我们处理区块本身时，区块没有概念，『这是Bellatrix区块。』，就像在CL上一样。我认为你们在区分不同类型的分叉区块方面做得很好。但在EL上，我认为这就是几乎所有客户端实现的方式，我们有一个区块代表所有区块类型，我们使用存在的，比如一个值的空值，来确定那个[分叉]是否活跃。」

Nimbus开发者「Dustin」反对这个提议，说Lightclient的提议并没有充分解决EL和CL上区块解释的复杂性。「这只是将复杂性和混乱从EL转移到CL，而且两个地方都是可行的。将其移到CL并没有解决问题。……它只是移动了问题，」Dustin说。

Stokes断言，CL更适合处理请求的解释，并建议开发者更仔细地查看Potuz和Lightclient在GitHub上提出的引擎API变更。

Pectra 中的 EIP 7688 和 7495

Nimbus开发者Etan Kissling一直在推动以太坊序列化方法更新为SSZ。为了Pectra的目的，他确定了两个中间EIPs，7688和7495，以引入智能合约开发者可以依赖的数据结构，以与未来的SSZ相关变更兼容。Kissling指出，他已经得到了像Rocketpool这样的流动质押池的支持，以及Teku和Lodestar等其他客户端团队的支持。

Stokes警告CL客户端团队不要在Pectra中添加新的EIPs。「Pectra已经非常大了，特别是如果我们最终在分叉中有了PeerDAS。在某个时候，我们需要非常现实地看待分叉的大小以及它所带来的风险。再说一次，我同意Etan给出的这个功能在真空中是有价值的理由，但我认为这是我们做过的最大的硬分叉之一，或者就是最大的，这不应该被轻视，」他说。

开发者们对这些EIP何时可以实际添加到Pectra devnet提出了一些担忧，因为Pectra devnet尚未纳入许多EIP，如PeerDAS和EOF。对此，Parithosh Jayanthi建议首先明确决定开发者是否应该在升级中包括这些EIP。Jayanthi还警告说，在测试CL和EL EIP一起在一个devnet上时存在瓶颈。他在Zoom聊天中写道：「10个直接的EIP一起发货，会使得分叉在组合中测试变得非常复杂。而我们不仅有直接的EIP。」

Lighthouse开发者Sean Anderson分享说，像EigenLayer团队这样的应用开发者正在试图弄清楚Pectra中计划激活的内容，以及这两个EIP的持续缺乏清晰度是他们工作的障碍。Anderson建议从以太坊上的应用开发者那里获取更多关于这些EIP的意见，以确定它们对应用程序有多关键。

Stokes建议稍后再重访这个讨论，以便开发者集中精力解决Pectra Devnet 1的问题。

PeerDAS 更新

开发者们就PeerDAS的最新进展进行了深入讨论。Sean Anderson报告称，共识层（CL）客户端团队正在积极修复在上一轮PeerDAS的devnet中发现的问题，并在启动新的devnet之前确保实现的稳定性。Lodestar和EthereumJS的开发者Gajinder Singh表示，根据最近一次PeerDAS实现者会议的反馈，社区有意向在下一个Pectra devnet中集成PeerDAS。

Stokes提出，根据与以太坊基金会（EF）研究团队及其他开发者的讨论，初步在主网上激活PeerDAS时可能需要省略抽样功能，以降低实现的复杂性。他阐释说，PeerDAS的完整实现涉及分发、抽样和重建三个关键功能。「目前，PeerDAS在Pectra中的规范涵盖了这三个任务。我的直觉告诉我，抽样功能可能是实现过程中最大的复杂点。如果抽样确实带来了难以克服的挑战，我们可以考虑在Pectra中增加blob的数量，同时减少或调整PeerDAS的范围，」Stokes解释道。

Stokes承诺，他将就此想法制定一个正式的提议，并与开发者社区进一步探讨。Singh对此表示支持。Stokes还建议在Pectra升级中正式纳入PeerDAS。对此，Jayanthi询问这是否意味着要在Pectra规范的基础上重新定义PeerDAS规范，并指出合并PeerDAS和Pectra devnets可能会因两者都不稳定而使调试工作复杂化。他建议在规范稳定之前，应保持两个工作流程的独立性。Teku的开发者Enrico Del Fante也赞同Jayanthi的看法。

Stokes注意到，许多专注于PeerDAS实现的开发者未能参加此次会议。他提议在下一次PeerDAS实现者会议上继续探讨PeerDAS的未来步骤。

添加 BeaconBlocksByRange V3

Lighthouse项目的开发者「Dapplion」提出了一项改进方案，旨在帮助客户端在发生长时间链分裂的情况下，能够更有效地同步至主链。他指出，现有的BeaconBlocksByRange V2 RPC协议存在一定的局限性：「当你需要同步一个长分叉的区块，而不确定哪个分支是主链时，按照当前的协议，你只需提交一个插槽范围，节点便会返回它认为正确的区块。尽管你可以通过状态消息查询这些信息，但这一过程存在异步性，可能会引发一些问题。虽然目前主网上尚未出现严重的分叉情况，但如果未来发生类似事件，这将是一个需要解决的问题。」

Dapplion进一步说明，他提出的解决方案相对简单，甚至有可能被纳入即将到来的Pectra升级中。尽管这些改进并非迫在眉睫，Stokes还是鼓励与会的开发者们仔细审查这一提议，并在GitHub上分享他们的看法和建议。