布拉格/伊莱克特拉（Pectra）升级计划于2025年3月进行。

撰写者：Sergey Boogerwooger，Dmitry Zakharov，Mixbytes

汇编：AI翻译，Denglian社区

介绍

在上一篇文章中，我们详细介绍了以太坊验证器的生命周期，讨论了与即将到来的Electra Hard Fork相关的多个方面。现在，是时候专注于即将到来的Electra和Brague升级的变化并进行详细解释了。

以太坊2.0的“股份证明”硬叉的历史很复杂。首先，将信标层添加到现有的执行层中，该执行层维持工作证明（阶段0和Altair硬叉），而信标则启动了Stake Consensus的证明。随后，POS在Bellatrix Hard Fork中被充分激活（尽管未启用退出）。然后，Capella Hard Fork允许取款，完成验证者的生命周期。最近的Hard Forks Deneb（Deneb/cancun升级的一部分）对信标链参数进行了少量修订，例如包含证据的时间窗口，处理志愿出口和验证器更换限制。 Dencun的主要变化发生在执行层，发射BLOB交易，Blob Gas，KZG承诺对斑点和放弃自我灭绝操作。

现在，布拉格/伊莱克特拉（IE Pectra）硬叉将重要的升级引入了执行和共识层。作为Lido项目的审计师，我们主要关注此硬叉中的共识和与Staking相关的变化。但是，我们不能忽略布拉格的执行层变化，因为它们包含影响以太坊网络和验证器的重要功能。让我们研究这些更改的细节。

Pectra的更高级别概述

Electra向信标层介绍了许多功能。主要更新包括：

同时，布拉格将以下更改引入了执行层：

让我们参考相关的以太坊改进建议（EIP）以进行进一步讨论：

这些EIP中的一些主要涉及共识层（Beacon）层，而另一些则与执行层有关。一定要跨越两个层，因为某些操作（例如存款和提款）需要共识和执行层之间的同步更改。由于这种相互依赖性，分开电气和布拉格是不切实际的，因此我们将依次审查每个EIP并指定每种情况下影响的以太坊成分。

EIP-7251：添加了max_effective_balance

参考：EIP-7251

由于为了准备以太坊的股份证明，因此验证器的最大有效余额已固定为32 ETH直到Electra。激活验证器的要求至少是规格。min_activation_balance（32 eth）。激活后，验证器以此最大有效的余额开始，但可以将其有效余额减少到Spec.evection_Balance（16 ETH），并在达到此阈值时被驱逐。这种“最低”逻辑在Electra中保持不变，但是现在Spec.max_effective_balance已增加到2048 ETH。因此，验证者可以存入32至2048 ETH之间以激活，所有这些都将贡献其有效的平衡。这种转变标志着从“ 32th of Stake”到“股份证明”的转变:)

现在，此变量有效余额将用于：

前两个活动是验证者最有意义的行动。因此，在Electra之后，大赌注的验证者将更频繁地参与块提案和同步委员会，其频率与其有效平衡成正比。

另一个影响与削减有关。所有削减与验证者的有效平衡成正比：

伊莱克特（Electra）还提出了切割比率的更改，定义了一部分被削减的验证者平衡，并通过举报人接收它。

接下来是无效的影响。当验证器在活动（证明或提出）时脱机时，无效分数会累积，导致每个周期的无效罚款。这些惩罚也与验证者的有效余额成正比。

由于有效余额的增加，验证者的“替换限制”也发生了变化。在以太坊的“ electra”之前，验证者通常具有相同的有效余额，而退出置换限制则定义为“在周期中，最多不能有1/65536（Spec.churn_limit_quotient）要退出的总股份。”这会创建一个“固定”数量的验证者以相同的股份退出。但是，在Electra之后，可能只有几个“鲸鱼”出口，因为它们代表了总承诺的重要组成部分。

另一个考虑因素是在单个验证程序实例上旋转许多验证键。当前，大型验证者被迫在一个实例上运行数千个验证器键，以容纳大量堆积，将其分为32个ETH部分。对于Electra，这种行为不再是强制性的。从财务的角度来看，这种变化几乎没有影响，因为奖励和概率与承诺的数量线性扩展。因此，每32个ETH的100个验证器等同于一个3200 ETH。此外，多个主动验证键可以具有相同的ETH1撤回证书，从而使所有奖励都可以撤回到一个ETH地址，从而避免了与奖励合并相关的汽油成本。但是，管理大量钥匙会产生额外的管理费用。

汇总验证器平衡的能力增加了新的执行层请求类型。以前，我们进行了存款和提款。现在，将有另一种类型：汇总请求。它将两个验证器结合在一起。此操作请求将包括源验证者的公钥和目标公钥，并将与存款和提款类似。聚合还将有未决的请求和余额替换限制，就像存款和提款一样。

摘要如下：

另一个重要的主题是对验证者的历史数据和利润估计，特别是与新参与者相关的验证者，他们试图评估风险和奖励。在获得Electra之前（截至撰写本文），32 ETH CAP（实际上是最小或最大）在历史数据中创造了统一性。所有验证者都具有相同的验证余额，奖励，个人削减惩罚，块提案频率和其他指标。这种统一性使以太坊可以在没有统计异常值的情况下测试其共识机制，从而收集有价值的网络行为数据。

伊莱克特拉（Electra）之后，放电的分布将发生显着变化。大型验证者将更频繁地参与块建议和同步委员会，削减的处罚更大，对延迟削减，激活队列和退出队列的影响更大。尽管这可能在数据聚合中引起挑战，但以太坊的共识确保了非线性计算很小。唯一的非线性组件使用SQRT（total_effective_balance）来计算适用于所有验证器的基本奖励。这意味着验证者的奖励和削减仍然可以按照“ per-1 eth”的基础进行估算（或更准确地说，基于spec.effective_balance_increment，这可能会在将来发生变化）。

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

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

参考：EIP-7002

以太坊中的每个验证器都有两个密钥对：一个活动键和提款键。活跃的公共BLS密钥是信标链中验证者的主要身份，该核心链用于签名，证明，削减，削减，同步委员会聚合，（在此EIP之前）自愿退出（遵循延迟启动verifier的共识，出口）。第二个密钥对（“提款券”）可以是另一个BLS密钥对或常规的ETH1帐户（私钥和地址）。现在，由Active BLS私钥签名的提款消息必须提取到ETH地址。此EIP已更改。

实际上，这两个（主动和退出）钥匙对的所有者可能会有所不同。验证者的活动键负责验证职责：运行服务器，使其正态运行等，并且取款凭证通常由股权所有者控制，后者获得奖励并负责资金。目前，只有控制取款凭证的承诺所有者不能启动验证者的退出，只能撤回奖励。这种情况使验证者的主动钥匙所有者可以有效地将验证者的平衡作为“人质”。验证者可以“预先签名”退出消息并将其移交给利益相关者，但是这种解决方法并不理想。此外，当前提取和退出都需要通过专用API与信标层验证器进行交互。

最好的解决方案是允许股权所有者通过常规的智能合同电话同时执行退出和提款操作。这涉及标准ETH1签名检查，这大大简化了操作。

该EIP允许利益相关者通过将标准交易从其ETH地址发送给专用的智能合约（类似于使用“存款”合同的现有存款过程）来触发提款和退出。提取（或在删除足够的股份时退出）的过程如下：

尽管沉积物是在ETH1块中触发的操作，然后通过“未决”的存款队列“移动”到信标层，但撤回遵循不同的方案。它们在信标层（通过CLI）上触发，然后“移动”到ETH1块。现在，这两个方案将通过相同的常见框架（如下所述）运行：在ETH1层创建一个请求，处理“未决”存款/提款/合并队列，并在信标层进行处理。对于“输出”操作，例如撤回，也将处理输出队列，结果将在ETH1块中“固定”。

使用此EIP，Stakers可以使用常规的ETH交易来提取和退出其验证器，而无需直接与验证器CLI进行交互或访问验证器的基础结构。这极大地简化了堆放操作，尤其是对于大型Staging提供商而言。现在几乎可以完全隔离验证者基础架构，因为只有维护活动验证者的键，而所有放电操作都可以在其他地方处理。它消除了独立的公司等待积极验证器动作的需求，并大大简化了诸如社区放入模块之类的利多链链部分。

因此，该EIP“完成”了放电操作，将其完全迁移到ETH1层，大大降低了基础设施安全风险并增强了独立桩计划的权力下放。

EIP-6110：链上的验证剂供应

参考：EIP-6110

当前，通过系统的“存款”合同中的事件（如先前文章中详细讨论）来实现存款。合同接受ETH和验证者的证书和问题“存款（）”事件，然后将其解析并转换为信标层上的存款请求。该系统有许多缺点：它需要对信标链层的ETH1DATA进行投票，这增加了重大的延迟。此外，信标层需要查询执行层，这进一步提高了复杂性。这些问题将在EIP中详细讨论。在不处理许多问题的情况下，更简单的方法是直接在指定位置的ETH1块中包括存款请求。该机制类似于上一个EIP中描述的撤回处理过程。

本EIP中提出的更改是有希望的。 ETH1DATA处理现在可以完全删除，不再需要在ETH1方面的事件之间进行投票或延长延误，并在信标层上（目前约12小时）存入夹杂物。它还消除了存款合同快照的逻辑。该EIP简化了存款处理，并将其与上述撤回处理方案保持一致。

对于Stakers和验证者，这些变化大大减少了存款和验证器激活之间的延迟。切割验证器时，必要的补充剂也将更快。

关于这种EIP，除了它消除过时的逻辑，简化了过程并为所有相关人员创造更好的结果外，没有什么可说的。

EIP-7685：一般执行层请求

参考：EIP-7685

该EIP应该是在前三个EIP与存款/戒断/合并有关的EIP之前提出的，因为它为这些EIP奠定了基础。但是，这里的引言是为了强调ETH1（执行）和信标（共识）链块（层）之间对一致的移动专用数据的不断增长的需求。该EIP会影响两层，从而使常规ETH交易触发的请求处理更加有效。目前，我们观察到：

这三个操作证明了在执行层和信标层之间切换时必须一致处理各种请求的必要性。此外，我们需要仅使用ETH1层触发这些操作的能力，因为这将使我们能够将验证者的基础结构隔离在堆放管理基础架构中，从而提高安全性。因此，管理此类请求的一般解决方案既实用又必要。

该EIP为至少三个主要情况建立了一个框架：存款，提款和合并。这就是为什么早期EIP介绍了诸如fortal_request_type和posite_request_type之类的字段，现在合并将添加另一个字段consolidation_request_type。此外，此EIP可能包括处理此类请求限制的常见机制（参考常数：pending_deposits_limit，pending_pendial_withdrawals_limit，pending_consolidations_limit）。

尽管此框架的详细实施详细信息仍然不可用，但它肯定会包括关键请求类型，完整性机制（例如，哈希和默克尔请求）以及等待的队列处理和限制速率。

该EIP具有架构意义，使ETH1能够通过统一的框架触发信标层中的关键操作。对于最终用户和项目，这意味着在ETH1层上触发的所有请求将在信标层上更有效地交付和处理。

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

参考：EIP-2537

如果您不想更深入地看，您可以将BLS12-381的预编码视为复杂的加密“哈希”操作，现在可以在智能合约中使用。对于那些有兴趣的人，让我们进一步探索。

目前主要用于两个目的：诸如BLS12-381（及其相应的BN-254）等椭圆曲线（及其相应的BN-254）的数学操作：

如果您想在智能合约中验证BLS签名或ZKSNARK证明，则必须计算这些“ Pairs”，这在计算上很昂贵。以太坊已经有用于BN254曲线操作的预编译合同（EIP-196和EIP-197）。但是，BLS12-381曲线（如今被认为更安全，更广泛地使用）尚未按预先编译进行实施。在没有这样的预编译的情况下，在智能合约中实施配对和其他曲线操作需要大量计算，如下所示，并且消耗了巨大的气体（约为10^5至10^6的气体）。

该EIP为许多潜在应用打开了大门，尤其是在基于BLS12-381曲线的廉价BLS签名验证中。这使得出于各种目的实现阈值解决方案。如前所述，以太坊验证器使用了基于BLS12-381的签名。使用此EIP，标准智能合约现在可以有效地验证聚合的验证者签名。这可以简化共识和跨网络资产的证明，因为BLS签名广泛用于区块链中。阈值BLS签名本身允许构建许多有效的阈值方案，用于投票，分散的随机数，多签名等。

便宜的ZKSNARK证明验证将依次解锁大量应用程序。目前，许多基于ZKSNARK的解决方案都受到高证明验证成本的阻碍，这使某些项目几乎不切实际。该EIP有可能改变这一点。

EIP-2935：保存状态的历史街区哈希

参考：EIP-2935

该EIP建议在区块链状态下存储8192（约27.3小时）的历史障碍物，为无状态客户（例如汇总和智能合约）提供了扩展的历史。它建议保留Blockhash OpCode的当前行为，维持256个区块的限制，同时引入专门为存储和检索历史哈希的新系统合同。当执行层处理块时，该合同执行set（）操作。任何人都可以访问它的get（）方法，可以从环形缓冲区中检索所需的块哈希。

目前，可以将EVM中的历史块Hash引用，但访问仅限于最近的256个街区（约50分钟）。但是，在某些情况下，访问较旧的块数据至关重要，尤其是对于跨链应用程序（需要经过证明的先前块的数据）和无状态客户端，这些客户会定期访问早期的块哈希。

该EIP扩展了可用于汇总和跨链应用程序的时间范围，使他们可以直接访问EVM中的历史数据，而无需外部收集。结果，这些解决方案变得更加强大和可持续。

EIP-7623：增加CallData成本

参考：EIP-7623

CALLDATA成本调节交易有效载荷的可用大小，在某些情况下可能很大（例如，将大阵列或二进制缓冲区作为参数作为参数）。大量的CALLDATA使用主要归因于汇总，该汇总通过包含当前汇总状态的CallData发送有效载荷。

将大型，经过验证的二进制数据引入区块链对汇总至关重要。 Dencun（Deneb-Cangun）升级对此类用例 - BLOB交易（EIP-4844）引入了重要的创新。 Blob交易具有自己的特殊“ Blob”汽油费。尽管他们的主题是暂时存储的，但其加密证明（KZG Promise）及其哈希的共识层集成在一起。因此，BLOB提供了比使用CallData存储数据更好的汇总解决方案。

鼓励汇总将其数据传输到斑点。这可以通过“胡萝卜和粘着”来实现。减少的BLOB气费用用作“胡萝卜”，这种EIP通过将CallData成本提高作为“杠杆”来抑制交易中的过多数据存储。该EIP补充了下一个EIP-7691（增加的斑点吞吐量），这增加了每个块允许的最大斑点数量。

EIP-7691：斑点吞吐量增加

参考：EIP-7691

斑点是在先前的Dencun Hard Fork中引入的，斑点“每个块”的最大值和目标数的初始值是保守的估计值。这是由于预测P2P网络将如何处理验证器节点之间大型二进制对象的传播的复杂性。事实证明，先前的配置已使其成为测试新值的合适时机。以前，将每个块目标/最大斑点数设置为3/6。这些限制现在分别提高到6/9。

结合以前的EIP-7623（增加CallData成本），此调整进一步激发了汇总，以将其数据从Calldata传输到Blobs。寻找最佳斑点参数的工作仍在继续。

EIP-7840：将BLOB时间表添加到EL配置文件

参考：EIP-7840

该EIP提议将目标和最大“每块”斑点计数（前面讨论）和basefeeupdateFraction值添加到以太坊执行层（EL）配置文件。它还使客户可以通过节点API检索这些值。此功能对于诸如估计斑点气成本等任务特别有用。

EIP-7702：设置EOA帐户代码

参考：EIP-7702

这是一个非常重要的EIP，它将为以太坊用户带来重大变化。如我们所知，EOA（外部拥有帐户）不能具有任何代码，但可以提供交易签名（TX.origin）。相比之下，智能合约具有字节码，但不能主动提出“ IT”的直接签名。任何需要额外，自动和可验证逻辑的用户交互当前只能通过调用外部合同来执行所需的操作。但是，在这种情况下，外部合同将成为后续合同的味精，导致“合同的呼叫，而不是用户的电话”。

此EIP引入了新的SET_CODE_TX_TYPE = 0x04事务类型（我们以前有旧的0x1交易，柏林和EIP-1559升级的新的0x02事务，以及在Dencun中引入的0x03 BLOB交易）。这种新的交易类型允许您为EOA帐户设置代码。实际上，它允许EOA“在其自己的EOA帐户中”执行外部代码。从外部角度来看，在交易过程中，EOA似乎从外部合同中“借用”代码并执行它。从技术上讲，这是通过在EOA地址的“代码”存储中添加特殊的授权数据元组来实现的（此“代码”存储在此EIP之前始终为EOA为空）。

当前，该EIP提出的新的0x04交易类型包含一个数组：

授权_list = [[chain_id，address，nonce，y_parity，r，s]，…]

每个元素允许帐户从指定地址（从最后一个有效的授权项目）使用代码。处理此类交易时，给定的EOA代码设置为特殊的0xEF0100 ||地址值（23个字节），地址指向带有所需代码的合同，||表示连接，而0xEF0100表示​​不能包括常规智能合约（根据EIP-3541）。这种魔术价值可确保该EOA不能被视为常规合同，也不能像常规合同一样称呼它。

当此EOA启动交易时，指定的地址将用于在EOA的上下文中调用相应的代码。尽管该EIP的完整实施细节尚不清楚，但可以肯定的是，它将带来重大变化。

一个主要的影响是直接从EOA进行多次数的能力。多个调用是DEFI的持续趋势，许多协议将此功能作为功能强大的工具（例如UNISWAP V4，Balancer V3或Euler V2）。使用此EIP，您现在可以直接从EOA启动多个呼叫。

例如，此新功能解决了defi中的一个常见问题：apenve（） + nothing（）需要两项独立交易的效率低下。该EIP允许常见的“预授权”逻辑，因此可以在单个交易中完成批准（x） +押金（x）。

能够“代表” EOA委托交易执行的另一个优点是赞助的概念。赞助是一项经常讨论且高度可取的功能，可帮助新用户进入以太坊。

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

当然，这种变化也引发了许多设计问题。一个问题是使用Chain_ID，它决定了相同的签名是否可以在多个网络上有效，具体取决于是否包含在签名中。另一个复杂的问题是使用目标代码的地址和嵌入实际字体模式之间的选择。这两种方法具有自己独特的特征和局限性。另外，使用Nonce在定义权限是“多功能”还是“单用途”中起关键作用。这些元素会影响功能和安全问题，包括批处理故障签名和易用性。 Vitalik在讨论（此处）的讨论中提出了这些问题，值得进一步探索。

值得注意的是，这种变化将影响以太坊的安全机制，TX.origin。有关此EIP实现的更多详细信息是必要的，但是看起来需要（tx.origin == msg.sender）的行为会改变。这项检查一直是确保味精的最可靠的方法。Sender是EOA，而不是合同。其他方法，例如检查ExtCodesize（要检查是否是合同），通常会失败并且可以绕过（例如，通过调用构造函数或在交易后在预定义的地址部署代码）。这些检查用于防止重新进入和闪电贷款攻击，但远非理想，因为它们也阻碍了与外部协议的整合。在此EIP之后，即使是可靠的要求（tx.origin == msg.sender）检查似乎已经过时了。必须通过删除这些检查来调整协议，因为“ EOA”和“合同”之间的差异将不再适用 - 现在每个地址可能都有相关的代码。

传统EOA和智能合约之间的分离仍然变得模糊。此EIP使以太坊更接近像TON这样的设计，每个帐户本质上都是可执行的代码。随着与协议的互动变得更加复杂，使用可编程逻辑来改善最终用户体验是这种发展的自然过程。

综上所述

布拉格/伊莱克特拉（Pectra）升级计划于2025年3月进行。最重要的计划更改包括：

如您所见，Pectra将对放入和共识层的最终用户体验以及执行层产生重大影响。尽管在此阶段我们无法通过代码详细分析所有这些更改，但由于开发仍在进行中，我们将在未来文章中介绍这些更新。