EIP-7685：通用执行层请求

介绍

很久以前，没有组成今天我们所知以太坊的两个区块链，没有执行层和共识层平行运行。只有一个单一的基于工作量证明的挖矿链以及EVM。一堆以Geth为多数派的节点客户端，以及许多基于Ethash挖矿算法的GPU和ASIC实现。那时的时代是不同的。

2015年以太坊上线时，通过引入一个全球去中心化的计算机，能够通过智能合约执行任意代码，从而彻底改变了区块链格局。和它的祖父比特币一样，以太坊最初依赖工作量证明共识来保护网络并验证交易。在PoW模型中，矿工竞争解决复杂的数学难题，获胜者赢得提出下一个区块的权利以及相应的区块奖励。

这一共识机制有若干优势，但高能耗、中心化风险和可扩展性限制使得迁移的必要性变得显而易见。没错—以太坊社区早在2014年便开始探索PoW的替代方案！然而，将一个实时的、高价值的网络从PoW迁移到PoS是一个前所未有的挑战。解决方案？一种分阶段的方法，最终以“合并”（The Merge）为高潮。

2020年12月1日，以太坊社区启动了光 beacon 链，更广为人知的是共识层，标志着以太坊新时代的诞生。这条新链引入了几个关键组件：

1. 权益证明共识：验证者可以质押32 ETH以参与区块生产和验证。
2. 基于时期的最终性：Casper FFG（友好最终性小工具）提供了更强的最终性保证。
3. 验证者管理：管理验证者入口、退出和惩罚的系统。

重要的是，光 beacon 链与原始以太坊 PoW 链并行运行，并未处理交易或智能合约交互。其主要目的是在实时环境中建立和测试 PoS 共识机制，并形成足够大的质押，让 PoS 的以太坊从第0天起就能够和 PoW 一样安全。

经过多年的开发和测试，以太坊在2022年9月15日执行了“合并”。这一历史性事件标志着原始以太坊执行层（EL）与光 beacon 链共识层（CL）的融合。合并带来了直接利益，包括能耗的剧减，因去掉了 PoW 挖矿奖励而减少的 ETH 发行，以及为未来的扩展解决方案如 danksharding 打下基础。

虽然合并无疑是一个胜利，但它也引入了以太坊生态系统仍在适应的新架构范式。执行层（处理状态转变和智能合约执行）与共识层（管理验证者和区块生产）之间的职责分离带来了新的挑战和机遇。这种分离改善了模块化，通过更强的最终性保证加强了安全性，并为未来的升级提供了灵活性。然而，它也引入了新的复杂性，尤其是在这两层如何通信和协调方面。

从技术角度看，包括合并的巴黎升级只是简单地将执行区块链的分叉选择委托给共识层，使得执行层完全依赖于其，但并不是完全反过来。具体来说，尽管在共识层启动之前就已存在对共识层的存款，但在合并后，从验证者账户提取 ETH 仍然是不可能的！

智能合约控制的验证者的兴起带来了对执行层和共识层之间更灵活、可编程交互的需求。这就是 EIP-7685 进入的地方。EIP-7685 旨在通过提出一个将请求从执行层传递到共识层的通用框架，以解锁执行层和共识层之间的跨层交互的新可能性。

EIP-7685 规范

EIP-7685 引入了一个将执行层（EL）发起的请求传输和存储到共识层（CL）的通用框架。该提案旨在规范跨层通信，促成两层之间更灵活和可编程的交互。该提案的关键组件如下：

请求格式

requests = request_data_0 ++ request_data_1 ++ ... ++ request_data_n

request_data 将是对请求智能合约进行系统调用的输出。requests 将是从每个请求中返回的每个 request_data_n 的串联。每个请求使用其 request_data 格式定义其 requests 对象。

每个 request_data 表示来自特定智能合约的不同请求列表，前缀为其类型。它们必须按第一个字节（即 request_type）排序。此外，request_data 包含零个或多个编码请求对象，以封锁可能由于包含零而引发的问题。

同一类型内请求的排序应由每个 request_type 定义，智能合约有责任进行选择。

在处理区块时，系统将产生多个不同 request_type 的请求对象，并累积到区块请求列表中。

例如，请求将通过其伪类型进行验证，该类型由智能合约选择。这种方法使得框架独立于特定请求类型编码和验证规则，因为这些规则由智能合约定义，从而允许实现上的灵活性。

例如，0x00 的请求类型将根据特定于该类型的逻辑进行验证。这种方法使得框架独立于特定请求类型的编码和验证规则，从而允许实现上的灵活性。

单字节标识符允许最多 256 个请求类型，这在未来一段时间内可能是足够的。如果必要，未来版本可以用 LEB128 替换单字节标识符来进一步扩展这一限制。

LEB128（varint）整数编码。我从网上偷的这张图片。

然后这些请求将由 CL 读取，并在正确时执行。这些请求是原子和同步的，这意味着它们按照提交的顺序处理。这与今天的验证者存款逻辑不同，在当前情况下，实际的存款只有在该存款的默克尔证明在 CL 上被揭示时才会被确认，并且可能不会按照实际执行的顺序被揭示。

区块请求编码

为了简化引擎 API，区块请求不会直接存储在区块体内。

EL验证 requestsHash 作为 blockHash 验证的一部分。因此，无需将 requests_hash 保持在 beacon 块内。共识层仍然可以通过实现 EL 用于计算 requestsHash 的算法进行 blockHash 验证。这一过程使得 EL 在 EL 区块头中对请求的 requestsHash 验证来自交易执行所获得的请求。

将其存储在头部作为承诺只是将执行头扩展为一个存储请求信息的单一字段。随后，请求逐一暴露给共识层，由其处理。

请求哈希计算

def compute_requests_hash(block_requests: Sequence[bytes]): 
    m = sha256() 
    for r in block_requests: 
        if len(r) > 1: 
            m.update(sha256(r).digest())

由于与请求相关的证明将基于 CL 区块制作，因此没有必要为其创建另一种存储方法（如默克尔树）。共识层可以原生访问请求。EL 区块体存储未经验证的请求，并且将永远不会用于证明。

我们有一个 32 字节值作为头部扩展的 requests_hash。每个提案可以选择如何扩展 beacon 链类型以包含新的 EL 请求类型。

作为新块的 EL 验证的一部分，EL 必须检查参数 executionRequestsHash 是否与该块的承诺匹配（block.header.requests_hash）。

另外，作为 beacon 块验证的一部分，共识层必须计算 beacon 块正文中的请求哈希，并将计算出的哈希传递给 EL，以便在调用引擎时合并到 block_hash 验证过程参数中。

执行哈希计算

requests_hash = sha256(sha256(0x00 || request_data_00) || sha256(0x01 || request_data_01) || ...)

由于 EL 不需要处理 request_data 或解码它，我们可以让智能合约决定使用哪种编码。对于现有请求，它们将使用 SSZ，因为请求是由共识层消费的。

以 0x00 || request_data_00 的形式表示每个请求的想法是避免发送回整个执行请求对象，EL 对此不关心。此外，每个请求必须被验证。

谁生成请求？

这是一个非常有趣的部分。正如我之前提到的，EIP-7685 是一个通用框架。换句话说，它不指定任何具体的操作，比如存款、取款等。它只是创建了一堆结构和逻辑，以一种不会给以太坊代码库带来过度复杂化的方式高效处理这些请求。或者，更简单地说，它为其他 EIP 创建新类型的请求提供了一个便捷的接口。

让我们看看两个最流行的基于 EIP-7685 的 EIP——存款请求 (EIP-6110) 和取款请求 (EIP-7002)。顾名思义，它们允许从执行层发起存款和取款。你甚至可能会在页面开头看到“需要：EIP-7685”这一行。然而，它们并不总是使用请求标准。此外，从它们的编号可以看出，它们甚至是在 EIP-7685 之前创建的！

EIP-6110上的存款是一种 EIP-7685 请求，格式如下：

request_type = DEPOSIT_REQUEST_TYPE
request_data = get_deposit_request_data(block.receipts)

因此，EIP-6110 只具有存款的逻辑，而不是每个请求的复杂性。并且…… EIP-7002，实施 execution layer 可触发的提款，具有完全相同的逻辑，但在不同的字段中。

EIP-7002上的提款也是一种 EIP-7685 请求，格式如下：

withdrawal_type = WITHDRAWAL_REQUEST_TYPE
request_data = read_withdrawal_requests()

因此，与其将每个存款和取款请求解释到它们的理解水平，我们可以使用 EIP-7685 实现共识层（CL）和执行层（EL）之间的互操作通信。现在，想象我们还想在 EIP-7251 的一部分中实施验证者聚合逻辑、提款凭证重新配置，或者我们从 EL 针对我们的应用程序触发的任何内容。以太坊区块的结构将变得过于庞大和不必要的复杂。

EIP-7685 提出了一种普遍和全面的方法。所有由 EL 触发的请求可以由 EL 原生访问，同时在区块头中作为承诺进行引用。所有请求由 CL 逐步读取和执行。我们可以在单个接口下实现多达 256（或者，如果我们愿意在未来将类型字节替换为 Base-128，可以更多）的请求类型，以考虑向前兼容性。

现在，让我们看看这两个最流行的基于 EIP-7685 的提案如何利用请求。

EIP-6110

EIP-6110 硬编码 0x00000000219ab540356cbb839cbe05303d7705fa（最受欢迎的质押存款合约）为唯一的官方质押存款合约，而不是允许来自任何智能合约的具有指定存款合约代码哈希的存款。

该官方存款合约的代码兼容 EIP-7685 标准，并使用 DEPOSIT_REQUEST_TYPE（通过智能合约获取）处理存款所需的所有信息。

来自该合约典型交易的示例

对于由该智能合约发出的每个日志，都通过智能合约启动一个“存款请求”，其提供的类型为 DEPOSIT_REQUEST_TYPE。它们按照日志的顺序启动，且因为所有请求在共识层上是同步处理的，所有存款变得同步、原子和原生。此外，缺乏异步存款验证允许取消目前大约需要12小时的验证者轮询，因此在 CL 上处理存款的唯一延迟是时期最终性，或者大约13分钟。

EIP-7002

目前，以太坊验证者基本上由两把密钥操作——活动 BLS 密钥，用于认证区块、提案和执行其他验证者职能，以及提款凭证，即 EL 地址——提取 ETH 所在的地方。活动密钥无法更改取款凭证，因此一旦设置，验证者“拥有”的 ETH 实际上由持有该地址提款密钥的人拥有。

这种关系在我们希望将提供资本用于质押的人与执行验证者职责所需质押进行分离时意义重大。也就是说，质押池、质押即服务，或者归根结底，愿意管理你验证者的朋友，因为你一直在旅行。然而，实际的取款无法由提款地址发起，只能由活动密钥发起。这可能导致安全风险。例如，持有提款密钥的人可能会用质押的 ETH 作为人质，比如以换取较大的质押份额。或者一旦遗失活动密钥，管理的质押也将丢失。

EIP-7002 建议通过实施一种在提款地址发起的提款请求，类型为 0x01 来改变这一点。为创建该请求，提款地址调用 0x00A3ca265EBcb825B45F985A16CEFB49958cE017 智能合约，并提供验证者公钥及请求的提款金额。智能合约计算费用（用于限制提款频率）并排队待取款。在区块结束时，系统地址发起对收集排队取款的智能合约的调用，并将其传输到 CL 并进入链下。

这种逻辑特别对去中心化质押池有用，目前其依靠验证者不会将其质押扣为人质并正确执行池请求的所有取款的假设。在此升级之后，操作池的智能合约将在验证者不当行为或性能不佳的情况下，能够自己提取质押。

未来的 EIP 使用 EIP-7685 请求可能会实现创建实际请求的其他逻辑。我猜想我们可能会看到旨在使后 7251 聚合比许多提款 -> 存款操作更加便利的验证者聚合请求 EIP，等等。某些人可能实现直接在 EVM 中创建请求，某些人则更倾向于 7002 的系统调用方法，等等。这取决于 EIP 的创造者。EIP-7685 提出的就是建立一种便捷、精简的接口，以构建 CL-EL 互操作性解决方案，不给以太坊代码库带来不必要的复杂性，并遵循 路线图中的 The Purge 线。

EIP-7685 能够实现什么？

让我们看看两个最受欢迎的去中心化质押协议——Lido 和 Rocket Pool，并推测它们的架构如何使用 EIP-7685 进行升级。

Lido：现状

Lido已在以太坊网络上建立了一个良好的去中心化流动质押协议。该协议的设计旨在平衡去中心化与高效的质押管理，允许用户参与以太坊质押，而无需进行直接的验证者操作。它支持多个质押模块，但第一种且迄今为止最受欢迎的是一个策划模块，我们将进行介绍。

Lido 操作的核心是Lido去中心化自治组织（DAO），它在协议的治理和运营决策中起着关键作用。DAO的主要责任之一是选择和管理专业的节点运营商。将用户存入的ETH捐赠以回报运营商负责运行验证者节点用户存入 ETH，以换取 Lido 的流动质押代币 stETH，代表所质押的 ETH 及应得的奖励。

截至本文撰写时，Lido CM 由39个节点操作员管理。该团体中包括以太坊生态系统中多个知名实体，例如 Everstake、Nethermind 和 Figment。著名和有声望的运营商的加入为 Lido 的运作增添了一层信任和专业性，从而增强了该协议在整个以太坊社区中的信誉。

在 Lido 当前实现中的取款过程是在链上发起的。当系统确定取款是必要时，比如由于用户希望撤消他们的 ETH 质押，它通过链上机制表达这种意图。节点运营商被期望使用其验证者密钥快速执行这些取款意图，因为他们受协议的“验证者退出政策”的约束。

然而，需要注意的是，这些取款并没有通过链上机制强制执行。这个限制源于目前无法直接从执行层（EL）智能合约启动共识层（CL）操作。因此，系统在很大程度上依赖于节点运营商的合作和遵守及时处理取款。

对于发生取款意图的运营商不配合的情况，Lido 实施了一种治理机制来解决此类情况。DAO 有权对不合规运营商进行投票，决定将其从系统中移除。如果这样的投票通过，相关运营商将被禁止接收新存款，有效地限制了他们在协议中的角色。然而，这一机制也有其局限性。即便运营商被移除，该系统在运营商自愿启动取款或面临共识层的惩罚之前，无法强制性地回收该运营商现存的资金。

Lido 的智能合约通过一个预言机系统接收验证者余额、取款及其违规行为的信息。选举出九名运营商，分享 CL 状态的数据给 EL 上的智能合约。在 5/9 阈值达到后，智能合约才会认为数据有效。因此，系统依赖 5/9 的可信运营商。在他们恶意行为的情况下，DAO 可以覆盖预言机的输出并重新选举运营商。然而，这样的操作需要社区的广泛协调，并且如果发生一次成功的攻击，可能会导致成功。

除了取款外，缺乏可编程的存款规则引入了一种脆弱性，允许节点运营商使用1 ETH存款及不同于Lido指定的提款凭证的地址进行前置操作。Lido 通过引入“存款安全委员会”防止这一操作，其成员被授权在发现存在前置尝试时批准或否决存款。这是因为目前对 CL 的存款是由 CL 而不是由 EL 处理，使其为异步，从而容许了前置。

尽管 Lido 的当前实现创新而且在很大程度上成功，但面临着许多源于以太坊架构限制的挑战。这些挑战包括对节点操作商遵守取款请求的依赖、预言机体系的潜在脆弱性以及存款过程需要更多的安全措施。然而，EIP-7685 和相关提案的引入有可能解决许多问题，为 Lido 的更高效和去中心化的实现铺平道路。

Lido：后7685

EIP-7685 及相关以太坊改进提案的提出，具有显著改善 Lido 的架构和操作的潜力。这些变化可能解决许多当前的局限性和脆弱性，导致协议变得更加稳健、高效和去中心化。

EIP-7685 可以为 Lido 在取款请求领域带来的最显著改善之一是。EIP-7002，由 EIP-7685 提动，则能够直接从验证者指定的凭证启动提款。这种能力将使 Lido 的智能合约能够自动化处理提取 ETH 质押的过程，实际上消除了目前对节点运营商这一关键职能的依赖。

这一改变的影响是深远的。目前，Lido 的取款流程可能需要长达24小时，因为它依赖于节点运营商遵循协议政策来执行取款意向。通过实施 EIP-7685，这些取款可能会近乎即时执行。这种取款时间的剧减将显著增强 stETH 的流动性，即 Lido 的流动质押代币，有可能改善其在二级市场与 ETH 的平价。

此外，取款自动化解决了 Lido 当前模型中关键的信任假设。通过消除对运营商干预取款过程的需求，该协议减少了运营商未能遵守取款请求的风险，无论是由于疏忽还是恶意。这一变化与 Lido 的目标完全相符，即增强去中心化并降低对受信任方的依赖。

EIP-7685 和相关提案还将在存款流程中带来实质性改善。由 EIP-7685 促成的 EIP-6110 引入了以太坊的同步存款逻辑。这一变化对 Lido 的操作具有重要意义，特别是在存款安全方面。

在当前异步存款模型中，有前置 Lido 存款的风险。攻击者可以在 Lido 存款之前提交一个具有不同提款凭证的 1 ETH 存款，从而有效地劫持池的资金。为防止这种情况，Lido 当前依靠其存款安全委员会来否决和批准存款。

随着同步存款的引入，这一攻击向量将被有效消除。存款将按提交顺序处理，使得攻击者无法在 Lido 存款之前抢先。这一变化将可能使得存款安全委员会成为多余，从而从 Lido 的架构中消除一个中心化组件，更进一步地与其去中心化目标对齐。

另一个 Lido 当前实现中另一个关键组件的预言机系统，更有可能随着 EIP-7685 的引入而显著改善。该框架为利用请求从执行层提取预言机信息开辟了新可能。这一能力有可能大幅减少甚至消除对当前中心化预言机系统的需求。

EIP-7685 还可以带来与验证者管理相关的重大改进，特别是考虑到已提出的 EIP-7251。该提案预计将在下一个 Pectra 升级中连同 EIP-7685 一并实施，旨在将每个验证者实体的最大有效质押增加到 2048 ETH。这一变化旨在将大型质押池运营的验证者密钥的数量减少最多 64 倍，显著减轻以太坊网络的负担，也可能为以太坊共识机制的单槽最终性等改进铺平道路。

然而，迁移到后7251验证者对于像Lido这样的大型质押池来说提出了重大挑战。在本文撰写时，其大约306,000个活跃验证者意味着Lido面临着将这些验证者整合以使其与新的最大质押限额对齐的巨大任务。在当前以太坊限制下，每个时期有8个存款和取款的变动限制，这一整合过程可能需要长达 190 天。这一漫长的过程将对 Lido 的运营效率产生重大影响，并可能使该协议失去进行整合的动力。

在这里，EIP-7685 的能力证明是无价的。该提案可能启用专门为验证者整合设计的新请求类型。这种整合请求将允许在没有当前取款和随后的存款过程造成的延迟的情况下，自动和同步地合并验证者。

这种整合请求的引入将极大简化Lido适应EIP-7251 提出的新的验证者质押限额的过程。取而代之的是需要数月的取款和存款流程，Lido 可能能够更快、更高效地整合其验证者。这不仅将方便 Lido 向新的验证者质押限额的过渡，还将使其更快地实现运营更少更大验证者的优势，例如减少运营复杂性。

值得注意的是，尽管由 EIP-7685 启用的整合请求可能主要在实施 EIP-7251 后的过渡期内有用，但将其纳入以太坊协议也可能在未来的升级中证明有价值。如果，将来验证者的最大有效余额（MaxEB）再度增加，拥有高效验证者整合的固定机制将极大简化大型质押池的过渡过程。

通过支持自动取款，Lido 可以显著增强其质押操作的流动性和效率。引入同步存款将消除对中心化存款安全措施的需要，更加紧密地与其去中心化目标对齐。对预言机系统的改进可能减少对受信方在关键状态信息方面的依赖。最后，高效整合验证者的能力将使 Lido 能够更轻松地适应以太坊验证者规范的变化，确保该协议在不断变化的以太坊质押生态系统中保持效率和竞争力。

Rocket Pool：现状

Rocket Pool已在去中心化以太坊质押协议领域确立了先锋地位。该协议的主要目标是通过显著降低个人质押者的准入门槛，使参与以太坊的权益证明共识机制民主化。同时，Rocket Pool 旨在为在生态中日益普遍的中心化质押服务提供更去中心化的替代方案。

Rocket Pool 创新的核心是其独特的节点操作方法。该协议允许个人以仅需 8 ETH 成为节点运营商，这大大低于标准的 32 ETH 要求。通过该协议，剩余的 24 ETH 由来自用户存款的池提供。这一机制不仅降低了节点运营商的准入门槛，还在节点运营商和 ETH 存款者之间创造了一个共生的关系，从而使他们在协议成功上的利益趋于一致。

对于那些不想自己运行节点的用户，Rocket Pool 提供了无缝的质押体验。这些用户可以存入任意数量的 ETH（最低 0.01 ETH），并获得 rETH 作为回报。rETH 是 Rocket Pool 的流动质押代币，代表用户质押的 ETH 以及任何应得的奖励。该流动质押代币使用户在参与以太坊质押的同时保持流动性，因为 rETH 可以在各种 DeFi 应用中交易或使用。

为了确保质押数据的准确性和可靠性，Rocket Pool 采用了去中心化的预言机网络。与一些使用受权预言机的质押协议不同，Rocket Pool 的预言机节点在无权限的基础上运行。任何人都可以通过质押一定数量的 RPL（Rocket Pool 的原生治理代币）来运行一个预言机节点。这种预言机操作方法与 Rocket Pool 的去中心化承诺保持一致，因为这消除了对报告质押奖励和其他协议操作这一关键功能的任何中央权威。

该协议利用这些预言机节点的数据来管理多个重要功能。首要任务是，当多数预言机报告有效数据后，准确地重新分配参与者之间的质押奖励。此外，这些数据在识别和惩罚网络中的不当行为方面起着至关重要的作用。通过利用去中心化的预言机网络，Rocket Pool 旨在确保这些关键功能以透明和无需信任的方式执行。

然而，和当前以太坊生态中的许多质押协议一样，Rocket Pool 在管理验证者退出和取款时面临一些限制。在当前的实现中，Rocket Pool无法自动化从验证者那里的质押提取。相反，该协议依赖节点运营商自愿退出或因验证者不当行为而由以太坊网络触发的镌刻事件。

为了减轻这种对自愿退出的依赖所带来的风险，Rocket Pool 实施了一种 RPL 债券系统。节点运营商需要抵押 RPL 作为担保，这为协议及其用户提供了一种保险。在镌刻或其他惩罚事件发生时，这些 RPL 债券可以用于覆盖损失。目前，RPL 债券设计为可覆盖验证者不当行为造成的大约 10% 的损失。

这一抵押机制为该协议提供了一层安全保障，特别是在镌刻情况下。正常情况下，最大镌刻金额为 1 ETH，而典型的 RPL 债券则约为 2.4 ETH。这种超额抵押确保协议及其用户受到一定程度上对常见镌刻事件的保护。

然而，需注意的是，这一债券机制也有其局限性。虽然在应对镌刻事件方面提供了稳固的保护，但在节点运营商可能试图通过未启动取款来保留全部质押的情况下，仅提供有限的覆盖。在这样的极端情况下，RPL 债券仅能覆盖大约 10% 的全部质押风险。

Rocket Pool：后7685

EIP-7685 的提出及相关以太坊改进提案的实施，具有显著提升 Rocket Pool 的架构和操作的潜力。这些变化可以解决当前的多个局限性，并进一步增强该协议对去中心化和安全性的承诺。

目前，Rocket Pool与 Lido 以及其他所有质押协议一样，无法强制其验证者诚实取款。该协议建立在验证者提供的 RPL 债券作为潜在损失的抵押这一假设之上。虽然该系统在抵御镌刻事件上提供了合理的保护，但在面对更极端的情况时面临局限。

如我们之前计算的那样，在当前模型下，如果一个节点运营商试图通过从未提取质押来攻击该池，RPL 债券最多也只会覆盖全部验证者质押的 10%。这一场景虽然不太可能，但在理论上代表了系统的潜在脆弱性，可能被恶意行为者利用。

EIP-7685 的实施可能根本改变这一动态。借助该提案所引入的新能力，Rocket Pool 的智能合约将具备自主发起提取的能力，而无须依赖节点运营商的合作。此项更改将有效消除节点运营商控制质押或拒绝处理取款的风险。

此外，该变更还可能允许 Rocket Pool 重新审视其抵押要求。当前，该协议要求节点运营商提供大量 RPL 债券作为安全措施。这些债券用作防范潜在不当行为的保险，包括未能处理取款。然而，通过自动化处理智能合约的取款能力，节点操作的风险概况将显著变化。

考虑到这些变更，Rocket Pool 的去中心化自治组织（DAO）的可能会考虑降低对节点运营商的最小质押要求。当前对 8 ETH 加上可观 RPL 债券（其价值一般约为 2.4 ETH）的要求，将可能降低至低至 1 ETH - 涉及可能的镌刻罚款所需的最低金额。

这种最小资金额的降低将对协议的可访问性和去中心化产生深远影响。通过降低节点运营商的资本要求，Rocket Pool 可以吸引更多样化的参与者来运行节点。这一增加的可访问性可能导致树立一个更加去中心化和稳健的运营商网络，进一步增强协议的韧性和去中心化。

降低节点运营商的进入门槛的潜力与 Rocket Pool 实现 Ethereum 质押民主化的使命完全一致。正如该协议使拥有仅0.01 ETH的用户能够参与质押一样，这些变化也可能使得节点运作变得更可及给更广泛的参与者。这可能会导致 Rocket Pool 生态系统中独立节点运营商数量的显著增加，从而增强协议的去中心化，可能增加其在整体以太坊质押市场的份额。

概念：ZK 质押池

于2024年3月发生的Dencun升级包含了EIP-4788。它启用了一个存储官方共识层的区块根的EVM智能合约。共识层中的区块根是默克尔根。这意味着可以创建一个默克尔证明，证明某些数据存在于某个区块中，而无需暴露所有其他数据。具体而言，区块根“包含”有关证明、镌刻、提议等的信息。

我们可以利用这一点，以自动获取有关验证者在我们想象的去中心化质押池中的效率的信息。让我们做一些简单的估算。为了做到这一点，我们需要从区块根揭示状态根（(~2000 gas)） 并执行对 CL 状态根的默克尔证明验证，以获取验证者的账户 (2log2 1_000_000 = 40; 40(60+12(64/32))+ 4032*16 = ~23840 gas)。在 ETH 价格为 $3000 、气体价格为 10 gwei 的情况下，这大约是 $0.78。我们需要在每个我们希望更新池状态的周期内执行这个操作，理想情况下是每个区块。考虑到每个验证者在每次认证中获得大约 $0.02-0.05 的收益，这将变得不可行。

然而，这还没有结束。我们可以使用零知识证明来对整个 CL 状态数据集执行离线可验证的计算，以查找余额和有关所有验证者的其他有用信息，无论他们有多少，凭借一个证明，甚至更少。一般来说，我希望你，读者，至少对 ZK 证明有个基本的了解，否则你可能不会深入到如此复杂的 EIP 中去探索。然而，让我们对此做个快速回顾：

想象你试图在不显露整个拼图的情况下证明关于一个巨大的拼图的信息。使用传统方法时，拼图越大，验证所需的时间和难度就会越高。然而，零知识证明允许你证明方面关于整个拼图的特性，同时只显示一小块特定大小的证据。在处理大量数据的系统（如区块链或大型数据库）中，这一特性非常实用。

ZK 合作处理，实际上是我们将在这里利用的技术，就类似于具有专门帮助者能够快速有效地执行复杂计算。在我们的日常计算机中，我们有显卡非常擅长于处理视觉任务，即与主CPU分开。同样，在某些使用零知识证明的系统中，某些任务可以借助这些协处理器进行卸载，而不会导致系统的主要部分过载。

由于执行层可以访问这些根，因此能够生成验证者的证明和镌刻的 ZK 证明并使用这些根进行验证。我们可以利用这个高效地计算某些验证者的效率，并检测他们是否受到惩罚。如我所述——可以验证 CL 数据的默克尔证明而不需 ZK，但在我们的规模和要求频率下，这样在以太坊 L1 上将花费过多的 gas，而在使用零知识证明的情况下则没有这种问题。接着，我们在智能合约中积累 ETH，将其分配给专业的债务节点，实现去中心化质押池。

现代 ZK 证明系统，如 Plonky3 允许对大量数据进行快速的大规模计算。通过利用这些系统，我们可以显著降低链上成本，从而使对验证者信息的完全链上处理成为可能。此外，我们可以采用证明聚合系统，将 ZK 证明聚合成单个易于验证的证明，例如 Nebra UPA，这将进一步降低成本，可能降低到我们之前提到的无 ZK 的每个验证者的 gas 成本的价格。然而，即使我们完全消除了对预言机的需求，我们仍然必须信任这些操作人员能够正确处理提款。这就是 EIP-7685 登场的地方。通过利用请求，我们可以从同样的智能合约中管理操作人员的验证者，同时将他们的信息转储到其中。如果某个验证者的效率较低或被削减，则撤回他们的资金，并根据 CL 数据计算他们的罚款，无需预言机或信任点。

我们可以通过使用分布式密钥生成（DKG）将验证者实体分配给多个操作人员来进一步改进。这种方式可以最小化验证者的停机时间和效率问题，让池子的质押者获得最大可能的收益，而无需担心失去资金给不诚实的参与者。节点操作员则可以以少至 0.1 ETH 甚至更少的资金管理验证者。与多个操作员一起运行验证者实体的做法并不新鲜。这被称为去中心化验证者技术（DVT），项目如 Obol 和 SSV 已经在推出他们的 DVT 解决方案。

总而言之，EIP-7685 是完全去中心化和无信任质押协议的最后一块拼图，在其完美状态下，可能允许人们以小额质押和完美的效率运行自己的验证者节点。

挑战与考虑

请求处理

主要挑战之一在于请求处理的领域，这源于执行层（EL）和共识层（CL）之间的根本性差异。这两层构成了以太坊当前架构的骨架，是在不同的时段和具有不同设计理念的情况下开发的。

例如，执行层从以太坊的原始架构演变而来，使用 Keccak256 作为其主要哈希函数，并使用递归长度前缀（RLP）编码进行数据序列化。相比之下，共识层使用 SHA256 进行哈希，使用简单序列化（SSZ）进行数据编码。这些差异为两层之间的无缝通信带来了重大挑战。设计选择的差异反映了区块链架构不断发展的认识以及每层的特定要求。执行层专注于智能合约的执行和状态管理，受益于 Keccak256 和 RLP 的效率。共识层则优先处理快速区块和高效的轻客户端证明，利用 SHA256 和 SSZ 的优势，依此类推。

有效且向前兼容地桥接这两个世界，一直是以太坊开发中的一个持续挑战。EIP-7685 的提出，就是为了在这一复杂领域中建立一个通用的跨层请求框架。挑战不仅在于使这些不同系统之间的通信成为可能，而且要在保持两个层的优势和安全属性的同时进行。

然而，EIP-7685 的设计者对这些挑战十分关注。该提案旨在创建一个灵活的框架，能够适应层之间的差异。例如，它允许对不同请求类型使用不同的序列化格式，从而在适当的时候可能启用 SSZ 和其他编码来处理请求数据。

向后兼容性

EIP-7685 实施中的另一个重要考虑是向后兼容性。虽然以太坊的升级过程通常依赖硬分叉，这允许对协议进行重大更改，但这些更改对现有基础设施和应用的影响不能被忽视。

例如，去中心化质押池围绕以太坊当前跨层通信的局限性构建了复杂的系统。它们依赖于像预言机网络、绑定节点操作员和复杂治理系统这样的机制来管理执行层和共识层之间的差距。EIP-7685 及其派生版本的引入，可能使很多这些系统变得过时或低效。

为了让去中心化质押池充分利用 EIP-7685 提供的能力，它可能需要对其核心架构进行重大 redesign。这可能涉及重写智能合约、重新设计治理机制以及重新考虑经济模型。这些变更需要大量的开发工作、严格的审核和细致的测试，以确保它们不会引入新的漏洞或低效。

向新架构转换以利用 EIP-7685 的能力可能并非简单。这些协议中的许多由去中心化自主组织（DAOs）治理，这些组织可能对批准在经过验证的系统上进行激进变更持谨慎态度。许多 DAOs 的保守性质，虽然通常有利于协议安全，但可能会减缓 EIP-7685 引入的新能力的采用。

EIP-6110

在 EIP-7685 的基础上还有特定的挑战，例如 EIP-6110 中描述的存款请求的实施。正如我们之前提到的，该提案旨在改变存款到共识层的处理方式。然而，其当前规范对向后兼容性和生态系统的影响提出了一些潜在问题。

EIP-6110 提议为处理存款指定一个单一的、规范的智能合约地址，而不是允许来自任何合约部署的存款（现在的规范是允许的，合约代码是规范存款合约代码）。虽然这种方法极大简化了提案的实施，但可能对围绕替代存款合约构建系统的项目产生意想不到的后果。

如果旧的基于 Merkle 证明的存款机制在实施存款请求后被废弃，使用非标准存款合约的项目可能会面临困难。它们需要重写其代码库，以使用新的规范存款合约，或者面临资金损失的风险，因为它们当前的存款机制将不再有效。

一种潜在的缓解策略是在新请求系统的基础上保持旧的存款逻辑并行运行，至少在过渡期间。这将为项目适应新系统提供时间，同时确保现有应用继续正常运行。然而，维护双重系统带来了自身的挑战，包括增加协议复杂性以及用户和开发者可能产生的混淆。

结论

EIP-7685 在以太坊架构的发展中代表了一个重要的进步，特别是在连接执行层和共识层之间的差距方面。通过引入一个通用的跨层请求框架，这一提案有可能彻底改变去中心化质押协议的运作方式，提高它们的效率、安全性和无信任性。

然而，EIP-7685 的实施并不没有挑战。连接执行层和共识层不同架构的技术障碍、确保向后兼容性以及管理现有协议和用户过渡的难题，都是需要重视的重要考虑。这些挑战将需要谨慎的计划、广泛的测试以及社区范围内的合作来克服。

尽管存在这些障碍，EIP-7685 的潜在好处使其成为以太坊一个引人注目的发展。随着生态系统的不断演进，像 EIP-7685 这样的提案在实现以太坊更具可扩展性、安全性和去中心化的区块链平台的愿景中扮演着至关重要的角色。这些倡议的成功将依赖于以太坊社区的持续创新、合作和奉献。

感谢阅读。

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