EIP-7688：生存还是毁灭？

要点

EIP-7688 引入了 StableContainer，这是一种新型的设计，旨在稳定 Ethereum Beacon Chain 状态中的 Merkle 树索引。虽然不是一个关键的升级，但它的加入将显著提高依赖 EIP-4788 和 BEACON_ROOTS 预编译的协议的长期兼容性。 这项研究表明，越来越多的生产级协议，包括 Lido、EigenLayer、Relic、Rocket Pool 以及多个 ZK oracle、桥和预确认系统，已经在使用或计划使用 EIP-4788。如果没有 EIP-7688，每次修改 BeaconState 的未来硬分叉都需要这些协议重写证明逻辑、重新审计合约并协调复杂的升级。 通过引入稳定的 Merkle 索引，EIP-7688 消除了这种重复的负担，并实现了跨分叉的兼容性。在即将到来的修改 Beacon 状态的硬分叉中采用它将使协议开发面向未来，降低运营风险，并简化 Ethereum 内外共识数据的链上使用。

简介

将任何 Ethereum 改进提案 (EIP) 纳入网络升级绝非易事。硬分叉并不频繁，并且受到严格的工程时间表的约束，这需要对具有广泛、可证明影响的提案进行细致的优先级排序。每个 EIP 不仅必须证明其技术上的合理性，而且还必须在有限的协调和开发者能力的约束下，证明其在整个生态系统中的相关性。在这种环境下，引入与 Beacon Chain 相关的更改需要格外谨慎，因为它们会影响关键基础设施。

随着 EIP-4788 的激活，该提案将 Beacon Chain 的根暴露给 EVM，协议中出现了一种新的证明设计。这些协议包括 staking 和 restaking 协议、去中心化 oracle 和利用共识根进行信任最小化验证的零知识证明系统。

本研究旨在绘制当前和近期受 EIP-4788 影响的协议格局，考察 staking 框架、Oracle 网络（包括基于 ZK 的架构）和信任最小化基础设施如何在今天与 Beacon Chain 数据交互。它还评估了这些系统在当前模型下面临的约束，以及通过 EIP-7688 扩展 Beacon 数据访问可以实现的潜在设计突破。

虽然最终是否将 EIP-7688 纳入即将到来的硬分叉由社区决定，但本文提供了做出该决定所需的技术和生态系统分析。展望模块化的 Ethereum，了解此 EIP 如何塑造下一代跨链桥、预确认系统和密码学证明机制至关重要。

EIP-7688 概述

EIP-7688 提出了 Ethereum Beacon Chain 状态中数据表示方式的根本性改变，旨在提高依赖共识层数据 Merkle 证明的协议的长期兼容性和开发者人体工程学。

目前，Beacon Chain 使用 SSZ (SimpleSerialize) Merkle 树存储其状态，其中每个字段和嵌套结构都被序列化和哈希以形成状态根。虽然效率很高，但这种设计存在一个关键缺陷：Merkle 树索引在硬分叉中不稳定。随着字段在 BeaconState 中添加或重新排序，特定数据块的 Merkle 路径会发生变化。这种不稳定性破坏了依赖于固定证明索引的链下和链上协议的向后兼容性，从而要求每次共识层更改都要重新建立索引和重新实现。

EIP-7688 引入了 StableContainer 的概念，这是一种新的 SSZ 类型，它为每个字段强制执行固定、确定性的树索引。根据此提案，BeaconState 的特定部分将被重构为 StableContainer 类型，其中每个字段都具有永久分配的索引，即使容器发生变化也是如此。新字段只能以仅追加的方式添加，而弃用的字段会被标记但保留以保持索引稳定性。这种结构性约束允许以这些容器为目标的 Merkle 证明在协议升级中保持有效。

过渡到使用 StableContainer 需要彻底检查数据在 BeaconState 中存储和访问的方式。生成 SSZ Merkle 证明的协议和客户端需要适应新的容器类型。然而，这种一次性调整带来了重大的长期利益：所有未来硬分叉中 Merkle 索引的稳定性。这大大简化了 ZK 证明系统、链上验证器和链下中继器的工作，它们使用 BEACON_ROOTS 来证明关于共识层数据的声明。

通过确保进入 BeaconState 的 Merkle 路径保持一致，EIP-7688 为构建跨分叉兼容协议奠定了可靠的基础。这对于 staking、oracle 和桥 (尤其是跨链桥) 等应用程序尤其重要，这些应用程序依赖于对验证器集、同步委员会和参与记录的可预测访问。

数据抓取

要理解 EIP-7688 的前景，需要将其植根于当前共识层数据的使用方式的现实中。虽然提议的 StableContainer 类型为 BeaconState 提供了一个更强大且面向未来的接口，但其相关性取决于开发者和协议是否已经依赖或计划依赖 EIP-4788。

为了评估这一点，我们使用两种互补的方法进行了全生态系统的扫描。首先，我们分析了在主网上对 BEACON_ROOTS 预编译的所有内部调用，以捕获实时使用模式并识别已部署的协议，这些协议已经在生产中依赖它。其次，我们对公共 GitHub 存储库进行了有针对性的抓取，以查找引用 BEACON_ROOTS 合约地址的项目，从而使我们能够深入了解仍在开发中的即将到来的集成和协议设计。这些方法（如下所述）使我们能够全面了解哪些协议将受益于或因 Beacon Chain 数据访问的可用性和稳定性而中断。

BEACON_ROOTS 内部调用

为了了解哪些协议正在积极使用今天的 EIP-4788，我们分析了过去 90 天内（截至 2025 年 4 月 15 日）对 BEACON_ROOTS 预编译 (0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02) 的所有内部调用。这个集中的时间窗口排除了主要来自非活动或实验性合约的早期交互，使我们能够仅捕获有意义的、生产级的用法。

在调用 BEACON_ROOTS 合约的 7,802 个唯一地址中，有 7,800 个与 EigenLayer 协议 相关。这一发现突出表明，基于 EigenLayer 的 restaking 系统已经严重依赖 EIP-4788，使用它来验证链上的共识层数据。这也表明，访问 Beacon Chain 根不是外围的，而是深深地融入到协议的架构中。

其余两个地址显示了 restaking 之外的显著采用：

• 一个与 Lido Community Staking Module 的 proof verifier 相关联，这是一个 Community Staking 实现，它使用 Beacon 数据来验证提款。
• 一个属于 Relic Protocol，它利用 BEACON_ROOTS 进行链上历史 oracle，这是一种设计模式，可能为未来的 ZK oracle 系统奠定基础。

这些发现表明，几个核心协议类已经在围绕可访问、可验证的 Beacon 数据构建。因此，EIP-7688 引入的结构稳定性和长期可靠性不是一个理论上的改进，它正在迅速成为一种实际的必需品。

GitHub 存储库分析

为了补充链上活动分析，我们通过分析引用 BEACON_ROOTS 合约 (0x000F3df6D732807Ef1319fB7B8bB8522d0Beac02) 的公共存储库，将我们的研究扩展到 GitHub 开发活动。这使我们能够捕获早期阶段的协议设计、概念验证和尚未部署在主网上但正在积极开发中的集成。

我们使用 EIP-4788 将存储库识别并分类为几个关键协议类别：

• Staking 和 Restaking：这包括 Lido、EigenLayer、Rocket Pool 和 Karak 等项目，所有这些项目都集成了 Beacon Chain 数据，用于验证器提款验证和 slashing 条件。这些协议严重依赖 EIP-4788，并且有望从 EIP-7688 中引入的稳定性保证中获益匪浅。

重要的是要注意，著名的 Rocket Pool 协议将在其即将到来的升级中使用 EIP-4788 证明。可以在 BeaconStateVerifier 合约中看到此用法，该合约严重依赖 BEACON_ROOTS 预编译。鉴于其当前的实现，为即将到来的硬分叉升级验证器部分将是一项复杂的任务，因此 Rocket Pool 将从 EIP-7688 的包含中受益匪浅。

如果没有 EIP-7688，该协议将需要重构其验证器逻辑的大部分，以应对未来硬分叉中 Merkle 树索引的潜在更改。这增加了 EIP-7688 专门设计用于消除的复杂性和维护开销。

• Oracles：Relic Protocol 举例说明了使用链上 Beacon 根证明历史共识数据而无需依赖中心化中继器的去中心化 oracle。
• 跨链桥：DendrETH 和 RRC-7755 PoC 等项目展示了如何使用 Beacon Chain 数据来增强跨链消息传递的安全性保证。特别是，如果未采用 EIP-7688，这些协议将面临主要的复杂性开销，在没有稳定 Merkle 索引的情况下保持跨硬分叉的兼容性可能需要脆弱的、特定于分叉的逻辑。
• 预确认：URC 和 BOLT 等举措正在试验依赖于快速、可验证的验证器数据访问的共识感知预确认机制，这是 Merkle 路径稳定性对于长期可维护性至关重要的另一个领域。

虽然我们还观察到在 Ethereum 和 L2 客户端代码库中使用 BEACON_ROOTS，但这些未包括在当前研究中，以将重点放在应用层协议上。

总而言之，这些发现加强了一个明显的趋势：EIP-4788 正在迅速成为各种 Ethereum 原生和跨域系统的基石。EIP-7688 的采用将为这些协议带来关键的稳定性和可预测性，特别是对于跨链桥和预确认系统，即使对 Merkle 路径的微小更改也可能在未来的硬分叉期间引入重大的技术债务或安全风险。

EIP-7688 影响

虽然生态系统级别的概述表明 EIP-4788 已经深深地嵌入到现代协议设计中，但下一个合乎逻辑的问题是支持 EIP-7688 需要什么，以及如果延迟会发生什么。

影响超出了概念上的好处。如果没有 EIP-7688，每次修改 Beacon State 结构的硬分叉都将迫使下游协议更新其 Merkle 证明逻辑。这包括重做字段索引、调整 SSZ 反序列化代码，并确保与分叉前和分叉后的 Beacon 根的兼容性。这些更新中的每一个都需要耗时的开发、仔细的审计和协调的重新部署。

EIP-7688 提供了一种摆脱这种循环的方法。通过引入通过 StableContainer 实现的稳定 Merkle 索引，它建立了一个协议可以跨分叉依赖的长期接口。在下一节中，我们将探讨采用此 EIP 所需的条件，包括客户端更改和 prover 调整，以及如果采用推迟到未来的硬分叉，开发者将面临的额外负担。

Staking

Staking 和 restaking 协议主动使用以下模式来监视执行层中的某些共识层事件：

1. 用户向协议提交有关特定事件（例如，slashing、验证器提款）或特征（例如，验证器余额）的信息，该信息必须出现在 Beacon Chain 块中。相应的 Merkle 证明用作用户调用中的参数。
2. 协议查询 BEACON_ROOTS 预编译以获取该树的根并验证该证明。如果证明正确，则该信息具有链上效果。

包含 Merkle 树中相关信息的叶节点的位置取决于硬分叉版本。BeaconState 对象中存在的字段越多，Merkle 树就越高。这意味着包含正在验证的数据的叶位于离根更远的位置。对于 Deneb 分叉，BeaconState 子树的高度为 5，而在 Pectra 中，高度已经为 6。

在 Lido 的 CSVerifier 中，在确定 Merkle 树索引时，会在提交证明的插槽和 PIVOT_SLOT（新硬分叉的第一个插槽）之间进行比较（1、2 和 3）。PIVOT_SLOT 和相应的索引是不可变的值。这意味着对于每个硬分叉，都必须部署具有更新参数的新版本的 CSVerifier。此外，部署和切换到新版本必须在硬分叉发生之前进行。

在 EigenLayer 的 EigenPod 中，情况类似。根据与证明对应的时间戳，会选择证明版本。然后，基于该版本，选择BeaconState根的高度，该高度用于计算相关字段的索引。

由于这些值在代码中是硬编码的，因此 EigenLayer 中过渡到新的硬分叉稍微复杂一些。这意味着，为了维持协议安全性，EigenLayer 会因审核每个新版本的代码而产生额外成本。

采用 EIP-7688 将允许此类协议仅更新一次代码，并避免将来在这些重复更改上花费资源。

Oracles

Ethereum 生态系统中的一些 oracle 系统利用通过 BEACON_ROOTS 预编译访问的 Beacon Chain 数据来实现信任最小化的验证机制。Relic Protocol，例如，遵循这种方法来验证链上的历史共识数据。虽然这种设计成功地消除了对中心化中继器的需求，但它提出了关于 oracle 系统如何与 BeaconState 结构交互的重要考虑因素。

Relic Protocol 的验证系统由几个模块组成，这些模块处理来自 Beacon Chain 的 SSZ (SimpleSerialize) 数据。这些模块使用 BeaconState 中的特定 Merkle 树索引，例如 STATE_ROOT_INDEX (3)、BLOCK_ROOTS_INDEX (5) 和 HISTORICAL_SUMMARIES_INDEX (27)。verifyHistoricalBlockSummary 和 verifyRelativeBlockRoot 之类的函数依赖于这些固定索引。当 BeaconState 结构在硬分叉中发生更改时，这些索引会发生变化，从而破坏现有的 oracle 合约。

如果没有 EIP-7688，每个硬分叉都需要更新所有索引常量、修改验证逻辑、部署新合约以及与客户端和中继器协调。这会产生运营开销并引入风险。例如，如果 HISTORICAL_SUMMARIES_INDEX 发生更改，则必须重写历史数据的整个验证逻辑，这可能会引入漏洞。

EIP-7688 引入了 StableContainer 的概念，该概念将为 oracle 系统提供稳定的 Merkle 树索引。这可以为现有证明提供向后兼容性，简化验证逻辑，并在 Beacon Chain 更新期间降低风险。Merkle 索引的稳定性对于必须提供对共识数据的可靠访问而无需依赖中心化中继器的去中心化 oracle 尤其重要。

问题不仅仅是更新索引常量。每个修改 BeaconState 结构的硬分叉都需要对验证逻辑进行全面更新，这可能涉及：

• 更新处理 Merkle 证明的链上验证器合约
• 修改生成和提交证明的链下中继器
• 协调系统多个组件之间的部署

如果要实施 EIP-7688，则需要对现有 SSZ 代码进行以下更改：

• 创建 StableContainer 类型：有必要为验证中使用的所有 BeaconState 数据结构定义 StableContainer 类型，而不是依赖于硬编码的索引。
• 定义当前分叉的 Profile：对于每个 StableContainer 类型，都需要创建一个相应的 Profile 以用于当前分叉。
• 更新验证函数：需要更新验证函数才能使用 StableContainer 类型而不是硬编码的索引。

虽然这些更改需要付出巨大的努力，但它们可以消除在每次硬分叉期间更新代码的需要，并降低出错的风险，特别是对于严重依赖 Merkle 树索引稳定性的协议而言。

ZK Oracles

如果 Ethereum 继续不采用 EIP-7688，则依赖于共识层数据（例如验证器余额、退出 epoch 和提款凭据）的 ZK oracle 实现必须不断适应 BeaconState 中的结构性变化。像 Succinct 的 plonky2x 这样的库，它基于 SSZ Merkle 路径生成电路和证明，需要不断更新通用索引 (gindex) 和路径计算。例如，Succinct 的 beacon module 中的实现需要在每次分叉后进行手动调整，从而改变了 like 等定义：

/// blockRoot -> validatorsRoot 的 gindex。
const VALIDATORS_ROOT_GINDEX: u64 = 363;

/// blockRoot -> stateRoot 的 gindex。
const STATE_ROOT_GINDEX: u64 = 11;

/// blockRoot -> balancesRoot 的 gindex。
const BALANCES_ROOT_GINDEX: u64 = 364;

同样，Succinct 的 ZK Oracle 电路和验证逻辑必须经常重新编译和重新部署，以处理底层 BeaconState 数据中的结构性变化。

这是一个在 plonky2x 库中更新通用索引的示例 - https://github.com/succinctlabs/succinctx/pull/199/files。

一旦采用 EIP-7688，StableContainer 方法将为 Ethereum 共识数据引入永久结构。对于使用 Succinct 的 plonky2x 库构建的 ZK oracle 电路，这意味着该库可以依赖于验证器余额和状态等共识数据元素的固定索引。通过更新 plonky2x 实现以引用这些稳定的位置，电路将变得不可变，并且不需要将来的更改。

然而，ZK oracle 本身并没有在其验证逻辑中直接使用这些通用索引。相反，它依赖于证明及其相关的公共输入。由于 EIP-7688 的实施，该电路在 Ethereum 升级中保持有效，因为稳定的布局确保了底层数据源不会发生变化。oracle 只需要确认更新后的电路一次。在初始调整之后，将不需要进一步的更新，从而允许 ZK oracle 保持一致的证明验证过程，而不管未来 Ethereum 协议的更改如何。

基于 Plonky2x 的项目必须保持敏捷，以响应 Ethereum 不断发展的共识机制，尤其是在像 Pectra 硬分叉这样的重大升级期间。需要对依赖于通用索引的电路进行更新，以确保准确的证明生成和验证。未能更新这些电路可能导致无效的证明。因此，开发人员必须密切关注 Ethereum 的开发，并重建其电路以与最新的共识更改保持一致。

结论

从狭义上讲，EIP-7688 并不是一个关键的升级，它没有解决共识安全性、执行层错误或直接的可扩展性问题。但是，它为越来越多的 Ethereum 原生和跨域协议提供了基础改进，这些协议通过 EIP-4788 依赖 Beacon Chain 数据。如本研究所示，staking 和 restaking 协议、oracle 系统以及新兴的跨链和预确认协议已经以假设可靠、一致地访问共识层状态的方式与 BEACON_ROOTS 集成。

如果没有 EIP-7688，每次未来的硬分叉都会通过添加或扩展字段来更改 Beacon State 结构，这将带来重复的负担：协议必须跟踪 BeaconState 的结构性更改、修改 Merkle 证明、调整其代码库，并进行额外的审核，所有这些都在严格的时间表和高协调成本下完成。这会产生随着生态系统采用而扩展的摩擦，并扼杀围绕共识感知应用程序的创新。

EIP-7688 通过引入通过 StableContainer 实现的稳定 Merkle 索引从根本上解决了这个问题。虽然它的实施需要预先进行客户端更改和 provers 的调整，但它在可预测性、安全性和开发效率方面提供的长期价值将不断超过初始成本。

鉴于此，虽然 EIP-7688 并不紧急，但不可否认的是它具有战略意义。将其包含在即将到来的需要在 Beacon State 结构中进行更改的硬分叉中，将最大限度地提高其有效性，减少未来的维护开销，并使协议开发人员能够更早而不是更晚地在稳定的基础上进行构建。值得注意的是，这个 EIP 已经在被几个正在开发共识客户端的团队实施为 PoC。

• 谁是 MixBytes？

MixBytes 是一支由专业的区块链审计师和安全研究人员组成的团队，专门为与 EVM 兼容的以及基于 Substrate 的项目提供全面的智能合约审计和技术咨询服务。在 X 上加入我们，以随时了解最新的行业趋势和见解。

• 原文链接： mixbytes.io/blog/eip-768...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～