以太坊核心开发者最新会议摘要：Deneb升级信息、Electra升级先考虑的EIP

时间：2024-02-14 阅读：94 来源：

微信扫一扫：分享

微信里点“发现”，扫一下

2024年1月23日，以太坊开发人员齐聚Zoom参加了AllCoreDevelopersConsensus(ACDC)call#126会议。ACDC电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员DannyRyan主持，开发人员在会上讨论和协调对以太坊共识层（CL）的更改。本周，开发者们讨论了在Electra升级中应该优先考虑哪些代码更改。

以下是确认纳入Electra升级的以太坊改进提案（EIP）：

·EIP6110，链上供应验证者存款

·EIP7002，执行层触发退出

·EIP7549，将委员会索引移出证明

由于时间有限，开发者们同意在下一次ACDC会议上继续讨论EIP7251（增加MAX_EFFECTIVE_BALANCE）、EIP7594（对等数据可用性采样）以及与SSZ相关的EIP。他们还同意不将EIP6914（重用验证者索引）和EIP7547（包含列表）列为Electra升级的优先考虑，因为希望保持升级范围狭窄，并且最好能在今年年底之前在主网上实施。

Deneb升级最新消息

DannyRyan简要介绍了Deneb升级的最新情况。在2024年1月24日星期三，以太坊基金会发布了一篇博客，详细列出了在Sepolia和Holesky上进行的Deneb升级的所有最新客户端发布。这两个测试网络将是Deneb升级在以太坊主网激活之前的最后两个测试网。Sepolia计划于1月30日激活Deneb，而Holesky则将于一周后的2月7日激活。

Electra讨论

通话的剩余时间用来讨论Deneb之后被称为Prague/Electra的下一个升级的候选EIP。Prague是以太坊执行层（EL）升级的名称，而Electra是共识层（CL）升级的名称。上周，开发人员审查了主要影响EL协议的Prague提案。而本周，开发人员则审查了主要影响CL协议的Electra提案。

EIP6110:链上供应验证者存款

Teku开发者MikhailKalinin因介绍了EIP6110，该提案将验证者的存款追加到EL块上。进行这项代码更改的动机是为了减少客户端软件设计的复杂性，提升验证者的用户体验。DannyRyan称该EIP为以太坊的「一项主要安全改进」。以太坊基金会的协议支持主管、ACDC会议主席TimBeiko补充说，该EIP是在Prague/Electra升级中，EL客户端团队已经表示支持的两个CL关注的EIP之一。与为Electra提出的其他一些以CL为重点的EIP一样，EIP6110需要对EL进行协议级别的更改。考虑到CL和EL客户端团队对EIP6110的支持，开发人员同意在Prague/Electra中包含这项代码更改。

EIP6914:重用验证者索引

EIP6914将使得完全退出的验证者的索引号能够重新分配给新进入的验证者。这样做的动机是为了防止验证者索引随时间不受限制地增长。Lighthouse开发者「Dapplion」提出了这个EIP，但指出尽管这项代码更改对于以太坊的长期健康至关重要，但在Electra中无需对其进行优先处理。开发人员一致同意在Electra中不将EIP6914列为优先考虑。

EIP7002:执行层可触发退出

DannyRyan分享了EIP7002的背景。「有两个[验证者]密钥。有活跃密钥和提取凭证。活跃密钥管理质押。提取凭证最终拥有资金。自零阶段以来，这种关系可能存在一个缺陷，即只有活跃凭证能够触发退出。因此，如果活跃密钥丢失，或者如果拥有活跃密钥和拥有提取凭证的关系更为动态，就可能出现相当恶劣的情况和结果。」Ryan详细解释说，这个EIP的主要好处之一是在以太坊上实现更多无需信任的质押池设计。作为EL客户端团队表示支持的另一个以CL为重点的EIP，CL客户端团队渴望在Electra中包含EIP7002。与EIP6110一样，7002将需要对EL进行轻微的更改。Ryan指出，该EIP的实施正在从有状态的预编译更改为EVM字节码。他呼吁EVM字节码专家密切关注实施情况，并在由Geth开发者「Lightclient」起草后提供帮助进行审查。

EIP7251:增加最大有效质押

接下来，以太坊基金会研究员迈克·Neuder介绍了EIP7251，该提案将验证者的最大有效质押从32ETH增加到2048ETH。想了解为什么需要进行这项代码更改的背景，请阅读有关验证者集大小增长问题的GalaxyResearchReport。Neuder指出，由于其复杂性以及对其他代码更改（如EIP7002）的依赖性，这项代码更改比其他提案「更有争议」。Lighthouse开发者「Sean」表示支持该提案，但鉴于其复杂性，建议考虑在多个硬分叉中实施这些更改，而不是一次性升级。Neuder对这个想法表示支持。Lodestar开发者GajinderSingh不赞成将EIP7251的实施分开到多个分叉中，担心这会在长期内给开发人员带来更多麻烦。

EIP7002中最大的复杂性之一是协议内的质押合并功能，该功能将使现有的验证者节点运营商能够在最小化收益损失的情况下合并来自多个验证者的质押。根据Neuder及其同事提出的设计，验证者节点运营商只会在256个纪元（约27小时）的一段时间内失去奖励。Neuder表示，他和同事已经就EIP7002的设计咨询了Lido、Coinbase和Figment等主要质押服务提供商，并获得了他们对这一代码更改的支持。

代表Prysm团队的开发者TerenceTsao表示，他们不赞成在Electra中包含EIP7002，因为EL客户端团队希望在年底之前执行Prague/Electra升级。Tsao说：「我们认为这个EIP的复杂性太大，无法适应即将在十月或十一月到来的小型分叉。」关于Prysm团队对应该包含在Electra中的EIP的全面观点，可以在这篇博客文章中阅读。Prysm开发者「Potuz」补充说，在他看来，没有能够显著减少EIP7002复杂性的「迷你版本」，以便仍然将其纳入Electra。关于EIP7002，Potuz表示：「我不明白这如何在2024年的任何形式下实施。」

然而，Potuz也补充说，如果开发人员愿意将Electra的实施范围延迟到2025年，那么Prysm团队将提供升级的不同优先级，并推动包含许多其他代码更改，包括EIP7002，以及与正式提案生成器分离和数据可用性抽样相关的EIP。他说：「我们非常保守，因为我们知道我们从未在一年内分叉过两次，尤其是在CL中，如果我们的范围是在今年，尝试放入这么多EIP是不现实的。」鉴于在Electra中包含此代码更改遇到的阻力，Ryan建议继续讨论Electra的其他提案EIP，并在另一次电话会议上再次讨论EIP7002。

EIP7547:包含列表

EIP7547创建了一种机制，通过该机制验证者可以强制在一个区块中包含某些交易。其主要动机是提高以太坊的审查抗性。与其他几位开发人员一起起草了该提案的Neuder解释说，以太坊上已经有67%的区块生成者在审查交易，超过90%的验证者接收来自第三方生成者的区块。在以太坊上有明显需要增强审查抗性。然而，Neuder指出，在强制交易包含列表的实施方面存在一些开放的设计问题，主要涉及到需要满足的确切条件。

Tsao插话称，Prysm团队过去几个月一直在实施EIP7547，并进行了正式提案生成器分离。然而，由于EIP7547的复杂性，他不认为这个代码更改是Electra的合适候选项。Sean和Potuz都对EIP的复杂性表示担忧。Singh建议客户团队改为全面实施构建器覆盖标志功能，这是一种机制，如果在EL上检测到审查活动，将导致验证者回归到本地区块生产。

由于开发人员对此代码更改的反对，Ryan建议不将其列为Electra升级的优先事项。Potuz再次强调，如果开发人员能够改变对分叉范围和主网激活时间的期望，Prysm团队将支持在Electra中包含EIP7547。

EIP7549:将委员会索引移出证明

接着，Dapplion分享了EIP7549，这是一项仅影响CL的代码更改。这一代码更改将使共识投票的聚合更为高效，可通过多种方式实施，从低到高复杂度不等。以太坊基金会研究员DankradFeist支持选择实施EIP7549的最简单方式，即在CL客户端中简单地将「AttestationData」中的「index」字段的数值设为零。DannyRyan也支持这一策略。开发人员同意以最简单的形式将EIP7549纳入Electra。

EIP7594:对等数据可用性抽样(PeerDAS)

Ryan介绍了EIP7594，这是一个旨在将EIP4844的目标blob数量扩展到每个区块的3个blob之外的提案。开发人员扩展以太坊数据可用性的方式是通过启用节点对blob数据进行抽样，而不是下载完整的blob。尽管EIP7594的设计并不复杂，但其在网络层的实施将需要客户团队投入大量的努力和测试。Tsao询问EIP是否将与目标blob数量的增加相结合，如果不是，EIP是否需要共识级别的更改来实施。Ryan确认，在其当前形式下，EIP7594不需要任何共识更改，可以独立于硬分叉升级之外实施。然而，他表示，EIP7594是否应与blob数量的增加相配对是一个尚未确定的问题，后者将需要共识更改进行更新。

Feist插话评论了在激活Deneb后来自Layer2协议的blob需求。Feist说：「[需求]目前大约是每个区块一个blob，但在过去一年里增长了10倍。」他补充说：「这很快就会变得紧迫，因为我们将很快进入rollups也会质疑为什么我们根本不使用4844，如果它比调用数据还要便宜的领域。我认为[对blob的需求]是我对此最小的担忧。我认为在4844之后，这将变得非常明显。」有关EIP4844和Deneb升级的背景，请阅读这份GalaxyResearch报告。

Dapplion赞成在Electra中优先考虑EIP7594，表示：「我认为每个EIP都有其优点，但从时间和产出的角度来看，扩展仍然是最好的投资。回报率非常明显。因此，将其列为首要任务似乎是非常不明智的。」Lighthouse开发人员PawanDhananjay要求了解PeerDAS在验证大量blob数据方面的效率以及实施所需的密码库的状态。Feist表示他将回头提供有关这些主题的更多信息。Potuz再次表达了对Electra升级范围的担忧，以及如果包括EIP7594，则升级可能会变得过大，无法在年底之前在主网上激活目标。Potuz说：「我们的印象是…我们打算通过在2024年范围内对[Electra]进行优先处理，来优先考虑在2025年优先考虑Verkle。我不明白我们如何能够并行进行这个和Verkle，并在今年发布类似这样的东西。这就是为什么如果我们将其范围定在今年，我们就不支持这个小型分叉的原因。」

以太坊基金会DevOps工程师ParithoshJayanthi回应了关于与Verkle并行测试PeerDAS的担忧。Jayanthi表示，他的团队正在研究一种通过隔离的影子分叉可靠测试Verkle的方法，EL客户端可以在没有DevOps团队支持的情况下独立启动。如果这个功能能够实现，那么在EL团队致力于Verkle升级的同时，DevOps团队将有更多带宽来帮助优先考虑在此期间测试PeerDAS。Ryan建议将PeerDAS作为Electra中的有条件的EIP，并由CL客户端团队与其他ElectraEIP一起进行工作，有权在延迟测试的情况下将其排除在升级之外。开发人员同意为了节省时间，推迟对PeerDAS的讨论，将其留待下一次ACDC会议。

SSZ相关的EIP

最后，Nimbus开发者EtanKissling正领导努力将以太坊的序列化方案从RLP更新为SSZ，并介绍了与SSZ格式相关的五个EIP。这些与SSZ相关的EIP将有助于减小交易包含证明的大小，减少由于EL和CL之间序列化格式差异而产生的协议复杂性，并在EL块头中使用的数据字段中引入更大的准确性。Kissling提出的EIP包括：

·EIP-6404:SSZ交易Root

·EIP-6465:SSZ提款Root

·EIP-6466:SSZ收据Root

·EIP-6493:SSZ交易签名方案

·EIP-7495:SSZ稳定容器

这些EIP中的每一个都需要对EL进行后续更改。因此，Ryan建议征求EL客户端团队关于是否愿意在Prague/Electra升级中包含这些更改的反馈。由于通话时间有限，Ryan还建议在下一次ACDC通话中更详细地讨论这些EIP。