当前位置：比特中国 > 资讯 >

ETH向“无限扩展”迈出的最重要一步

来源： www.hsdll.com时间：2025-12-09 14:36

计划于 2025 年 12 月 3 日激活的 Fusaka 硬分叉是ETH继 Pectra 之后的又一次重大互联网升级，标志着这家加密巨头又向扩容迈出了要紧一步。

Pectra 升级的 EIP 专注于提高性能、安全性和开发者工具。Fusaka 升级的 EIP 则重视扩容、操作码更新和实行安全性等方面。

其他增强功能包含限制 RLP 格式的区块大小 (EIP|7934)、添加新的 CLZ 操作码以加快位操作速度 (EIP|7939)，与引入 secp256r1 预编译 (EIP|7951) 以更好地兼容现代密码学和硬件安全密钥。

Fusaka 是 Fulu（实行层）和 Osaka（共识层）的组合名字。它代表着ETH向高度可扩展、数据丰富的将来迈出的又一步，在这个将来中，Layer 2 Rollup 可以以更低的本钱和更快的速度运行。

本篇文章将深入分析 Fusaka 硬分叉的9大核心 EIP 提案。

EIP|7594：PeerDAS ——节点数据可用性采样

ETH需要这项提案，由于互联网期望为用户（特别是 Rollup 用户）提供更高的数据可用性。

然而，在目前的 EIP|4844 设计下，每一个节点仍然需要下载很多的 blob 数据才能验证其是不是已发布。这导致了扩展性问题，由于假如所有节点都需要下载所有数据，互联网的带宽和硬件需要就会增加，去中心化程度也会遭到影响。为知道决这个问题，ETH需要一种办法，让节点不需要下载所有数据即可确认数据是不是可用。

数据可用性采样 (DAS) 通过允许节点仅检查少量随机数据来解决这个问题。

但ETH还需要一种与现有 Gossip 互联网兼容的 DAS 办法，并且不会给区块生产者增加繁重的计算负担。PeerDAS 的创建正是为了满足这类需要，并在维持节点需要较低的状况下安全地提升 blob 吞吐量。

PeerDAS 是一种互联网系统，它允许节点仅下载少量数据片段来验证完整数据是不是已发布。节点不需要下载全部数据，而是借助常规的 gossip 互联网共享数据，发现什么节点持有特定部分的数据，并仅请求所需的小样本。其核心思想是，通过仅下载数据片段中随机的小部分，节点仍然可以确信整个数据片段的存在。比如，节点可能只下载大约 1/8 的数据，而不是下载完整的 256 KB 数据片段——但因为很多节点会采样不一样的部分，因此任何缺失的数据都会非常快被发现。

为了达成采样，PeerDAS 用一种基本的纠删码对 EIP|4844 中的每一个数据片段进行扩展。纠删码是一种添加额外冗余数据的技术，即便某些数据片段缺失，也能恢复原始数据——像拼图即便丢失几块也能拼完整。

blob 会变成一个“行”，其中包括原始数据与一些额外的编码数据，以便后续可以重建数据。然后，这一行会被分割成很多称为“单元格”的小块，单元格是与 KZG 承诺关联的最小验证单元。所有“行”随后会被重新组织成“列”，每列包括来自所有行的相同地方的单元格。每列都被分配到一个特定的 gossip 子网。

节点负责依据其节点 ID 存储某些列，并在每一个时隙从对等节点采样一些列。假如一个节点采集到至少 50% 的列，它就能完全重建数据。假如采集到的列少于 50%，它需向对等节点请求缺失的列。这确保了假如数据确实已发布，则一直可以重建。简而言之，假如总共有 64 列，一个节点仅需大约 32 列即可重建完整的 blob。它自己保留一些列，并从对等节点下载一些列。只须互联网中存在一半的列，节点就能重建所有内容，即便某些列缺失。

除此之外，EIP|7594 还引入了一条要紧规则：任何买卖都不可以包括超越 6 个 blob。此限制需要在买卖验证、gossip 传播、区块创建和区块处置期间强制实行。这能够帮助降低单个买卖致使 blob 系统过载的极端状况。

PeerDAS 添加了一种称为“单元 KZG 证明”的功能。单元 KZG 证明表明 KZG 承诺确实与 blob 中的一个特定 cell（一小单元）匹配。这致使节点可以仅下载它想要采样的 cell。在保证数据完整性的首要条件下，获得完整的 blob，这对于数据可用性采样至关要紧。

但，生成所有这类单元证明的本钱非常高。区块生产者需要对很多 blob 反复计算这类证明，这致使速度太慢。不过，证明验证的本钱很低，因此，EIP|7594 需要 blob 买卖发送者预先生成所有单元证明，并将它包括在买卖包装器中。

正因这样，买卖 gossip（PooledTransactions）目前用了一个修改后的包装器：

rlp([tx|payload|body, wrapper|version, blobs, commitments, cell|proofs])

PeerDAS 使ETH可以在不增加节点工作量的状况下提升数据可用性。现在，一个节点仅需采样大约 1/8 的总数据。将来，这一比率甚至可能降至 1/16 或 1/32，从而提高ETH的可扩展性。该系统运行好，由于每一个节点都拥有海量对等节点，因此，假如某个对等节点没办法提供所需数据，该节点可以向其他对等节点请求。这自然地打造了冗余机制，并提升了安全性，节点还可以选择存储超出实质需要的数据，这进一步增强了互联网的安全性。

验证节点比普通全节点承担更多责任。因为验证节点本身运行着性能更强的硬件，PeerDAS 会依据验证节点的总数，为其分配相应的数据推广托管负载。这确保一直有稳定的节点组可用于存储和共享更多数据，从而提高互联网的靠谱性。简而言之，假如有 90 万个验证节点，则每一个验证节点可能被分配一小部分总数据进行存储和服务。因为验证节点拥有更强大的机器，互联网可以信赖它们可以确保数据的可用性。

PeerDAS 用列采样而非行采样，由于如此可以大大简化数据重建。假如节点对整行（整个 blob）进行采样，则需要创建原本没有的额外“扩展 blob”，这会减慢区块生产者的速度。

通过列采样，节点可以预先筹备额外的行数据，并且由买卖发送者（而非区块生产者）计算必要的证明。这可以维持区块创建的速度和效率。比如：假设一个 blob 是一个 4×4 的单元格网格。行采样意味着从一行中取出所有 4 个单元格，但某些扩展行尚未筹备就绪，因此区块生产者需要现场生成它们；列采样则是从每一行（每一列）中抽取一个单元格，重建所需的额外单元格可以预先筹备好，如此节点就能在不减慢区块生成速度的状况下验证数据。

EIP|7594 与 EIP|4844 完全兼容，因此不会破坏ETH上的任何现有功能。所有测试和详细规则都包括在共识和实行规范中。

任何 DAS 系统的主要安全风险是“数据隐瞒攻击”，即区块生产者假装数据可用，但事实上隐藏了部分数据。PeerDAS 通过用随机抽样来预防这样的情况：节点检查数据的随机部分。抽样的节点越多，攻击者就越难作弊。EIP|7594 甚至提供了一个公式，可以参考节点总数 (n)、样本总数 (m) 和每一个节点的样本数 (k) 来计算此类攻击成功的可能性。在拥有约 10,000 个节点的ETH主网上，攻击成功的概率极低，因此 PeerDAS 被觉得是安全的。

EIP

EIP|7823：为 MODEXP 设置 1024 字节上限

这项提案的必要性在于，ETH目前的 MODEXP 预编译机制多年来致使了很多共识漏洞。这类漏洞大多来自于 MODEXP 允许输入数据量极其庞大且不切实质，致使推广客户端需要处置无数异常状况。

因为每一个节点都需要处置买卖提供的所有输入，因此没上限致使 MODEXP 更难测试、更容易出错，并且更容易在不一样的推广客户端上表现不同。过大的输入数据也致使 gas 本钱公式很难预测，由于当数据量可以无限增长时，非常难对其进行定价。这类问题也致使将来用 EVMMAX 等工具将 MODEXP 替换为 EVM 级别的代码变得困难，由于假如没固定的限制，开发者就没办法创建安全且优化的实行路径。

为了降低这类问题并提升ETH的稳定性，EIP|7823 为 MODEXP 输入数据量添加了严格的上限，从而使预编译过程愈加安全、易于测试且更可预测。

EIP|7823 引入了一条简单的规则：MODEXP 用的所有三个长度字段（基数、指数和模数）都需要小于等于 8192 位，即 1024 字节。MODEXP 输入遵循 EIP|198 中概念的格式：<len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS>，因此该 EIP 仅限制长度值。假如任何长度超越 1024 字节，预编译将立即停止，返回错误并消耗所有 gas。

比如，假如有人尝试提供一个 2000 字节长的基数，则调用将在任何工作开始之前失败。这类限制仍然可以满足所有实质应用场景。RSA 验证一般用 1024 位、2048 位或 4096 位等密钥长度，这类长度都在新限制范围内。椭圆曲线运算用更小的输入大小，一般小于 384 位，因此也不受影响。

这类新的限制也能够帮助将来的升级。假如将来用 EVMMAX 将 MODEXP 重写为 EVM 代码，开发者可以为容易见到的输入大小（比如 256 位、381 位或 2048 位）添加优化路径，并为罕见状况用较慢的回退策略。通过固定最大输入大小，开发者甚至可以为很容易见到的模数添加特殊处置。此前，因为输入大小不受限制，设计空间过于庞大，很难安全管理，因此这类都没办法达成。

为了确认此更改不会破坏过去的买卖，作者剖析了从区块 5,472,266（2018 年 4 月 20 日）到区块 21,550,926（2025 年 1 月 4 日）的所有 MODEXP 用状况。结果显示，历史上所有成功的 MODEXP 调用都没用过超越 513 字节的输入，远低于新的 1024 字节限制。大部分实质调用都用了较小的长度，比如 32 字节、128 字节或 256 字节。

存在一些无效或损毁的调用，比如空输入、填充了重复字节的输入，与一个很大但无效的输入。这类调用在新限制下的行为也是无效的，由于它们本身就是无效的。因此，虽然 EIP|7823 在技术上是一个重大变更，但事实上它不会改变任何过去买卖的结果。

从安全角度来看，降低允许的输入大小并不会带来新的风险。相反，它消除去之前致使推广客户端之间出现错误和不同的非必要极端状况。通过将 MODEXP 输入限制在适当的大小范围内，EIP|7823 使系统更具可预测性，降低了奇怪的极端状况，并减少了不同达成之间出错的概率。这类限制也能够帮助做好筹备，假如将来的升级（比如 EVMMAX）引入了优化的实行路径，则该系统可以达成更平滑的过渡。

EIP|7825：买卖 1670 万 Gas 上限

ETH确实也需要这项提案，由于现在单笔买卖几乎可以消耗整个区块的 Gas 上限。

这会导致几个问题：一笔买卖可能消耗掉区块的大多数资源，致使类似 DoS 攻击的缓慢延迟；耗费很多 Gas 的操作会过快地增加ETH的状况更新；区块验证速度变慢，节点很难跟上。

假如一个用户提交了一笔几乎消耗所有 Gas 的巨额买卖（比如，一笔在 4000 万 Gas 的区块中消耗 3800 万 Gas 的买卖），那样其他普通买卖就没办法放入该区块，每一个节点都需要花费额外的时间来验证该区块。这会威胁到互联网的稳定性和去中心化，由于验证速度变慢意味着性能较弱的节点会落后。为知道决这个问题，ETH需要一个安全的 Gas 上限，限制单笔买卖可以用的 Gas 数目，从而使区块负载愈加可预测，减少 DoS 攻击的风险，并使节点的负载愈加均衡。

EIP|7825 引入了一条硬性规则：任何买卖消耗的 Gas 不能超越 16,777,216 (2²⁴)。这成为协议层面的上限，意味着它适用于所有环节：用户发送买卖、买卖池检查买卖与验证者将买卖打包进区块。假如有人发送的 Gas 上限超越此值，推广客户端需要立即拒绝该买卖，并返回类似 MAX|GAS|LIMIT|EXCEEDED 的错误。

此上限与区块 Gas 上限完全独立。比如，即便区块 Gas 上限为 4000 万，任何单笔买卖的 Gas 消耗也不能超越 1670 万。其目的是确保每一个区块可以容纳多笔买卖，而不是让单笔买卖占据整个区块。

为了更好地理解这一点，假设一个区块可以容纳 4000 万 Gas。假如没此上限，有人或许会发送一笔消耗 3500 万到 4000 万 Gas 的买卖。该买卖会垄断区块，不给其他买卖留下任何空间，就像一个人包下整辆巴士，别的人都没办法上车一样，新的 1670 万 Gas 上限将使区块自然容纳多笔买卖，从而防止此类滥用行为。

该提案还对推广客户端怎么样验证买卖提出了具体需要。假如买卖的 Gas 超越 16,777,216，买卖池需要拒绝该买卖，这意味着此类买卖甚至不会进入队列。在区块验证过程中，假如区块中包括超越上限的买卖，则该区块本身需要被拒绝。

选择 16,777,216 (2²⁴) 这个数字是由于它是一个明确的 2 的幂次方边界，便于达成，而且它仍然足够大，可以处置大部分实质买卖。比如智能合约部署、复杂的 DeFi 交互或多步骤合约调用。这个值大约是典型区块大小的一半，这意味着即便是最复杂的买卖也能轻松控制在这个限制范围内。

这项 EIP 也维持了与现有 Gas 机制的兼容性。大部分用户不会注意到这一变化，由于几乎所有现有买卖消耗的 Gas 都远低于 1600 万。验证者和区块创建者仍然可以创建总 Gas 超越 1670 万的区块，只须每笔买卖都遵守新的上限即可。

唯一受影响的买卖是之前试图用超越新限制的超大买卖。这类买卖目前需要拆分成多个较小的操作，像将一个很大的文件上传拆分成两个较小的文件。从技术上讲，这项更改对于这类罕见的极端买卖并不向下兼容，但预计受影响的用户数目将很少。

在安全性方面，Gas 上限使ETH更能抵御基于 Gas 的 DoS 攻击，由于攻击者没办法再强迫验证者处置超大买卖。它还能够帮助维持区块验证时间的可预测性，从而使节点更容易维持同步。主要极端状况是，少数规模很大的合约部署可能没办法满足上限需要，需要重新设计或拆分为多个部署步骤。

总体而言，EIP|7825 旨在加大互联网防范滥用，维持节点需要合理，提升区块空间用的公平性，并确保伴随 Gas 上限提升，区块链仍能维持迅速稳定运行。

EIP|7883：ModExp Gas 成本上涨

ETH需要这项提案是什么原因，ModExp 预编译（用于模幂运算）的价格与其实质消耗的资源相比一直偏低。

在某些状况下，ModExp 操作所需的计算量远远超越用户现在支付的成本。这种不匹配会带来风险：假如复杂的 ModExp 调用价格过低，它们或许会成为瓶颈，使互联网很难安全地提升 Gas 上限。由于区块生产者可能被迫以极低的本钱处置极其繁重的操作。

为知道决这个问题，ETH需要调整 ModExp 的定价公式，使 Gas 消耗可以准确反映推广客户端实质完成的工作量。因此，EIP|7883 引入了新的规则，提升了最低 Gas 本钱、提升了总 Gas 本钱，并使输入数据量较大的操作（特别是超越 32 字节的指数、底数或模数运算）愈加昂贵，从而使 Gas 定价与实质所需的计算量相匹配。

该提案通过几个要紧方面提升了本钱，从而修改了刚开始在 EIP|2565 中概念的 ModExp 定价算法。

第一，最低 Gas 消耗从 200 提升到 500，并且总 Gas 消耗不再除以 3，这意味着总 Gas 消耗事实上增加了三倍。比如，假如之前一个 ModExp 调用需要消耗 1200 gas，那样在新公式下，它目前将需要消耗大约 3600 gas。

第二，指数大于 32 字节的运算本钱翻倍，这是由于乘数从 8 增加到了 16。举例来讲，假如指数长度为 40 字节，EIP|2565 会将迭代次数增加 8 × (40 − 32) = 64 次，而 EIP|7883 目前用 16 × (40 − 32) = 128 次，本钱涨了一倍。

第三，定价目前假定最小基数/模数大小为 32 字节，并且当这类值超越 32 字节时，计算本钱会急剧增加。比如，假如模数为 64 字节，则新规则应用双倍复杂度 (2 × words²)，而不是以前更简单的公式，从而反映了大数运算的实质本钱。这类更改一同确保了小型 ModExp 运算支付适当的最低成本，并且大型、复杂的运算的本钱会依据其大小进行适合的调整。

该提案概念了一个新的 Gas 计算函数，更新了复杂度和迭代次数规则。乘法复杂度目前对基数/模数长度低于 32 字节的状况用默认值 16，而对于更大的输入，则切换到更复杂的公式 2 × words²，其中“words”指的是 8 字节块的数目。迭代次数也进行了更新，致使 32 字节或更小的指数用其位长度来确定复杂度，而大于 32 字节的指数则会增加更大的 Gas 惩罚。

这确保了实质计算本钱非常高的超大指数目前具备更高的 Gas 本钱。关键的是，返回的最小 Gas 本钱被强制设置为 500，而不是之前的 200，这致使即便是最简单的 ModExp 调用也愈加合理。

这类价格上涨的动机来自于基准测试，该测试表明在很多状况下 ModExp 预编译的定价明显偏低。修订后的公式将小型操作的 Gas 成本提升 150%，典型操作提升约 200%，而大型或不平衡操作的 Gas 成本则提升更多倍，有时甚至超越 80 倍，具体取决于指数、底数或模数的大小。

此举的目的并不是改变 ModExp 的工作原理，而是为了确保即便在资源消耗最大的极端状况下，它也不会再威胁互联网稳定性或妨碍将来区块 Gas 上限的提高。因为 EIP|7883 更改了 ModExp 所需的 Gas 数目，因此它不向后兼容，但 Gas 重定价在ETH中已多次发生，并且已被充分理解。

测试结果表明，此次 Gas 成本的提高幅度很显著。大约 99.69% 的历史 ModExp 调用目前要么需要 500 Gas（之前为 200 Gas），要么需要之前价格的三倍。但某些高负载测试用例的 Gas 成本涨幅更大。比如，在一个“指数运算密集型”测试中，Gas 消耗从 215 跃升至 16,624，大约增加了 76 倍，这是由于目前对很大指数的定价愈加合理。

EIP

在安全性方面，该提案不会引入新的攻击渠道，也不会减少任何运算的本钱。相反，它着重于防范一个关键的风险：定价过低的 ModExp 运算可能使攻击者可以以极低的本钱在区块中填充极其繁重的计算。唯一可能的缺点是某些 ModExp 运算的价格或许会过高，但这远比目前定价过低的问题要好得多。该提案没引入任何接口变更或新功能，因此现有些算术行为和测试向量仍然有效。

EIP|7917：准确预言下一建议者

ETH需要这项提案，由于互联网下一 epoch 的建议者调度没办法完全预测。即便在第 N 个 epoch 已知第 N+1 个 epoch 的 RANDAO 种子，实质的建议者列表仍然可能因第 N 个 epoch 内的有效余额 (EB) 更新而发生变化。

这类 EB 变化可能来自罚没、惩罚、超越 1 以太币的奖励、验证者合并或新的存款，特别是在 EIP|7251 将最大有效余额提升到 32 以太币以上之后。这种不确定性给那些依靠于提前了解下一个建议者的系统（比如基于预确认的协议）带来了问题，这类系统需要稳定且可预测的时间表才能顺利运行。验证者甚至可能试图“刷”或操纵其有效余额，以影响下一个 epoch 的建议者。

因为这类问题，ETH需要一种办法来使建议者时间表在将来几个 epoch 内完全确定，使其不会因最后一刻的 EB 更新而改变，并且易于被应用层访问。

为了达成这一点，EIP|7917 引入了一种确定性的建议者前瞻机制，即在每一个 epoch 开始时预先计算并存储下面 MIN|SEED|LOOKAHEAD + 1 个 epoch 的建议者调度。简单来讲，信标状况目前包括一个名为 `prosoperer|lookahead` 的列表，该列表一直涵盖两个完整周期的建议者（总共 64 个时隙）。

比如，当 epoch N 开始时，该列表已经包括了 epoch N 和 epoch N+1 中每一个时隙的建议者。然后，当互联网进入周期 N+1 时，该列表向前移动：移除周期 N 的建议者条目，将周期 N+1 的条目移到列表前面，并在列表末尾添加周期 N+2 的新建议者条目。这致使调度固定、可预测，并且推广客户端可以直接读取，而不需要每一个时隙都重新计算建议者。

为了维持更新，列表会在每一个 epoch 边界处向前移动：移除上一个 epoch 的数据，并计算下一个将来 epoch 的一组新的建议者索引并添加到列表中。该过程用与之前相同的种子和有效余额规则，但目前调度计算得更早，从而防止了在种子确定后有效余额变化对其产生影响。分叉后的第一个区块也会填充整个前瞻范围，以确保所有将来的 epoch 都拥有正确初始化的调度。

假设每一个 epoch 有 8 个槽位而不是 32 个（为了简化起见）。假如没这项 EIP，在第 5 个 epoch 期间，虽然你了解第 6 个 epoch 的种子，但假如验证者被罚没或获得足够的奖励以改变其在第 5 个 epoch 期间的有效余额，则第 6 个 epoch 的槽位 2 的实质建议者仍然可能发生变化。有了 EIP|7917，ETH会在第 5 个 epoch 开始时预先计算第 5、6 和 7 个 epoch 的所有建议者，并按顺序存储在 `prosopers|lookahead` 中。那样即便余额在第 5 个 epoch 后期发生变化，第 6 个 epoch 的建议者列表也维持固定且可预测。

EIP|7917 修复了信标链设计中长期存在的缺点。它保证一旦先前 epoch 的 RANDAO 可用，将来 epoch 的验证者选择就没办法更改。这也预防了“有效余额刷取”，即验证者在看到 RANDAO 后试图调整其余额以影响下一个 epoch 的建议者列表。确定性前瞻机制消除去整个攻击向量，大大简化了安全剖析。它还使共识推广客户端可以趁早了解哪个将建议即将来临的区块，这能够帮助达成，并允许应用层通过信标根的默克尔证明轻松验证建议者日程。

在此提案之前，推广客户端仅计算目前时隙的建议者。有了 EIP|7917，它们目前会在每一个 epoch 转换期间一次性计算下一个 epoch 所有时隙的建议者列表。这会增加少量工作，但计算建议者索引很轻量级，主要涉及用种子对验证者列表进行采样。然而，推广客户端需要进行基准测试，以确保此额外计算不会致使性能问题。

EIP|7918：Blob 基础成本受实行本钱限制

ETH需要这项提案，由于目前的 Blob 成本系统（来源于 EIP|4844）在实行 Gas 成为 Rollup 的主要本钱时会失效。

现在，大部分 Rollup 支付的实行 Gas（将 Blob 买卖包括在区块中的本钱）远高于实质的 Blob 成本。这导致了一个问题：即便ETH不断减少 Blob 基础成本，Rollup 的总本钱事实上并没改变，由于本钱最高的部分仍然是实行 Gas。因此，Blob 基础成本会持续降低，直至达到绝对最低值（1 wei），此时协议将没办法再借助 Blob 成本来控制需要。然后，当 Blob 用量忽然上升时，Blob 成本需要经过不少区块才能恢复到正常水平。这致使价格不稳定，对用户而言很难预测。

比如，假设一个 Rollup 想要发布其数据：它需要支付大约 25,000,000 gwei 的实行 Gas（大约 1,000,000 gas 需要 25 gwei），而 Blob 成本仅约为 200 gwei。这意味着总本钱约为 25,000,200 gwei，其中几乎全部本钱都来自实行 Gas，而非 Blob 成本。假如ETH持续减少 Blob 成本，比如从 200 gwei 降至 50 gwei，再降至 10 gwei，最后降至 1 gwei，总本钱几乎也不会改变，仍然维持在 25,000,000 gwei。

EIP|7918 通过引入一个基于实行基础成本的最低“保留价格”来解决这个问题，从而预防 Blob 价格过低，并使 Rollup 的 Blob 定价愈加稳定和可预测。

为了理解为何需要如此做，大家可以看看 Blob 的需要。Rollup 关注的是它支付的总本钱：实行本钱加上 blob 本钱。假如实行 Gas 成本特别高，比如 20 gwei，那样即便 Blob 成本从 2 gwei 降到 0.2 gwei，总本钱也几乎不变。这意味着减少 Blob 基础成本对需要几乎没影响。在经济学中，这被叫做“成本缺少弹性”。它导致了一种需要曲线几乎垂直的状况：减少价格不会增加需要。

在这样的情况下，Blob 基础成本机制会变得盲目——即便需要没反应，它也会继续减少价格。这就是为何 blob 基础成本常常会降到 1 gwei 是什么原因。然后，当实质需要稍后增加时，协议需要一个小时或更长期的几乎满区块才能将成本提高到适当的水平。EIP|7918 通过打造与实行 Gas 挂钩的储备价格来解决这个问题，从而确保即便实行本钱占主导地位，Blob 成本仍然有意义。

添加此保留价格的另一个缘由是，节点需要做不少额外的工作来验证 Blob 数据的 KZG 证明。这类证明保证了 Bob 中的数据与其承诺相符。在 EIP|4844 下，节点仅需验证每一个 Blob 的一个证明，本钱非常低。但在 EIP|7918 中，节点需要验证的证明数目更多。这全是由于在 EIP|7594 (PeerDAS) 中，blob 被分割成很多称为 cell 的小块，每一个 cell 都有我们的证明，这致使验证工作量大大增加。

从长远来看，EIP|7918 也能够帮助ETH为将来做好筹备。伴随技术的进步，存储和共享数据的本钱自然会减少，ETH预计会伴随时间的推移允许存储更多 Blob 数据。当 Blob 容量增加时，Blob 成本（以以太币计）自然会降低。该提案支持这一点，由于保留价格与实行 Gas 价格挂钩，而不是一个固定值，因此它可以参考互联网的增长进行调整。

伴随 Blob 空间和实行区块空间的扩展，它们的价格关系将维持平衡。只有在极少数状况下，ETH大幅增加 Blob 容量但未增加实行 Gas 容量时，保留价格才可能过高。在这样的情况下，Blob 成本最后或许会高于实质所需。但ETH没计划以这种方法扩展——Blob 空间和实行区块空间预计将同步增长。因此，所选值 (BLOB|BASE|cosplayT = 2¹³) 被觉得是安全且平衡的。

当实行 Gas 成本忽然暴涨时，需要知道一个小事。因为 Blob 的价格取决于实行基础成本，实行本钱的忽然上升或许会暂时使 Blob 成本进入一种由实行本钱主导的状况。比如，假设实行 Gas 成本在一个区块内忽然从 20 gwei 跃升至 60 gwei。因为 Blob 的价格与该数值挂钩，Blob 成本没办法跌破新的更高水平。假如 Blob 仍在被用，其成本仍会正常增长，但协议不会允许其降低，直到其增长到足以匹配更高的实行本钱为止。这意味着在几个区块内，Blob 成本的增长速度或许会慢于实行本钱。这种短暂的延迟并无害处——它事实上可以预防 Blob 价格出现剧烈的波动，并使系统愈加平稳。

作者还对 2024 年 11 月至 2025 年 3 月的实质区块买卖活动进行了实证剖析，应用了保留价格规则。在高实行浪费时间期（平均约 16 gwei），与旧机制相比，储备阈值显著提升了区块基础成本。在低实行浪费时间期（平均约 1.3 gwei），区块成本几乎维持不变，除非计算出的区块基础成本低于储备价格。通过比较数千个区块，作者表明，新机制在维持对需要自然响应的同时，还能创造更稳定的定价。四个月的区块成本直方图显示，储备价格预防区块成本狂跌至 1 gwei，从而减少了极端波动。

就安全性而言，此变更也不会引入任何风险。基本区块成本一直会等于或高于实行 Gas 的 BLOB|BASE|cosplayT 单位本钱。这是安全的，由于该机制仅提升了最低成本，而设定价格下限不会干扰协议的正确性。它只不过确保了健康的经济运行。

EIP|7934：RLP 实行区块大小限制

在 EIP|7934 之前，ETH对 RLP 编码的实行区块的大小没严格的上限。理论上，假如区块包括很多买卖或很复杂的数据，则其大小或许会很大。这导致了两个主要问题：互联网不稳定和拒绝服务 (DoS) 攻击风险。

假如区块过大，节点下载和验证它所需的时间就会更长，这会减慢区块传播速度并增加区块链临时分叉的可能性。更糟糕的是，攻击者可以故意创建一个很大的区块来使节点过载，致使延迟甚至使其离线——这是一种典型的拒绝服务攻击。同时，ETH的共识层（CL）Gossip 协议已经拒绝传播任何超越 10MB 的区块，这意味着过大的实行区块可能没办法在互联网中传播，从而导致链上的碎片化或节点间的分歧。鉴于这类风险，ETH需要一条明确的协议级规则来预防区块过大，并维持互联网的稳定和安全。

EIP|7934 通过引入协议级的 RLP 编码实行区块大小上限来解决这个问题。允许的最大区块大小（MAX|BLOCK|SIZE）设置为 10 MiB（10,485,760 字节），但因为信标区块也会占用一些空间（SAFETY|MARGIN），ETH在此基础上增加了 2 MiB（2,097,152 字节）。

选择 10 MiB 的上限是有意为之，由于它与共识层 gossip 协议中现有些限制相匹配。任何大于 10 MiB 的数据都不会在互联网中广播，因此此 EIP 使实行层与共识层的限制维持一致。这确保了所有组件的一致性，并预防了因为 CL 拒绝传播而致使有效实行区块“不可见”的状况。

此变更不向下兼容大于新限制的区块，这意味着矿工和验证者需要更新其推广客户端以遵守该规则。然而，因为超大区块本身就存在问题，且在实质运行中并不容易见到，因此影响微乎其微。

在安全性方面，EIP|7934 通过确保任何参与者都没办法创建会使互联网瘫痪的区块，显著增强了ETH抵御针对特定区块大小的 DoS 攻击的能力。总而言之，EIP|7934 增加了一条关键的安全边界，提升了稳定性，统一了实行逻辑 (EL) 和 CL 的行为，并预防了与超大区块的创建和传播有关的多种攻击。

EIP|7939：计算前导零 (CLZ) 操作码

在此 EIP 之前，ETH没内置的操作码来计算 256 位数字中前导零的位数。开发者不能不用 Solidity 手工达成 CLZ 函数，这需要很多的位移操作和比较。

这是一个非常大的问题，由于自概念达成速度慢、本钱高，而且会占用很多字节码，从而增加 Gas 消耗。对于零常识证明系统来讲，本钱更高，右移操作的证明本钱极高，因此像 CLZ 如此的操作会显著减少零常识证明电路的运行速度。因为 CLZ 是一个很容易见到的底层函数，广泛应用于数学库、压缩算法、位图、签名策略与很多加密或数据处置任务中，ETH需要一种更快、更经济的计算办法。

EIP|7939 通过引入一个名为 CLZ (0x1e) 的新操作码解决了这个问题。该操作码从栈中读取一个 256 位的值，并返回前导零的个数。假如输入数字为零，则操作码返回 256，由于一个 256 位的零有 256 个前导零。

这与 ARM 和 x86 等很多 CPU 构造中 CLZ 的工作方法一致，在这类构造中，CLZ 操作是原生支持的。添加 CLZ 可以显著减少很多算法的开销：lnWad、powWad、LambertW、各种数学函数、字节串比较、位图扫描、调用数据压缩/解压缩与后量子签名策略等操作都能受益于更快的先行零测试。

CLZ 的 gas 本钱设置为 5，与 ADD 类似，并且略高于之前的 MUL 价格，以防止定价过低而致使拒绝服务 (DoS) 攻击的风险。基准测试表明，CLZ 的计算量与 ADD 大致相同，并且在 SP1 rv32im 证明环境中，CLZ 的证明本钱事实上比 ADD 更低，从而减少了零常识证明的本钱。

EIP|7939 完全向后兼容，由于它引入了一个新的操作码，并且没修改任何现有行为。

总体而言，EIP|7939 通过添加一个现代 CPU 已支持的简单高效的原语，使ETH运行速度更快、本钱更低，并且对开发者愈加友好——减少 Gas 成本、减小字节码大小，并减少很多容易见到操作的零常识证明本钱。

EIP|7951：支持现代硬件的签名

在此 EIP 之前，ETH没安全、原生的方法来验证用 secp256r1 (P|256) 曲线创建的数字签名。

该曲线是 Apple Secure Enclave、Android Keystore、HSM、TEE 和 FIDO2/WebAuthn 安全密钥等现代设施用的规范。因为缺少这种支持，应用程序和钱包没办法轻松地用设施级硬件安全进行签名。此前曾有过一次尝试 (RIP|7212)，但它存在两个紧急的安全漏洞，分别与无穷远点处置和错误的签名比较有关。这类问题可能致使验证错误，甚至可能致使共识失败。 EIP|7951 修复了这类安全问题，并引入了一个安全、原生的预编译程序，使ETH最后可以安全高效地支持来自现代硬件的签名。

EIP|7951 在地址 0x100 处添加了一个名为 P256VERIFY 的新预编译合约，该合约用 secp256r1 曲线实行 ECDSA 签名验证。与直接在 Solidity 中达成该算法相比，这致使签名验证愈加迅速且本钱更低。

EIP|7951还概念了严格的输入验证规则。假如存在任何无效状况，预编译将返回失败，且不会回滚，消耗的 Gas 与成功调用相同。验证算法遵循标准的 ECDSA：它计算 s⁻¹ mod n，重建签名点 R'，假如 R' 为无穷远则拒绝，最后检查 R' 的 x 坐标是不是与 r (mod n) 匹配。这修正了 RIP|7212 中的错误，RIP|7212 直接比较了 r'，而不是先将它模 n 化简。

该操作的 Gas 成本设定为 6900 gas，高于 RIP|7212 版本，但与 secp256r1 验证的实质性能基准相符。关键的是，该接口与已部署 RIP|7212 的 Layer 2 互联网完全兼容（地址相同，输入/输出格式相同），因此现有些智能合约将继续正常运行，不需要任何更改。唯一有什么区别在于修正后的行为和更高的 Gas 成本。

从安全角度来看，EIP|7951 恢复了 ECDSA 的正确行为，消除去预编译级别的可塑性问题（将可选检查留给应用程序），并明确指出预编译无需恒定时间实行。 secp256r1 曲线提供 128 位安全性，并已获得广泛的信赖和剖析，因此可安全应用于ETH。

简而言之，EIP|7951 旨在安全地将现代硬件支持的身份验证引入ETH，修复早期提案的安全问题，并提供一种靠谱、标准化的方法来验证整个生态系统中的 P|256 签名。