以太坊Pectra升级:安全影响与洞察

  • Ackee
  • 发布于 2025-04-28 23:21
  • 阅读 19

文章介绍了以太坊计划于2025年5月7日进行的Pectra升级,该升级合并了执行层(Prague)和共识层(Electra)的改进,旨在提高网络的效率、速度和易用性。文章重点分析了Pectra升级中包含的各项EIP提案,包括历史区块哈希预编译、BLS12-381曲线预编译、EOA加载智能合约代码的新交易类型等,并从安全角度进行了评估。

以太坊期待已久的升级,名为 Pectra,终于确定了上线时间。Pectra 将于 2025 年 5 月 7 日在 epoch 364032 激活,大约在 UTC 时间 10:05:11。自 2024 年 3 月以来,已经过去一年多的时间了,当时交付了一个名为 Dencun 的重要可扩展性升级。它最著名的改进 L2 可扩展性的变化是使用 Blobs 的 Proto-Danksharding(EIP-4844)。

Pectra 硬分叉的目标是什么?

从安全角度来看,情况如何?

它将带来的改进的细节是什么?

让我们来了解一下。

Pectra 的演变

自 2022 年的 Merge 以来,以太坊对共识层(CL,使用 PoS 确保共识)和执行层(EL,持有状态并处理交易)的升级正在同时进行。这也在升级命名中有所体现。Pectra 是以下单词的组合:

  • Prague – EL 升级的名称(以 Devcon 城市命名);
  • Electra – CL 升级的名称(以天体恒星命名)。

在 Pectra 的最完整版本中,提议了 24 个以太坊改进提案(EIP)被包含,但范围缩小了一半以上,减少到 11 个 EIP。其余的 EIP,包括两个引起共鸣的提案,PeerDAS(对等数据可用性采样)和 EOF(新的 EVM 对象格式),至少推迟到下一次名为 Fusaka 的升级,甚至更晚,但这还有待重新评估。

Pectra 中保留了什么?升级将带来什么?

Pectra 总结

以太坊 Pectra 升级通过改进钱包、验证者和智能合约,使网络更快、更高效、更易于使用。

由于范围缩小,Pectra 升级可以概括为以下五个要点:

  • 建立一个跨层系统(EIP-7685),将来自智能合约的请求传达给 CL 客户端,例如质押(EIP-6110)和存款(EIP-7002)。
  • 通过更安全的链上存款(EIP-6110)和提款(EIP-7002),以更灵活的增量和复合奖励进行质押(EIP-7251)。
  • 为 EOA 启用与 ERC-4337 兼容的智能账户(EIP-7702)。
  • 通过减少验证者数量(EIP-7251)、改进签名聚合和检查(EIP-7549)以及通过增加其目标值(EIP-7691)和增加 calldata 成本 (EIP-7623)来优先处理 blobs,从而提高以太坊的可扩展性。
  • 添加新的预编译,以实现更安全的链上 BLS 签名验证(EIP-2537)和检索最近的区块哈希以减少 CL 状态(EIP-2935)。

Pectra EIP 的安全角度

本节将通过 SC 审计专家的视角来检查影响 EL 层的改进。

EIP-2935 用于历史区块哈希的预编译

虽然此改进为 SC 层添加了一个任何人都可以使用的新系统合约,但其主要用例将在成功过渡到无状态客户端后变得可行。尚未提及的是,L2 rollups 可以通过直接查询此合约来受益于更长的历史窗口。

新的预编译对于利用 BLOCKHASH 操作码的协议或应用程序也可能有所帮助,例如,对于某些与时间相关的验证。该操作码只能访问最近的 256 个区块哈希,因此如果某些应用程序需要更旧的哈希,则可以利用新的预编译,最多可以访问 8192 个历史区块哈希。

此提案中的更改很简单,不会引入新的直接攻击向量。

EIP-2537 用于 BLS12-381 曲线的预编译

第二个预编译,它添加了可以对椭圆曲线执行的操作,对于利用零知识证明的以太坊 dApp 很有帮助(例如,zkEmail)。零知识对于提高安全性、隐私性或改进扩展(正如我们在 ZK rollups 中看到的那样)可能是有益的。

如前所述,此预编译中的操作将提供 120+ 位的安全性,这意味着输入和输出是可变的。这种可变性在 gas 计算中得到了充分缓解。由于此 EIP 还包含有关如何有效地实现曲线运算和处理边缘情况的详细信息,因此潜在的拒绝服务(DoS)或其他攻击向量的可能性很小。

EIP-7702 用于将 SC 代码加载到 EOA 中的新交易类型

此 EIP 带来了多年来最具影响力的 UX 改进。以太坊最初的愿景是创建一个 SC 平台,所有帐户都作为具有可编程逻辑的 SC 运行。但是,为了便于实现,EOA 早期被引入作为启动交易的唯一方式,这给采用该技术的新用户带来了最大的使用困难(如种子或 gas 支付)。

此更改带来了许多引人入胜的好处:

  • 现有的 EOA 作为 SA – 不仅新钱包可以使用 SA(如ERC-4337),而且现有的 EOA 也可以通过新的委托交易转换为 SA。这种转换的可能性令人兴奋,因为减慢 SA 采用速度的主要因素是创建新钱包的要求。

  • 基础设施重用–EOA 可以将代码委托给 ERC-4337 智能钱包,以利用围绕它构建的现有架构。

  • 部署效率– 多个 EOA 可以委托给完全相同的(经过审计的)实现,从而减少已经很陡峭的状态增长并简化部署。

  • 变形– 该交易的设计使得 EOA 可以随时更改其实现或委托给零地址以删除配置的委托。

另一方面,此更改带来了一些不可否认的安全风险:

  • 安全委托

委托合约必须实施强大的安全措施,并且理想情况下应由独立的审计进行验证。这些措施包括重放保护,并且需要帐户授权机构对涉及价值、gas、目标和 calldata 的关键操作进行签名。否则可能会使恶意行为者能够访问所有用户资金,甚至几乎完全控制用户的 EOA。这就是为什么用户在签署此类交易时必须特别关注他们委托给哪个合约。

利用网络钓鱼或伪装技术的恶意协议的可能攻击场景可能如下所示:

  1. 在典型的交互(例如,代币交换)期间,向用户建议签署到 SC(由恶意协议控制)的委托交易。
  2. 该交易试图看起来像常规交易。
  3. 用户没有意识到该交易不安全并签署了它。
  4. 该协议使用委托的 SC 控制用户的 EOA 和所有资产。

钱包提供商必须缓解此攻击场景。他们应谨慎实施此新功能,并在签署委托交易时高亮显示潜在风险。最好还能看到有关目标 SC 的最新审计的一些信息,甚至可以利用链上审计表示(EIP-7512)。

  • 破坏 tx.origin 不变性

EOA 可以委托给 SC,然后调用自身的方法,从而有效地调用 SC 的方法。tx.origintx.sender 在此调用中是相同的,这也会传播到嵌套调用。一方面,这使得批量处理交易成为可能。另一方面,它使依赖 require(tx.origin == msg.sender) 的重入检查和原子三明治保护可以通过这种精确的技术来利用。尽管利用 tx.origin 的保护并不常用,但是这种漏洞可能会在已部署的协议上使用。除了将这些协议迁移到不需要保护或以不同方式存档的新版本之外,没有其他解决方法。

  • 抢跑初始化 与传统的合约部署相比,委托给 SC 不会初始化存储,因为构造函数没有被调用。这使得委托容易受到抢跑初始化的影响,可以通过以下方式实现:
  1. 用户将委托交易发送到未正确保护初始化或包含未检查是否已完成初始化的易受攻击方法的 SA。
  2. 由于未调用构造函数,用户的 EOA 处于未初始化状态。
  3. 恶意行为者可以调用初始化方法或用户 EOA 上的易受攻击方法,从而获得优于用户帐户的优势。

SA 开发人员必须通过在每个(可能容易受到攻击的)方法中执行初始化检查并确保初始化只能由 EOA 所有者执行来缓解此攻击场景。

EIP-7685 SC 对 CL 的请求(EIP-7002 提款,EIP-6110 存款)

乍一看,SCs 对 CL 请求的新通信通道可能看起来像是一个新的漏洞利用领域。但是由于 CL 和 EL 需要能够独立运行,因此这些请求不会立即处理。但是,它们会在未来的某个时间(取决于请求)在未指定的时间范围内处理。这意味着请求(提款/存款)的结果不是同步可用的,而是在某些后续调用中可用,这使得它不可组合并且难以用于任何漏洞利用场景。

由于这些 EIP 向 SC 层引入了新功能,因此无需担心现有协议处理链下存款/提款会被此特定协议更改所利用。相反,他们可以将他们的逻辑迁移到链上,从而为用户提供更高的透明度、安全性和去中心化。

由于此 EIP 还包含有关如何定价提款和存款请求的详细的 gas 计算,因此潜在的 DoS 可能性也很小。

仔细研究 EIP

Pectra 升级(EIP-7600)将包括以下 11 个 EIP:

计划纳入

EIP-2935 用于历史区块哈希的预编译

添加一个新的预编译,用于返回最新的 8192 个区块哈希。这种向无状态客户端的改变将允许 CL 客户端从 EL 客户端加载区块哈希。在当前实现中,EVM 假定 CL 客户端可以访问最近的区块,这对于以太坊的无状态扩展愿景来说不是面向未来的。

EIP-2537 用于 BLS12-381 曲线的预编译

添加一个新的预编译,具有 120+ 位的安全性,用于在链上验证 BLS 签名。现有的 BLS 预编译仍然存在,但仅提供 80 位的安全性。

EIP-7685 通用执行层请求

添加一个新的通信通道,允许将请求从 SC 直接发送到 CL。此通道使 SC 能够控制验证者存款(EIP-6110)、提款(EIP-7002)以及将来的任何其他内容,因为通信格式非常开放。目前,只能通过链下服务(或人工)将请求从 SC 发送到 CL 以控制权益,该服务收集并将链上请求转发到 CL。此更改将启用完全由 SC 控制的验证者 – 简化交易所和协议(例如,Lido)与存款交互的过程,同时通过去中心化使其更安全。

EIP-6110 链上验证者存款

将权益存款的责任从 CL 转移到 EL。此更改使存款处理更安全,并将其从当前的 13 小时加快到 12 分钟。它还弃用了存款投票(CL 中的其他验证者投票以接受新的验证者)和用于存储此数据的相关 Eth1Data 轮询,从而简化了 CL 实现。

EIP-7002 链上验证者提款

将提款存款的责任从 CL 转移到 EL。与上一个类似,此更改使该过程更安全。它将提取已存入的 Ether 的权利从验证者转移到 Ether 所有者,而在现实世界中,以太币所有者可以是不同的实体(通常是)。这使得存款无需信任,因为资金所有者可以随时提取资金,而无需验证者的批准。

EIP-7251 增加 MAX_EFFECTIVE_BALANCE

将有效余额(用于奖励计算的基本值)从 32 Ether 增加到 2048 Ether。此更改的主要动机是将验证者的数量减少多达 64 倍(对应于有效余额的 64 倍增加)。此改进的动机是以太坊扩展愿景从 64 个单独的分片链转变为利用 Danksharding 进行 rollup 扩展,并通过无状态客户端进行数据可用性采样。它通过减少投票开销和启用复合奖励来使整个网络受益。它还允许大型验证者将权益合并到更少的验证者中,从而减少基础设施要求并允许小型参与者以更灵活的增量进行质押。

EIP-7549 将委员会索引移到证明之外

将委员会索引(验证者组的标识符)移到已签名的证明(证明区块有效性的消息)之外。此更改允许更有效地聚合证明,这意味着必须验证更少的签名才能达成共识。

EIP-7702 用于将 SC 代码加载到 EOA 中的新交易类型

添加一种新的交易类型,用于将代码添加到发送 EOA。可以加载到 EOA 的代码仅限于指向地址的指针。成功验证交易后,EOA 将表现得好像指向地址上的 SC 代码原生存在于 EOA 中一样。此行为将持续到 EOA 通过新交易更改为不同的地址或零地址以删除代码为止。此更改为以太坊带来了期待已久的账户抽象,从而可以实现 EOA 到智能账户(SA)的转换,并使自定义安全规则、gas 支付委托或交易批处理等功能成为可能。这种方法的一个显着优势是它与 ERC-4337 兼容,后者是当前使用的 SA 标准,近年来已开发出基础设施和钱包。

EIP-7623: 增加 Calldata 成本

提高交易的 calldata 的 gas 成本,该交易在 EVM 操作上花费的 gas 不超过某个阈值。主要目标是使 L2 使用 calldata 进行数据可用性(DA)的交易更加昂贵,以激励它们使用 blobs(首选方式)并减少空间增长。

EIP-7691: Blob 吞吐量增加

将目标 blobs 翻倍(3 → 6)并增加最大 blobs(6 → 9),从而扩展以太坊上的Layer2容量。将目标到最大比率从 1/2 更改为 2/3,以实现更灵敏的费用:当区块已满时,基本费用增加 8.2%(之前为 12.5%),当区块为空时,基本费用减少 14.5%(之前为 11.1%),从而优化数据可用性定价。

EIP-7840: 将 blob 计划添加到 EL 配置文件

引入“blobSchedule”配置对象,以 JSON 格式存储不同网络分叉的 blob 参数(目标、最大值、基本费用分数)。用外部配置替换执行客户端中的硬编码常量,从而能够根据活动分叉版本自动应用参数。

  • 原文链接: ackee.xyz/blog/ethereums...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Ackee
Ackee
Cybersecurity experts | We audit Ethereum and Solana | Creators of @WakeFramework , Solidity (Wake) & @TridentSolana | Educational partner of Solana Foundation