Pectra升级：以太坊硬分叉的关键细节解析_币圈资讯

以太坊的Pectra硬分叉升级即将到来，这次升级不仅仅是技术上的改进，更是对以太坊生态的一次全面优化，从验证者有效余额的调整到新的预编译合约，Pectra升级将如何改变以太坊的运行方式？本文将带你深入了解这些变化，从验证者管理的简化到执行层的新功能，逐一解析Pectra升级的核心内容，无论你是开发者、验证者还是普通用户，这次升级都将对你的以太坊体验产生深远影响，让我们一起探索Pectra升级的细节，看看它如何为以太坊的未来铺平道路！

以太坊的Pectra硬分叉即将到来，这次升级将为执行层和共识层带来多项重要改进。从验证者有效余额的调整到新的预编译合约，Pectra升级将显著提升以太坊的性能和灵活性。本文将深入解析这些变化，帮助你了解它们对以太坊生态的影响。

以太坊2.0的「权益证明」硬分叉历程充满了复杂性。最初，信标层被引入到现有的执行层中，信标层启动了权益证明共识，而执行层仍然保持工作量证明（Phase0和Altair硬分叉）。随后，Bellatrix硬分叉完全激活了PoS（尽管提款功能尚未启用）。接着，Capella硬分叉允许提款，完成了验证者的生命周期。最近的Deneb硬分叉（Dencun升级的一部分）对信标链参数进行了小幅调整，例如包含证明的时间窗口、处理自愿退出和验证者更换限制。Dencun的主要变化发生在执行层，引入了blob交易、blob gas、用于blob的KZG承诺，并废弃了SELFDESTRUCT操作。

现在，Prague/Electra（即Pectra）硬分叉为执行层和共识层带来了重要升级。作为Lido项目的审计员，我们主要关注此次硬分叉中与共识和质押相关的变化。不过，Prague中的执行层变化也不容忽视，因为它们包含了影响以太坊网络及验证者的重要特性。让我们深入探讨这些变化的细节。

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可以执行的操作，如执行multicalls或将执行委托给其他地址。

让我们参考相关的以太坊改进提案（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之间存款以激活，所有这些金额都将贡献其有效余额。这一转变标志着从「32ETH-权益证明」转向「权益证明」。

这个可变的有效余额现在将被用于：

增加成为区块提议者的概率，与有效余额成正比。
增加成为同步委员会成员的概率，与有效余额成正比。
作为计算相对削减和不活跃处罚金额的基础。

前两个活动是验证者最有回报的操作。因此，在Electra之后，大额质押的验证者将更频繁地参与区块提议和同步委员会，其频率与他们的有效余额成正比。

另一个影响与削减有关。所有削减罚金与验证者的有效余额成正比：

「立即」和「延迟」的削减罚金对高额质押的验证者来说更大。
与有高额质押的被削减验证者一起的「延迟」削减罚金也更大，因为总质押中的「被削减」部分变得更大。
报告有效余额较高的验证者的举报者获得更大比例的被削减的质押。

Electra还提出了对削减比例的更改，定义了被削减的验证者余额的一部分，并由举报者接收。

接下来是无效性影响。当验证者在活跃时（证明或提议）离线时，无效性分数会累积，导致每个周期施加无效性惩罚。这些惩罚也与验证者的有效余额成比例关系。

由于有效余额的增加，验证者的「更换限制」也发生了变化。在「Electra之前」的以太坊中，验证者通常具有相同的有效余额，退出更换限制定义为「在一个周期内，最多不能有1/65536（spec.churn_limit_quotient）的总质押可以退出。」这创建了一个「固定」的具有相同质押的验证者退出数量。然而，在「Electra之后」，可能出现只有少数「鲸鱼」退出的情况，因为它们代表了总质押的一个重要部分。

另一个考虑是单个验证者实例上许多验证者密钥的轮换。大型验证者目前被迫在一个实例上运行数千个验证者密钥，以适应大额质押，将其拆分为32 ETH部分。随着Electra，这种行为不再是强制性的。从财务角度来看，这一变化影响不大，因为奖励和概率与质押金额线性缩放。因此，100个每个32 ETH的验证者等同于一个3200 ETH的验证者。此外，多个活跃的验证者密钥可以具有相同的Eth1取款凭证，允许所有奖励提取到单个ETH地址，从而避免与奖励合并相关的gas成本。然而，管理大量密钥会产生额外的管理成本。

聚合验证者的余额的能力增加了一种新的执行层请求类型。之前，我们有存款和取款。现在，将会有另一种类型：聚合请求。它将两个验证者合并为一个。该操作请求将包括源验证者的公钥和目标公钥，并将类似于存款和取款进行处理。聚合也将有待处理的请求和余额更换限制，就像存款和取款一样。

总结如下：

对于小型的独立验证者，Electra引入了自动增加其有效余额（和奖励）的能力。之前，任何超出32 ETH的盈余只能提取，但在Electra之后，这一盈余最终将贡献于其有效余额。然而，有效余额只能按照spec.effective_balance_increment（1 ETH）的倍数增加，这意味着增加仅在达到下一个「1 ETH界限」后发生。
对于大型独立验证者，Electra通过允许将多个活跃验证者密钥整合为一个，提供了显著的管理简化。虽然这并不会改变游戏规则，但经营一个1x2048质押无疑比管理64x32质押要简单得多。
对于流动质押提供者，他们从用户那里收集小额质押并在验证者之间分配，Electra在质押分配方案中增加了更多灵活性，但同时也需要对基于固定32 ETH有效余额的验证者会计进行严重重构。

另一个重要话题是验证者的历史数据和利润估算，对新参与者尤其相关，他们试图评估风险和回报。在Electra之前（截至本文撰写时），32 ETH上限（无论是最小还是最大，实际上）在历史数据中创造了均匀性。所有验证者的有效余额、奖励、个体削减惩罚、区块提议频率和其他指标都相同。这种均匀性使以太坊能够在没有统计异常值的情况下测试其共识机制，从而收集有价值的网络行为数据。

在Electra之后，质押的分布将发生重大变化。大型验证者在区块提议和同步委员会中的参与将更频繁，在削减事件中将面临更大的惩罚，并对延迟削减、激活队列和退出队列有更大的影响。虽然这可能在数据聚合中造成挑战，但以太坊的共识确保非线性计算是最小的。唯一的非线性组件使用sqrt(total_effective_balance)来计算基本奖励，这适用于所有验证者。这意味着验证者奖励和削减仍然可以在「每1 ETH」基础上（或更准确地说，根据spec.effective_balance_increment，这可能在未来发生变化）进行估算。

有关更多详细信息，请参阅我们之前关于验证者行为的文章。

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

参考：EIP-7002

以太坊中的每个验证者都有两个密钥对：一个活跃密钥和一个取款密钥。活跃的公共BLS密钥作为验证者在信标链中的主要身份，该密钥对用于签署区块、证明、削减、同步委员会聚合，以及（在此EIP之前）自愿退出（以在延迟后启动验证者的共识退出）。第二个密钥对（「取款凭证」）可以是另一个BLS密钥对或常规的Eth1账户（私钥和地址）。现在，提取到ETH地址需要由活跃BLS私钥签名的取款消息。这一EIP进行了更改。

实际上，这两个（活跃和取款）密钥对的所有者可以是不同的。验证者的活跃密钥负责验证职责：运行服务器、保持其正常运行等，而取款凭证通常由质押所有者控制，质押所有者接收奖励并负责资金。目前，只有控制取款凭证的质押所有者无法启动验证者的退出，只能提取奖励。这种情况允许验证者的活跃密钥所有者有效地将验证者的余额作为「人质」握在手中。验证者可以「预签」退出消息并将其交给质押所有者，但这种变通方法并不理想。此外，目前提取和退出都需要通过专门的API与信标层验证者进行交互。

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

这一EIP允许质押所有者通过从他们的ETH地址向专用智能合约发送标准交易来触发取款和退出（类似于现有的使用「存款」合约的存款过程）。提取（或在移除足够质押时进行的退出）过程如下：

质押者向系统的「取款」合约发送取款请求（「in」请求）。
合约收取特定的费用（以ETH计）以减轻潜在的恶意攻击，并类似于EIP-1559，在请求队列繁忙时费用会增加。
合约将「in」取款/退出请求保存到其存储中。
当一个区块被提议到信标层时，队列中的「in」取款/退出请求会从存储中检索。
信标层处理「in」请求，与活跃验证者的余额交互，安排验证者退出，并形成「out」取款请求。
「out」取款请求在执行层处理，质押者接收他们的ETH。

虽然存款是在Eth1区块中触发的操作，然后通过「待处理」存款队列「移动」到信标层，但取款则遵循了不同的方案。它们在信标层（通过CLI）上触发，然后「移动」到Eth1区块。现在，两种方案将通过相同的通用框架（如下所述）进行操作：在Eth1层创建请求，处理「待处理」存款/取款/合并队列，并在信标层处理。对于像取款这样的「输出」操作，输出队列也会被处理，结果将在Eth1区块中「结算」。

通过此EIP，质押者可以使用常规ETH交易提取并退出他们的验证者，而无需直接与验证者CLI交互或访问验证者的基础设施。这大大简化了质押操作，特别是对于大型质押提供者。验证者的基础设施现在几乎可以完全隔离，因为只需维护活跃验证者的密钥，而所有质押操作可以在其他地方处理。它消除了独立质押者等待活跃验证者动作的需求，并显著简化了像Community Staking Module这样的Lido服务的链外部分。

因此，此EIP「完成」了质押操作，完全将其迁移到Eth1层，显著降低了基础设施安全风险，并增强了独立质押倡议的去中心化。

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

参考：EIP-6110

目前，存款是通过系统「存款」合约中的事件实现的（如在之前的文章中详细讨论）。合约接受ETH和验证者凭证，发出「Deposit()」事件，这些事件随后被解析并转换为信标层上的存款请求。该系统有许多缺点：它要求对信标链层的eth1data进行投票，这增加了显著的延迟。此外，信标层需要查询执行层，进一步增加了复杂性。这些问题在EIP中进行了详细讨论。一种更简单的方法，无需处理许多这些问题，是直接在指定位置将存款请求包括在Eth1区块中。该机制类似于在之前EIP中描述的取款处理流程。

此EIP中提出的变化很有前景。eth1data处理现在可以完全移除，不再需要在Eth1侧的事件与信标层上存款包含之间进行投票或长时间延迟（当前大约为12小时）。它还移除了存款合约快照的逻辑。此EIP简化了存款处理，并使其与上述取款处理方案对齐。

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

关于此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层触发的所有请求将在信标层上更高效地传递和处理。