作者： 币安app官方 日期：2024-07-07 19:47
以太坊所有核心开发者共识电话（ACDC）每两周举行一次，主要讨论和协调对以太坊共识层（CL）的更改。本次为 ACDC 第 126 次电话会议，会议还涵盖了对以太坊权益奖励曲线变更的讨论，以及对硬分叉升级中可能引入的其他变更的展望。
在会上，开发者们讨论了即将到来的以太坊 Electra 升级的相关议题，包括已确认纳入 Electra 的 EIP 和一些备选 EIP 的讨论。此外，会议还讨论了有关 Deneb 升级的更新，包括 Deneb 在 Sepolia 和 Holesky 两个测试网络上的激活计划。在会议的后半部分，开发者们还就 Electra 升级后的 Prague 升级进行了讨论。
Galaxy Digital 研究副总裁 Christine Kim 对本次会议要点做了详细记录，BlockBeasts 将原文编译如下：
2024 年 1 月 23 日，以太坊开发人员齐聚 Zoom 参加了 All Core Developers Consensus (ACDC) call #126 会议。ACDC 电话会议是一个每两周举行一次的系列会议，由以太坊基金会研究员 Danny Ryan 主持，开发人员在会上讨论和协调对以太坊共识层（CL）的更改。本周，开发者们讨论了在 Electra 升级中应该优先考虑哪些代码更改。
以下是确认纳入 Electra 升级的以太坊改进提案（EIP）：
EIP 6110，链上供应验证者存款
EIP 7002，执行层触发退出
EIP 7549，将委员会索引移出证明
由于时间有限，开发者们同意在下一次 ACDC 会议上继续讨论 EIP 7251（增加 MAX_EFFECTIVE_BALANCE）、EIP 7594（对等数据可用性采样）以及与 SSZ 相关的 EIP。他们还同意不将 EIP 6914（重用验证者索引）和 EIP 7547（包含列表）列为 Electra 升级的优先考虑，因为希望保持升级范围狭窄，并且最好能在今年年底之前在主网上实施。
Danny Ryan 简要介绍了 Deneb 升级的最新情况。在 2024 年 1 月 24 日星期三，以太坊基金会发布了一篇博客，详细列出了在 Sepolia 和 Holesky 上进行的 Deneb 升级的所有最新客户端发布。这两个测试网络将是 Deneb 升级在以太坊主网激活之前的最后两个测试网。Sepolia 计划于 1 月 30 日激活 Deneb，而 Holesky 则将于一周后的 2 月 7 日激活。
通话的剩余时间用来讨论 Deneb 之后被称为 Prague/Electra 的下一个升级的候选 EIP。Prague 是以太坊执行层（EL）升级的名称，而 Electra 是共识层（CL）升级的名称。上周，开发人员审查了主要影响 EL 协议的 Prague 提案。而本周，开发人员则审查了主要影响 CL 协议的 Electra 提案。
Teku 开发者 Mikhail Kalinin 因介绍了EIP 6110，该提案将验证者的存款追加到 EL 块上。进行这项代码更改的动机是为了减少客户端软件设计的复杂性，提升验证者的用户体验。Danny Ryan 称该 EIP 为以太坊的「一项主要安全改进」。以太坊基金会的协议支持主管、ACDC 会议主席 Tim Beiko 补充说，该 EIP 是在 Prague/Electra 升级中，EL 客户端团队已经表示支持的两个 CL 关注的 EIP 之一。与为 Electra 提出的其他一些以 CL 为重点的 EIP 一样，EIP 6110 需要对 EL 进行协议级别的更改。考虑到 CL 和 EL 客户端团队对 EIP 6110 的支持，开发人员同意在 Prague/Electra 中包含这项代码更改。
EIP 6914 将使得完全退出的验证者的索引号能够重新分配给新进入的验证者。这样做的动机是为了防止验证者索引随时间不受限制地增长。Lighthouse 开发者「Dapplion」提出了这个 EIP，但指出尽管这项代码更改对于以太坊的长期健康至关重要，但在 Electra 中无需对其进行优先处理。开发人员一致同意在 Electra 中不将 EIP 6914 列为优先考虑。
Danny Ryan 分享了 EIP 7002 的背景。「有两个 [验证者] 密钥。有活跃密钥和提取凭证。活跃密钥管理质押。提取凭证最终拥有资金。自零阶段以来，这种关系可能存在一个缺陷，即只有活跃凭证能够触发退出。因此，如果活跃密钥丢失，或者如果拥有活跃密钥和拥有提取凭证的关系更为动态，就可能出现相当恶劣的情况和结果。」Ryan 详细解释说，这个 EIP 的主要好处之一是在以太坊上实现更多无需信任的质押池设计。作为 EL 客户端团队表示支持的另一个以 CL 为重点的 EIP，CL 客户端团队渴望在 Electra 中包含 EIP 7002。与 EIP 6110 一样，7002 将需要对 EL 进行轻微的更改。Ryan 指出，该 EIP 的实施正在从有状态的预编译更改为 EVM 字节码。他呼吁 EVM 字节码专家密切关注实施情况，并在由 Geth 开发者「Lightclient」起草后提供帮助进行审查。
接下来，以太坊基金会研究员迈克·Neuder 介绍了 EIP 7251，该提案将验证者的最大有效质押从 32 ETH 增加到 2048 ETH。想了解为什么需要进行这项代码更改的背景，请阅读有关验证者集大小增长问题的 Galaxy Research Report。Neuder 指出，由于其复杂性以及对其他代码更改（如 EIP 7002）的依赖性，这项代码更改比其他提案「更有争议」。Lighthouse 开发者「Sean」表示支持该提案，但鉴于其复杂性，建议考虑在多个硬分叉中实施这些更改，而不是一次性升级。Neuder 对这个想法表示支持。Lodestar 开发者 Gajinder Singh 不赞成将 EIP 7251 的实施分开到多个分叉中，担心这会在长期内给开发人员带来更多麻烦。
EIP 7002 中最大的复杂性之一是协议内的质押合并功能，该功能将使现有的验证者节点运营商能够在最小化收益损失的情况下合并来自多个验证者的质押。根据 Neuder 及其同事提出的设计，验证者节点运营商只会在 256 个纪元（约 27 小时）的一段时间内失去奖励。Neuder 表示，他和同事已经就 EIP 7002 的设计咨询了 Lido、Coinbase 和 Figment 等主要质押服务提供商，并获得了他们对这一代码更改的支持。
代表 Prysm 团队的开发者 Terence Tsao 表示，他们不赞成在 Electra 中包含 EIP 7002，因为 EL 客户端团队希望在年底之前执行 Prague/Electra 升级。Tsao 说：「我们认为这个 EIP 的复杂性太大，无法适应即将在十月或十一月到来的小型分叉。」关于 Prysm 团队对应该包含在 Electra 中的 EIP 的全面观点，可以在这篇博客文章中阅读。Prysm 开发者「Potuz」补充说，在他看来，没有能够显著减少 EIP 7002 复杂性的「迷你版本」，以便仍然将其纳入 Electra。关于 EIP 7002，Potuz 表示：「我不明白这如何在 2024 年的任何形式下实施。」
然而，Potuz 也补充说，如果开发人员愿意将 Electra 的实施范围延迟到 2025 年，那么 Prysm 团队将提供升级的不同优先级，并推动包含许多其他代码更改，包括 EIP 7002，以及与正式提案生成器分离和数据可用性抽样相关的 EIP。他说：「我们非常保守，因为我们知道我们从未在一年内分叉过两次，尤其是在 CL 中，如果我们的范围是在今年，尝试放入这么多 EIP 是不现实的。」鉴于在 Electra 中包含此代码更改遇到的阻力，Ryan 建议继续讨论 Electra 的其他提案 EIP，并在另一次电话会议上再次讨论 EIP 7002。
EIP 7547 创建了一种机制，通过该机制验证者可以强制在一个区块中包含某些交易。其主要动机是提高以太坊的审查抗性。与其他几位开发人员一起起草了该提案的 Neuder 解释说，以太坊上已经有 67% 的区块生成者在审查交易，超过 90% 的验证者接收来自第三方生成者的区块。在以太坊上有明显需要增强审查抗性。然而，Neuder 指出，在强制交易包含列表的实施方面存在一些开放的设计问题，主要涉及到需要满足的确切条件。
Tsao 插话称，Prysm 团队过去几个月一直在实施 EIP 7547，并进行了正式提案生成器分离。然而，由于 EIP 7547 的复杂性，他不认为这个代码更改是 Electra 的合适候选项。Sean 和 Potuz 都对 EIP 的复杂性表示担忧。Singh 建议客户团队改为全面实施构建器覆盖标志功能，这是一种机制，如果在 EL 上检测到审查活动，将导致验证者回归到本地区块生产。
由于开发人员对此代码更改的反对，Ryan 建议不将其列为 Electra 升级的优先事项。Potuz 再次强调，如果开发人员能够改变对分叉范围和主网激活时间的期望，Prysm 团队将支持在 Electra 中包含 EIP 7547。
接着，Dapplion 分享了 EIP 7549，这是一项仅影响 CL 的代码更改。这一代码更改将使共识投票的聚合更为高效，可通过多种方式实施，从低到高复杂度不等。以太坊基金会研究员 Dankrad Feist 支持选择实施 EIP 7549 的最简单方式，即在 CL 客户端中简单地将「AttestationData」中的「index」字段的数值设为零。Danny Ryan 也支持这一策略。开发人员同意以最简单的形式将 EIP 7549 纳入 Electra。
Ryan 介绍了 EIP 7594，这是一个旨在将 EIP 4844 的目标 blob 数量扩展到每个区块的 3 个 blob 之外的提案。开发人员扩展以太坊数据可用性的方式是通过启用节点对 blob 数据进行抽样，而不是下载完整的 blob。尽管 EIP 7594 的设计并不复杂，但其在网络层的实施将需要客户团队投入大量的努力和测试。Tsao 询问 EIP 是否将与目标 blob 数量的增加相结合，如果不是，EIP 是否需要共识级别的更改来实施。Ryan 确认，在其当前形式下，EIP 7594 不需要任何共识更改，可以独立于硬分叉升级之外实施。然而，他表示，EIP 7594 是否应与 blob 数量的增加相配对是一个尚未确定的问题，后者将需要共识更改进行更新。
Feist 插话评论了在激活 Deneb 后来自 Layer 2 协议的 blob 需求。Feist 说：「[需求] 目前大约是每个区块一个 blob，但在过去一年里增长了 10 倍。」他补充说：「这很快就会变得紧迫，因为我们将很快进入 rollups 也会质疑为什么我们根本不使用 4844，如果它比调用数据还要便宜的领域。我认为 [对 blob 的需求] 是我对此最小的担忧。我认为在 4844 之后，这将变得非常明显。」有关 EIP 4844 和 Deneb 升级的背景，请阅读这份 Galaxy Research 报告。
Dapplion 赞成在 Electra 中优先考虑 EIP 7594，表示：「我认为每个 EIP 都有其优点，但从时间和产出的角度来看，扩展仍然是最好的投资。回报率非常明显。因此，将其列为首要任务似乎是非常不明智的。」Lighthouse 开发人员 Pawan Dhananjay 要求了解 PeerDAS 在验证大量 blob 数据方面的效率以及实施所需的密码库的状态。Feist 表示他将回头提供有关这些主题的更多信息。Potuz 再次表达了对 Electra 升级范围的担忧，以及如果包括 EIP 7594，则升级可能会变得过大，无法在年底之前在主网上激活目标。Potuz 说：「我们的印象是…我们打算通过在 2024 年范围内对 [Electra] 进行优先处理，来优先考虑在 2025 年优先考虑 Verkle。我不明白我们如何能够并行进行这个和 Verkle，并在今年发布类似这样的东西。这就是为什么如果我们将其范围定在今年，我们就不支持这个小型分叉的原因。」
以太坊基金会 DevOps 工程师 Parithosh Jayanthi 回应了关于与 Verkle 并行测试 PeerDAS 的担忧。Jayanthi 表示，他的团队正在研究一种通过隔离的影子分叉可靠测试 Verkle 的方法，EL 客户端可以在没有 DevOps 团队支持的情况下独立启动。如果这个功能能够实现，那么在 EL 团队致力于 Verkle 升级的同时，DevOps 团队将有更多带宽来帮助优先考虑在此期间测试 PeerDAS。Ryan 建议将 PeerDAS 作为 Electra 中的有条件的 EIP，并由 CL 客户端团队与其他 Electra EIP 一起进行工作，有权在延迟测试的情况下将其排除在升级之外。开发人员同意为了节省时间，推迟对 PeerDAS 的讨论，将其留待下一次 ACDC 会议。
最后，Nimbus 开发者 Etan Kissling 正领导努力将以太坊的序列化方案从 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。
以太坊基金会研究员 Ansgar Dietrichs 提出了他在以太坊基金会同事 Anders Elowsson 关于更改权益奖励曲线的研究帖子。根据 Elowsson 的研究，减少奖励可能是可行的，以减少以太坊的通货膨胀并降低验证器集大小增长的速度。Ryan 鼓励开发人员审查 Elowsson 的研究，并在此基础上考虑在 Electra 或之后的不同硬分叉升级中包含的任何潜在行动项目或 EIP。