以太坊 2.0 向「权益证明」（PoS）过渡的历史并非一蹴而就。这一进程始于在现有执行层之上引入信标层，在信标层启动 PoS 共识的同时，执行层仍短暂维持工作量证明（PoW）机制（Phase0 和 Altair 硬分叉阶段）。随后，Bellatrix 硬分叉全面激活了 PoS（尽管当时尚未开放提款功能）。Capella 硬分叉则正式允许提款，标志着验证者生命周期的闭环。近期的 Deneb 硬分叉（作为 Dencun 升级的一部分）对信标链参数进行了微调，例如优化了包含证明的时间窗口、处理自愿退出及验证者更换限制。Dencun 的核心变革发生在执行层，引入了 blob 交易、blob gas 以及用于 blob 的 KZG 承诺，并废弃了 SELFDESTRUCT 操作。
如今，Prague/Electra（即 Pectra）硬分叉为执行层和共识层带来了里程碑式的升级。作为 Lido 项目的审计方，我们重点关注此次升级中与共识和质押相关的变化，但执行层的更新同样不容忽视，因为它们深刻影响着以太坊网络性能及验证者的运作效率。以下将深入解析这些关键变革。
Pectra 升级概览
Electra 升级为信标层引入了多项核心功能，主要更新包括：
验证者的有效余额范围扩大至 32 至 2048 ETH（此前固定为 32 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 还调整了削减比例，定义了被削减验证者余额中由举报者接收的部分。
关于无效性惩罚：当验证者在活跃期间（证明或提议）离线时，无效性分数会累积，导致每个周期施加惩罚。这些惩罚同样与验证者的有效余额成比例。
有效余额的增加也影响了验证者的「更换限制」（Churn Limit）。在 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 质押比管理 64x32 质押要简单得多。
流动质押提供者：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 上下文中调用相应代码。
主要影响之一是能够直接从 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 而非合约的最可靠方法。其他方法（如检查 EXTCODEG9AQVG）常被规避。这些检查用于防止重入和闪电贷攻击，但也妨碍与外部协议的集成。在此 EIP 之后，即使是 require(tx.origin == msg.sender) 检查也可能变得过时。协议必须适应，因为「EOA」和「合约」之间的界限将不再清晰——每个地址都可能拥有相关代码。
传统的 EOA 和智能合约分离继续模糊。此 EIP 使以太坊更接近 TON 等设计，其中每个账户本质上都是可执行代码。随着与协议交互日益复杂，使用可编程逻辑改善最终用户体验是这一演进的自然过程。
