以太坊 Pectra 升级深度解析：验证者余额扩展、EOA 可编程性与质押流程简化

以太坊从 PoW 向 PoS 的过渡，不是一蹴而就的。整个过程大体是这样的：先在现有执行层之上搭一层信标链，信标链启动 PoS 共识时，执行层继续跑 PoW（这就是 Phase0 和 Altair 阶段）。接着，Bellatrix 硬分叉全面激活了 PoS——虽然当时还不能提款。再后来，Capella 硬分叉打开了提款大门，验证者生命周期终于形成闭环。再到近期的 Deneb 硬分叉（作为 Dencun 升级的一部分），信标链参数又做了微调，比如优化了打包证明的时间窗口、调整了自愿退出和验证者更换的限制条件。而 Dencun 真正的重头戏在执行层——引入 blob 交易、blob gas 和用于 blob 的 KZG 承诺，同时废弃了 SELFDESTRUCT 操作码。

现在，Prague/Electra——也就是 Pectra 硬分叉——给执行层和共识层带来了一次里程碑式的升级。作为 Lido 项目的审计方，我们自然把目光聚焦在共识和质押相关的变化上，但执行层的更新同样不能忽视，因为它们会直接影响以太坊网络的性能以及验证者的运作效率。接下来，我们就深入聊聊这些关键变革。

Pectra 升级概览

Electra 升级给信标层塞进了几项核心功能，主要更新包括：

• 验证者的有效余额范围从固定的 32 ETH，扩展到了 32 到 2048 ETH。

• 验证者可以通过二级“提款”凭证发起退出流程，不再强制要求使用活跃验证者密钥。

• 重构了信标层处理 Eth1 存款的机制，不再依赖解析存款合约事件。

• 建立了一个新的通用框架，用于处理来自常规 Eth1 合约的请求——逻辑类似 Electra 之前的存款管理。

与此同时，Prague 升级也给执行层带来了一系列关键改进：

• 新增支持 BLS12-381 曲线的预编译合约，用于验证 zkSNARK 证据（之前主要支持 BN254 曲线）。

• 引入新的系统合约，用来存储和访问最多 8192 个历史区块哈希——这个对无状态客户端来说很有价值。

• 提高 calldata 的 gas 成本，目的是抑制区块大小膨胀，同时鼓励那些重度依赖 calldata 的项目（比如 Rollup）把数据迁移到 Dencun 引入的 blobs 上。

• 支持每个 Eth1 区块包含更多的 blobs，并提供相应的 API 来读取这些数据。

• 允许 EOA（外部拥有账户）拥有可执行代码，这极大扩展了 EOA 的功能，比如执行 multicall，或者把执行逻辑委托给其他地址。

为了更清楚这些变化，我们整理了相关的以太坊改进提案（EIP），方便对照着看：

• EIP-7251：增加 MAX_EFFECTIVE_BALANCE

• EIP-7002：执行层可触发的退出

• EIP-6110：链上提供验证者存款

• EIP-7549：将委员会索引移出证明

• EIP-7685：通用执行层请求

• EIP-2537：BLS12-381 曲线操作的预编译

• EIP-2935：在状态中保存历史区块哈希

• EIP-7623：增加 calldata 成本

• EIP-7691：增加 blob 吞吐量

• EIP-7840：向 EL 配置文件添加 blob 调度

• EIP-7702：设置 EOA 账户代码

这里面，有些 EIP 主要涉及共识层，有些涉及执行层，还有的则横跨两层——因为存款和提款这些操作需要在两层之间同步。考虑到它们之间紧密的相互依赖关系，把 Electra 和 Prague 分开讨论其实不太现实。下面我们就逐一拆解这些 EIP，同时说清楚它们会影响以太坊的哪些组件。

EIP-7251：增加 MAX_EFFECTIVE_BALANCE

参考: EIP-7251

从 Phase0 硬分叉开始，一直到 Electra 升级之前，验证者的最大有效余额被死死锁在 32 ETH。要激活一个验证者，最少需要 spec.min_activation_balance（32 ETH）。激活后，验证者就从这个最大有效余额起步，但有效余额可以降到 spec.ejection_balance（16 ETH），低于这个阈值就会被踢出网络。这个“最小”逻辑在 Electra 里保留了下来，不过 spec.max_effective_balance 已经被提升到了 2048 ETH。简单说，验证者可以在 32 到 2048 ETH 之间存入资金来激活，所有金额都会计入有效余额。这意味着以太坊从“32 ETH 权益证明”正式迈进了“灵活权益证明”时代。

这个可变的有效余额会用在以下几个方面：

• 提升成为区块提议者的概率——和有效余额成正比。

• 提升成为同步委员会成员的概率——同样与有效余额成正比。

• 作为计算相对削减和不活跃处罚金额的基础。

前两项是验证者收益最高的操作。所以，Electra 之后，大额质押的验证者会更频繁地参与区块提议和同步委员会，频率直接和有效余额挂钩。

当然，削减罚金也和有效余额成正比：

• “即时”和“延迟”的削减罚金，对高额质押的验证者来说会更大。

• 那些与高额质押被削减验证者共同参与的“延迟”削减罚金也会更大，因为总质押中被削减的部分占比变大了。

• 举报有效余额较高的验证者的举报者，能拿到更大比例的被削减质押。

Electra 还调整了削减比例，重新定义了被削减验证者余额里由举报者接收的部分。

关于无效性惩罚：当验证者在活跃期间（比如证明或提议）离线时，无效性分数会累积，导致每个周期都会施加惩罚。这些惩罚也和验证者的有效余额成正比。

有效余额的增加，还影响了验证者的“更换限制”。在 Electra 之前，验证者通常都有相同的 32 ETH 余额，退出限制被定义为“一个周期内，最多不能有 1/65536 的总质押可以退出”，这创造了一个固定的退出数量。而在 Electra 之后，如果少数“鲸鱼”验证者退出，因为它们代表的总质押比例很大，退出速度就会变得非常不一样。

另一个值得注意的点是验证者密钥的轮换。大型验证者之前被迫在一个实例上运行几千个验证者密钥来适应大额质押，把这些质押拆成 32 ETH 的碎片。Electra 之后，这种操作不再是必须的了。从财务角度看，100 个 32 ETH 的验证者和一个 3200 ETH 的验证者，奖励和概率都是线性缩放，没区别。而且，多个活跃验证者密钥可以用同一个 Eth1 取款凭证，把所有奖励提到一个 ETH 地址，还能省掉合并奖励的 gas 成本。不过，管理大量密钥还是会带来额外的运维成本。

聚合验证者余额的能力，还引入了一种新的执行层请求类型：聚合请求。它能把两个验证者合并成一个，操作请求包括源公钥和目标公钥，处理流程跟存款和取款差不多。聚合操作同样受待处理请求队列和余额更换限制的约束。

总结一下：

• 小型独立验证者
  ：Electra 允许自动增加有效余额（以及奖励）。之前超出 32 ETH 的盈余只能提取，现在可以贡献到有效余额里。不过，有效余额只能按 spec.effective_balance_increment（1 ETH）的倍数增加，这意味着要等到下一个“1 ETH 界限”才会更新。

• 大型独立验证者
  ：通过允许把多个活跃验证者密钥整合成一个，管理难度大大降低。运营一个 1x2048 ETH 的质押，比管理 64x32 ETH 的质押简单太多了。

• 流动质押提供者
  ：Electra 在质押分配方案中增加了灵活性，但也意味着那些基于固定 32 ETH 有效余额的会计系统，需要重构了。

还有一个重要话题是验证者历史数据和利润估算。在 Electra 之前，32 ETH 的上限在历史数据里创造了一种均匀性——所有验证者的有效余额、奖励、惩罚和提议频率都一样。这种均匀性有助于以太坊在没有统计异常值的环境下测试共识机制。Electra 之后，质押分布会发生重大变化：大型验证者在提议和同步中的参与度更高，面临的惩罚风险也更大，对激活和退出队列的影响也更强。虽然这会增加数据聚合的难度，但以太坊的共识机制确保了非线性计算被控制在最低程度。唯一的非线性组件是使用 sqrt(total_effective_balance) 来计算基本奖励，这个对所有验证者都适用。所以，验证者的奖励和削减，仍然可以按“每 1 ETH”的基础来估算。

EIP-7002：可触发的执行层退出

参考: EIP-7002

以太坊里的每个验证者都有两对密钥：活跃密钥和取款密钥。活跃 BLS 密钥是验证者在信标链中的主要身份，用来签署区块、证明、削减以及同步委员会聚合。之前，自愿退出也需要由活跃 BLS 私钥签名。第二对密钥（“取款凭证”）可以是另一个 BLS 密钥对，也可以是常规的 Eth1 账户。过去，提取 ETH 需要由活跃 BLS 私钥签名的取款消息，而 EIP-7002 改变了这个机制。

实际情况是，这两对密钥的所有者可以不是同一个人。活跃密钥负责验证职责（比如跑服务器什么的），而取款凭证通常由质押所有者控制，负责接收奖励和管理资金。目前的问题是，只控制取款凭证的质押所有者无法启动验证者退出，只能提取奖励。这意味着活跃密钥所有者可以把验证者余额当“人质”来用。虽然验证者可以“预签”退出消息交给质押所有者，但这并不是理想的方案。另外，提款和退出之前需要通过专门的 API 跟信标层交互。

最好的解决方案，是允许质押所有者通过常规智能合约调用，同时执行退出和取款。这涉及到标准的 Eth1 签名检查，操作起来会简单得多。

EIP-7002 允许质押所有者通过向一个专门的智能合约发送标准交易，来触发取款和退出（流程跟现有的存款类似）。具体步骤是这样的：

• 质押者向系统的“取款”合约发送取款请求（也就是“in”请求）。

• 合约收取一定费用（以 ETH 为单位）来防范潜在攻击，费用机制类似于 EIP-1559，在队列繁忙时会增加。

• 合约把“in”取款/退出请求保存到存储里。

• 当信标层提议区块时，队列里的“in”请求会被从存储中检索出来。

• 信标层处理这些“in”请求，与活跃验证者余额交互，安排验证者退出，然后形成“out”取款请求。

• “out”取款请求在执行层处理，质押者就能收到 ETH。

以前，存款是在 Eth1 区块触发后移到信标层，而取款是在信标层触发后移到 Eth1 区块。现在，这两种方案都将通过同一个通用的框架来操作：在 Eth1 层创建请求，处理待处理队列，然后在信标层处理。对于“输出”操作，结果会在 Eth1 区块中结算。

通过这个 EIP，质押者可以用常规的 ETH 交易来提取并退出验证者，不需要直接跟验证者的 CLI 交互，也不用访问基础设施。这极大地简化了质押操作，特别是对大型质押提供者来说。验证者基础设施现在几乎可以完全隔离，只需要维护活跃密钥，所有质押操作都可以在外部处理。这消除了独立质押者等待活跃验证者动作的需要，也显著简化了 Lido 这类服务的链外部分。

可以说，这个 EIP 完成了质押操作的迁移，把它完全搬到了 Eth1 层，降低了基础设施的安全风险，也增强了去中心化。

EIP-6110：在链上供应验证者存款

参考: EIP-6110

目前，存款是通过系统“存款”合约中的事件来实现的。合约接收 ETH 和验证者凭证，发出一个“Deposit()”事件，然后这个事件被解析并转换成信标层上的存款请求。这个系统有个缺点：它要求对信标链层的 eth1data 进行投票，这引入了显著的延迟；信标层还需要查询执行层，增加了复杂性。EIP-6110 提出了一种更直接的方法：在 Eth1 区块的指定位置，直接包含存款请求。这个机制跟前面说的取款处理流程很相似。

这个 EIP 带来的变化前景不错。eth1data 处理现在可以完全移除，不再需要在 Eth1 侧的事件和信标层存款包含之间进行投票，也不用再忍受大约 12 小时的长时间延迟。同时，存款合约的快照逻辑也被移除了。这个 EIP 简化了存款处理，并让它和取款处理方案对齐了。

对质押者和验证者来说，这些变化显著减少了存款到验证者激活之间的延迟。当验证者被削减时，必要的补充操作也会更快完成。

EIP-7685：通用执行层请求

参考: EIP-7685

这个 EIP 其实应该在前面三个跟存款、取款、合并相关的 EIP 之前提出来，因为它为这些 EIP 奠定了基础。放在这里讲，是为了强调在 Eth1（执行链）和信标（共识链）区块之间，一致地移动专用数据的需求是非常必要的。这个 EIP 影响了两层，让通过常规 ETH 交易触发的请求处理变得更高效。目前我们可以看到：

• Eth1 区块中的存款事件被“移动”到信标块处理。

• 信标块中的取款请求（通过 CLI 发起）被“移动”到 Eth1 块处理。

• 验证者合并的处理，也是一种 Eth1 到信标的请求。

这三项操作都说明，在执行层和信标层之间转换时，需要一致地处理各种类型的请求。此外，我们需要一种仅靠 Eth1 层就能触发这些操作的能力，以便把验证者基础设施跟质押管理基础设施隔离开，提高安全性。因此，一个管理这类请求的通用解决方案，既实际又必要。

这个 EIP 为至少三种主要情况建立了框架：存款、取款和合并。早期的 EIP 引入了 WITHDRAWAL_REQUEST_TYPE 和 DEPOSIT_REQUEST_TYPE 字段，合并则会添加 CONSOLIDATION_REQUEST_TYPE。此外，这个 EIP 还包括处理这类请求限制的通用机制（可以参考常量：PENDING_DEPOSITS_LIMIT、PENDING_PARTIAL_WITHDRAWALS_LIMIT、PENDING_CONSOLIDATIONS_LIMIT）。

虽然详细的实施细节还没出来，但肯定会包括关键的请求类型、完整性机制（比如哈希和默克尔化请求），以及待处理队列的处理和速率限制。

这个 EIP 具有架构层面的意义——它让 Eth1 能够通过一个统一的框架，触发信标层中的关键操作。对最终用户和项目方来说，这意味着在 Eth1 层触发的所有请求，在信标层上会被更高效地传递和处理。

EIP-2537：BLS12-381 曲线操作的预编译

参考: EIP-2537

如果不深入技术细节，可以把 BLS12-381 的预编译理解成一种复杂的加密“哈希”操作，现在可以在智能合约里直接用了。像 BLS12-381 这样的椭圆曲线（以及它的对应曲线 BN-254），其数学运算目前主要用于两个目的：

• BLS 签名验证
  ：通过“配对”操作来验证签名。BLS 签名被验证者广泛使用，因为它支持把多个签名聚合为一个。验证者用的就是基于 BLS12-381 曲线的 BLS 签名。

• zkSNARK 证明验证
  ：配对也用于验证证明。此外，Dencun 升级引入的大区块 KZG 承诺，也使用配对来验证区块承诺。

在智能合约里验证 BLS 签名或 zkSNARK 证明，需要计算“配对”，这在计算上非常昂贵。以太坊已经有用于 BN254 曲线操作的预编译合约（EIP-196 和 EIP-197），但 BLS12-381 曲线——通常被认为更安全且应用更广泛——还没实现。在没有预编译的情况下，实现配对要消耗巨大的 gas（大概在 10^5 到 10^6 gas 的量级）。

这个 EIP 为许多潜在应用打开了大门，尤其是基于 BLS12-381 曲线的低成本 BLS 签名验证。这使得实现各种门限方案成为可能。标准智能合约现在可以高效地验证聚合的验证者签名，简化共识证明和跨网络资产桥接。门限 BLS 签名本身，也为构建用于投票、去中心化随机数生成、多签等场景的高效门限方案提供了条件。

更便宜的 zkSNARK 证明验证，将解锁大量应用。许多基于 zkSNARK 的解决方案目前都受限于高昂的验证成本，这个 EIP 有望改变这一现状。

EIP-2935：在状态中保存历史区块哈希

参考: EIP-2935

这个 EIP 提议在区块链状态中存储 8192 个（大约 27.3 小时）历史区块哈希，为无状态客户端（比如 Rollup）和智能合约提供扩展的历史数据。它建议保留 BLOCKHASH 操作码的现有行为（限制在最近 256 个区块），同时引入一个专门用于存储和检索历史哈希的新系统合约。这个合约在执行层处理区块时执行 set() 操作，它的 get() 方法可以供任何人访问，从环形缓冲区里检索所需的区块哈希。

目前在 EVM 里引用历史区块哈希，只能访问最近 256 个区块（大约 50 分钟）。但是，跨链应用（需要证明先前的区块数据）和无状态客户端（需要定期访问早期区块哈希）对访问旧数据的需求至关重要。

这个 EIP 扩展了 Rollup 和跨链应用可用的时间范围，允许它们直接在 EVM 中访问历史数据，不需要外部收集，这使得解决方案更加健壮和可持续。

EIP-7623：增加 calldata 成本

参考: EIP-7623

calldata 的成本调节着交易有效负载的大小。大规模的 calldata 使用主要是 Rollup 导致的，它们通过包含当前状态的 calldata 来发送有效负载。

把大型可证明的二进制数据引入区块链，对 Rollup 来说至关重要。Dencun 升级为此引入了 blob 交易（EIP-4844）。blob 交易有专门的“blob”gas 费用，主体数据被临时存储，但它的加密证明（KZG 承诺）以及哈希被整合到了共识层。因此，blob 为 Rollup 提供了比 calldata 更好的解决方案。

鼓励 Rollup 把数据迁移到 blob，可以通过“胡萝卜加大棒”的策略来实现。降低的 blob gas 费用是“胡萝卜”，而这个 EIP 通过提高 calldata 成本作为“大棒”，来抑制过度的数据存储。这个 EIP 和 EIP-7691（增加 blob 吞吐量）形成了互补，后者提高了每个区块允许的 blob 最大数量。

EIP-7691：blob 吞吐量增加

参考: EIP-7691

在 Dencun 硬分叉引入 blob 时，“每区块”blob 的最大值和目标值设定得比较保守，主要是为了应对 P2P 网络传播大型二进制对象的复杂性。鉴于之前的配置运行得还不错，现在是时候测试新值了。此前，每区块的目标/最大 blob 数量设为 3/6。现在分别提高到了 6/9。

结合 EIP-7623，这一调整会进一步激励 Rollup 把数据从 calldata 迁移到 blobs。当然，寻找最佳 blob 参数的工作还在继续。

EIP-7840：将 blob 调度添加到 EL 配置文件

参考: EIP-7840

这个 EIP 提议把目标和最大“每区块”blob 数量，以及 baseFeeUpdateFraction 值，添加到以太坊执行层（EL）的配置文件中。同时，它让客户端能够通过节点 API 检索这些值。这个功能对于估算 blob gas 费用等任务来说特别有用。

EIP-7702：设置 EOA 账户代码

参考: EIP-7702

这是一个会给用户带来重大变化的 EIP。传统的 EOA（外部拥有账户）不能拥有代码，只能提供交易签名。相比之下，智能合约有字节码，但不能主动发起直接签名。目前，需要额外逻辑的用户交互只能通过调用外部合约来执行。但在这种情况下，外部合约会成为后续合约的 msg.sender，导致调用“来自合约而不是用户”。

EIP-7702 引入了一种新的 SET_CODE_TX_TYPE=0x04 交易类型。这种新的交易类型允许为 EOA 账户设置代码。实际上，它允许 EOA“在其自身账户的上下文里”执行外部代码。从外部视角看，EOA 在交易过程中仿佛“借用”了外部合约的代码来执行。技术上，这是通过把特殊的授权数据元组添加到 EOA 地址的“代码”存储中实现的——此前，这个存储对于 EOA 来说始终是空的。

目前，这个 EIP 提议的新 0x04 交易类型包含一个数组：

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

数组里的每个元素，允许账户使用来自指定地址的代码。在处理这类交易时，系统会把给定的 EOA 的代码设置为一个特殊的值 0xef0100 || 地址（共 23 字节），其中地址指向一个包含所需代码的合约。0xef0100 是一个常规智能合约无法包含的特殊魔法值（根据 EIP-3541），它确保了这个 EOA 不会被当作常规合约，也不能像常规合约一样被调用。

当这个 EOA 发起交易时，指定的地址将被用于在该 EOA 的上下文中调用相应的代码。

这个 EIP 最主要的影响之一，是能够直接从 EOA 进行多重调用（multicall）。多重调用是 DeFi 里一个持续的趋势，很多协议（比如 Uniswap V4、Balancer V3、Euler V2）都已经提供了这个功能。有了这个 EIP，用户现在可以直接从 EOA 发起多重调用。

举个例子，这个新特性解决了 DeFi 里 approve() + anything() 需要两笔独立交易的低效问题。这个 EIP 允许通用的“预授权”逻辑，使得 approve(X) + deposit(X) 可以在单笔交易里完成。

能够“代表”EOA 委托交易执行的另一个优势，是“赞助”的概念。赞助是帮助新用户进入以太坊的一个很受欢迎的特性。

与 EOA 关联的可编程逻辑，解锁了很多可能性，比如可以实施安全限制、设置支出上限、强制执行 KYC 要求等等。

当然，这个转变也带来了一些设计上的问题。比如 chain_id 的使用决定了签名在多网络间的有效性；目标代码地址和嵌入实际字节码之间的选择各有优劣；nonce 的使用则定义了权限是“多用途”还是“单一用途”。这些元素会影响到功能和安全，包括签名批量失效的便利性以及易用性。Vitalik 在讨论中也提出了这些问题，值得进一步探索。

值得注意的是，这个变化会影响以太坊的安全机制 tx.origin。require(tx.origin == msg.sender) 的行为可能会改变。以前，这个检查是用来确保 msg.sender 是 EOA 而不是合约的最可靠方法。其他方法（比如检查 EXTCODESIZE）经常会被绕过。这些检查通常用于防止重入和闪电贷攻击，但也妨碍了与外部协议的集成。在这个 EIP 之后，即使是 require(tx.origin == msg.sender) 这种检查也可能变得过时。协议必须适应新的情况，因为“EOA”和“合约”之间的界限将不再清晰——每个地址都可能拥有相关的代码。

传统的 EOA 和智能合约之间的分离，正在继续模糊化。这个 EIP 让以太坊更接近 TON 这类设计——每个账户本质上都是可执行代码。随着与协议交互的日益复杂，使用可编程逻辑来改善最终用户体验，是这个演进过程中很自然的一步。