编译 ：吴说区块链
除了对原文的编译外，本文还补全介绍了原文未提及的 Pectra 其他 EIPs。
关键要点
Pectra 是以太坊的下一次重大升级，涉及执行层（Prague）和共识层（Electra）的变更。在经历了测试网Pectra升级的一波三折后，最终确定于5月7日10:05 UTC 附近激活 Pectra主网升级。
此次升级将对质押、Layer 2 可扩展性和用户体验（UX）进行关键改进，并为未来的变革奠定基础。
主要变化包括：提高验证者的质押上限、灵活的质押提款、账户抽象的增强以及增加 blob 吞吐量，以提升网络效率和安全性。
引言
距离「合并」（The Merge）已有 31 个月，距离「Shapella」升级 24 个月，距离「Dencun」升级 13 个月，以太坊即将迎来下一次重大升级 — — Pectra 硬分叉。
而在 Pectra 主网升级之前的测试网升级，可谓是一波三折。
Holesky 测试网的 Pectra 升级于 2 月 24 日 21:55 UTC 激活，不过由于客户端软件配置错误（Geth、Nethermind 和 Besu 的存款合约地址错误）而中断，导致链分叉。开发者讨论了通过大规模惩罚事件恢复网络的计划，旨在加速错误验证者的退出并实现网络最终确定性，直至 3 月 11 日才能实现最终化。
Sepolia 测试网的 Pectra 升级于 3 月 5 日按计划升级，由于自定义存款合约配置问题导致部分执行层（EL）客户端在区块中包含交易时出现异常，不过问题很快就得到修复，网络也实现最终化。
3 月 19 日，为了测试验证者退出，推出了新测试网 Hoodi，并于 3 月 26 日成功激活 Pectra 网络升级。
以太坊 Pectra 测试网的升级历经两月波折，为主网部署铺平道路，最终确定于 5 月 7 日 10:05 UTC 附近激活 Pectra 主网升级。
与以往的以太坊升级类似，Pectra 同时涉及执行层（EL）和共识层（CL）。其名称正体现了这一双重重点：Prague（布拉格）代表执行层升级，以纪念 Devcon 4 举办地；Electra（Electra 星）则象征共识层升级。
Pectra 是以太坊历史上涉及 EIP（Ethereum Improvement Proposals，以太坊改进提案）数量最多（11 个 EIPs）的硬分叉之一。它在去年的 Dencun 升级基础上进一步优化，旨在改善用户体验（UX）、优化验证者操作，并推动 Layer 2 扩展，预计将对以太坊生态系统产生深远影响。
本文我们将根据每个 EIP 所属领域进行归类划分，深入分析各项 EIP。
验证者和质押机制的改进
Pectra 通过三项主要 EIP 优化以太坊 PoS 系统中的验证者操作体验：
EIP-7251：提高最大有效余额（MaxEB）
目前，以太坊的质押机制限制单个验证者的有效质押上限为 32 ETH，这意味着独立质押者必须以 32 ETH 为单位进行质押，而超过该限额的奖励不会计入有效质押。
EIP-7251 提议将最大有效余额（MaxEB）提高至 2048 ETH，允许单个验证者的质押范围扩展至 32 至 2048 ETH，带来的影响包括：
-
提升质押灵活性：质押者可以将所有收益复投到有效质押余额中，而无需受限于 32 ETH 的倍数。例如，一个持有 33 ETH 的验证者，现在所有 33 ETH 都可以获得质押奖励，提高资金效率和灵活性。
-
减少验证者数量：目前以太坊共有 105 万个活跃验证者，该 EIP 允许大型运营者合并其验证者，从而降低总数，减轻网络负担。
-
降低网络负载：尽管较多的验证者有助于去中心化，但也会增加带宽和计算负担。提高 MaxEB 可以优化验证者集，减少点对点通信的开销。
EIP-7002：执行层可触发提款
EIP-7002 进一步增强验证者功能，允许其通过执行层（0x01）提款凭证直接触发退出和部分提款。
目前，验证者有两个密钥：
1. 活动密钥，用于执行验证职责；
2. 提款密钥，用于访问和管理质押资金。
此前，只有活动密钥能触发退出，而提款密钥则无法自主操作。EIP-7002 允许提款密钥也能触发提款，这带来了：
-
更大的资金控制权：验证者可以直接管理资金，而无需依赖节点运营商。
-
支持完全去信任的质押池，提高安全性和去中心化程度。
EIP-6110：链上存储验证者存款
目前，当新验证者在执行层存款后，需要等待共识层识别并处理，导致激活延迟。
EIP-6110 允许执行层直接向共识层传递存款信息，减少额外的验证步骤，使验证者的激活时间从约 9 小时缩短至约 13 分钟。
提升 Layer 2 扩展能力：提高 Blob 吞吐量
EIP-7691：增加 Blob 吞吐量
去年 Dencun 升级引入了 Blobs，作为 Layer 2 rollups 存储数据的高效方式。目前，每天约有 2.1 万个 Blobs 在以太坊上提交，但容量已接近上限，导致费用上涨并限制了吞吐量。
当前，以太坊每个区块的目标 Blob 数量为 3 个，最大为 6 个。EIP-7691 提议将其目标值提高至 6，最大值提高至 9，以增加数据存储容量，提高吞吐量和可扩展性。这将降低数据存储成本，从而减少 L2 交易费用。
EIP-7623：提高 calldata 成本
在 Blob 机制推出之前，L2 主要使用 calldata 存储数据，并在某些情况下仍然沿用，因为它可能更具成本效益。EIP-7623 提高 calldata 费用，以激励 L2 主要使用 blob 存储数据，从而提升 rollup 交易效率。
用户体验（UX）增强
EIP-7702：设置 EOA 账户代码
核心思想：临时赋予 EOA 智能合约能力
EIP-7702 引入了一种全新的交易类型（标识为 0x04），允许外部拥有账户（EOA）在执行一笔交易期间，临时获得智能合约的功能。也就是说，虽然传统上 EOA 是没有代码的，仅能用来签名交易，但通过这个提案，EOA 可以在一笔交易里「加载」一段代码，从而像智能合约钱包一样执行复杂操作。
主要优势
-
批量操作：用户可以在一笔交易内完成多个操作（例如 approve + deposit 组合），避免了需要多笔交易的低效问题。
-
Gas 赞助：这种机制还能支持第三方赞助交易费用，改善用户体验，让用户无需预先持有 ETH 即可操作。
-
安全性与灵活性提升：用户可以对交易进行细粒度的权限控制，比如仅允许子账户在限定条件下操作，增强了账户安全性。
可能面临的挑战
-
生态兼容性问题：由于 EOA 传统上被认为没有代码，一些现有的智能合约或安全检查（例如 require(tx.origin == msg.sender)）可能需要调整以适应这种临时赋予代码的机制。
-
交易结构复杂性增加：新交易类型的引入会使钱包和客户端需要进行较大改动，确保在处理新的授权元组和临时代码设置时不会出现安全漏洞或额外的高成本。
EIP-7702 允许普通 EOA 在单笔交易中临时获得智能合约功能，从而支持批量交易、交易赞助以及更灵活的权限管理。这一机制可以极大改善用户体验和扩展 dApp 功能，但也会打破一些传统假设，需要生态各方适配更新。总体来说，这是一项为账户抽象铺路的重要提案，目标是让未来的以太坊账户既安全又更灵活。
其他 EIPs
EIP-7685：通用执行层请求
背景与目的
当前，Eth1（执行层）和信标链（共识层）之间需要处理三种主要请求：
-
存款：用户发起的存款事件最初出现在 Eth1 区块里，但最终需要在信标链上处理。
-
取款：从信标链发出的取款请求（通常通过命令行工具）则需要在 Eth1 上处理。
-
验证者合并：同样，这种请求也需要在 Eth1 和信标链之间传递。
为什么需要这个提议
目前不同类型的操作分别在两个层之间来回传递，容易造成混乱。EIP-7685 提出的统一处理框架，旨在：
-
用一种标准的方法处理所有这些请求，使得流程更清晰、效率更高；
-
仅依靠 Eth1 触发这些操作，这样可以把验证者的运行环境和质押管理分开，从而提高安全性。
主要内容
-
请求类型标识：为每种操作定义了特定的标识，比如已有的存款和取款请求类型，现在还要增加合并请求类型。
-
完整性保障：会采用一些机制（如哈希校验、默克尔化数据）来确保请求数据的完整性和安全。
-
处理队列与限速：针对待处理的请求会设定一些限制（比如同时等待的存款、取款或合并请求的数量），防止系统过载。
最终意义
对于普通用户和开发者来说，这意味着以后无论是发起存款、取款还是验证者合并的操作，都能通过一个统一的、标准化的流程更快、更安全地完成。这不仅提高了系统的效率，也有助于降低整体风险。
EIP-2537：BLS12–381 曲线操作的预编译
核心目的
这个提案在以太坊中加入了内置功能（称为预编译合约），专门用于处理 BLS12–381 曲线上的数学运算。
为什么需要这个预编译
-
效率提升：在智能合约中直接实现复杂的椭圆曲线运算（如签名验证和聚合）会消耗大量 gas。预编译合约可以大幅降低这些运算的成本。
-
更高安全性：相比当前使用的 BN254 曲线（安全性大约 80 位），BLS12–381 曲线提供约 120 位的安全性，使得加密操作更安全。
主要用途
-
BLS 签名验证：BLS 签名允许将多个签名聚合为一个，从而大幅减少验证时的计算量。
-
zkSNARK 证明验证：在一些隐私保护和可扩展性方案中，需要验证 zkSNARK 证明，而这些操作也依赖于复杂的椭圆曲线计算。
实际意义
通过这个 EIP，开发者可以在智能合约中更高效、低成本地使用 BLS12–381 曲线相关的加密运算，从而支持更多创新应用，比如更高效的共识机制、跨链交互和各种去中心化应用。
简而言之，EIP-2537 就是为了解决在链上进行高安全性加密运算时消耗过多 gas 的问题，通过预编译合约让这些复杂运算变得更加高效和实用。
EIP-2935：在状态中保存历史区块哈希
当前问题
在以太坊虚拟机（EVM）中，通过 BLOCKHASH 操作码只能查到最近 256 个区块的哈希（大约 50 分钟内的），这对于某些应用来说不够用，比如需要证明更早区块数据的跨链应用或者无状态客户端（如 rollup）。
提案的核心
EIP-2935 提议在区块链的状态中额外保存 8192 个区块的哈希（约 27.3 小时内的），这样可以大大扩展可供查询的历史区块数据范围。
如何实现
除了保持现有 BLOCKHASH 操作码仅能访问最近 256 个区块外，提案还会引入一个专门的新系统合约：
-
set() 方法：在每个区块被处理时，新合约会自动将当前区块哈希存入一个环形缓冲区。
-
get() 方法：任何人或智能合约都可以通过这个方法查询存储在环形缓冲区里的历史区块哈希。
实际好处
这样一来，跨链应用、rollup 或其他需要访问较早区块数据的系统，就能直接在链上获取所需的历史信息，无需额外依赖外部数据，这使得它们的设计更加简单、安全和可靠。
EIP-7840：将 blob 调度添加到 EL 配置文件
核心目的
这个提案旨在把有关 blob 调度的关键参数（例如每个区块允许的 blob 数量和基础手续费更新比例）写进执行层（EL）的配置文件中。
具体做法
-
在配置文件中添加「目标 blob 数量」和「最大 blob 数量」的设置。
-
同时加入一个叫 baseFeeUpdateFraction 的参数，用来调节基础手续费的更新速度。
-
客户端可以通过节点 API 查询这些参数，从而知道当前网络对 blob 的具体配置。
为什么有用
这些信息能帮助开发者和节点运营者更准确地估算 blob gas 费用，也有助于网络更好地管理区块中大数据的调度和处理。
总的来说，EIP-7840 为以太坊执行层增加了一套可配置的 blob 调度参数，使网络在处理大数据（blob）时更高效、更透明。
EIP-7549：将委员会索引移出证明
核心想法
目前，验证投票（Attestation）消息里包含三个部分：
-
LMD GHOST 投票（包含区块根和时隙）
-
Casper-FFG 投票（包含 source 和 target）
-
委员会索引（index）
问题在于，委员会索引也被签名了，这会导致即使投票内容相同，但由于索引不同，生成的签名根也不同。这会使得同样内容的投票无法被聚合在一起。
EIP-7549 提出的解决办法是：将委员会索引从被签名的投票消息中移除。这样，只有投票的核心内容（LMD GHOST 和 Casper-FFG 投票）会参与签名计算，允许相同投票的多个验证者产生相同的签名根，从而可以聚合在一起。
主要好处
-
大幅降低验证工作量：现有情况下，为了达到 2/3 共识，可能需要验证 1366 条投票。移除委员会索引后，只需验证大约 22 条投票（节省了约 62 倍的计算量），这对于需要大量配对运算的验证过程来说，效率提升非常显著，尤其是对于基于零知识证明的 Casper FFG 客户端。
-
提高链上数据存储效率：由于投票信息可以更高效地聚合，能够在每个区块中打包更多的投票。现在一个区块只能包含 2 个时隙的投票，改进后能达到最多 8 个时隙的投票，即使只有 1/8 的提议者在线，也能把所有投票都包含在区块中。
通过将委员会索引从 Attestation 消息中移出，不仅可以极大地减少验证投票时需要处理的配对运算数量，而且能更高效地打包投票数据，提升整个共识验证过程的性能和链上存储利用率。这项改进对于 Casper FFG 共识机制及其相关的零知识证明验证尤为重要。
结论
Pectra 作为一次涵盖创纪录数量的 EIP 的升级，将推动以太坊在账户抽象、验证者机制优化、网络效率提升及 Layer 2 扩展等关键方向发展。同时，正如 Vitalik Buterin 近期所强调，以太坊虽然采用 Rollup 为中心的扩展路线，但仍在持续优化 Layer 1，例如最近将 Gas 限制提升至 3600 万，未来可能会进一步提升抗审查能力、吞吐量和可扩展性。
