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

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

PeerDAS (EIP-7594) 通过允许节点在无需下载所有数据的情况下验证 Blob，提高了数据可用性。多项升级也加强了执行安全性，包括限制 ModExp (EIP-7823)、限制交易 Gas 限额 (EIP-7825) 以及更新 ModExp Gas 成本 (EIP-7883)。此次 Fusaka 升级还通过确定性提议者前瞻机制 (EIP-7917) 改进了区块生成，并通过设置与执行成本挂钩的「保留价格」保持 Blob 费用的稳定 (EIP-7918)。

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

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

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

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

以太坊需要这项提案，因为网络希望为用户（尤其是 Rollup 用户）提供更高的数据可用性。

然而，在当前的 EIP-4844 设计下，每个节点仍然需要下载大量的 blob 数据才能验证其是否已发布。这造成了扩展性问题，因为如果所有节点都必须下载所有数据，网络的带宽和硬件需求就会增加，去中心化程度也会受到影响。为了解决这个问题，以太坊需要一种方法，让节点无需下载所有数据即可确认数据是否可用。

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

但以太坊还需要一种与现有 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])」

在新包装器中，cell_proofs 只是一个列表，其中包含每个 blob 的每个单元的所有证明（例如：[cell_proof_0, cell_proof_1, ...]）。其他字段 tx_payload_body、blobs 和 commitments 与 EIP-4844 中的完全相同。区别在于，原有的单个「proofs」字段被移除，并替换为新的 cell_proofs 列表，同时新增了一个名为 wrapper_version 的字段，用于指示当前使用的包装器格式。

PeerDAS 使以太坊能够在不增加节点工作量的情况下提高数据可用性。如今，一个节点只需采样大约 1/8 的总数据。未来，这一比例甚至可能降至 1/16 或 1/32，从而提升以太坊的可扩展性。该系统运行良好，因为每个节点都拥有众多对等节点，因此，如果某个对等节点无法提供所需数据，该节点可以向其他对等节点请求。这自然地建立了冗余机制，并提高了安全性，节点还可以选择存储超出实际需求的数据，这进一步增强了网络的安全性。

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

PeerDAS 使用列采样而非行采样，因为这样可以大大简化数据重建。如果节点对整行（整个 blob）进行采样，则需要创建原本不存在的额外「扩展 blob」，这会减慢区块生产者的速度。

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

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

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

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

这项提案的必要性在于，以太坊当前的 MODEXP 预编译机制多年来导致了诸多共识漏洞。这些漏洞大多源于 MODEXP 允许输入数据量极其庞大且不切实际，导致客户端必须处理无数异常情况。

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

为了减少这些问题并提高以太坊的稳定性，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 上限

以太坊确实也需要这项提案，因为目前单笔交易几乎可以消耗整个区块的 Gas 上限。

这会造成几个问题：一笔交易可能消耗掉区块的大部分资源，导致类似 DoS 攻击的缓慢延迟；耗费大量 Gas 的操作会过快地增加以太坊的状态更新；区块验证速度变慢，节点难以跟上。

如果一个用户提交了一笔几乎消耗所有 Gas 的巨额交易（例如，一笔在 4000 万 Gas 的区块中消耗 3800 万 Gas 的交易），那么其他普通交易就无法放入该区块，每个节点都必须花费额外的时间来验证该区块。这会威胁到网络的稳定性和去中心化，因为验证速度变慢意味着性能较弱的节点会落后。为了解决这个问题，以太坊需要一个安全的 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 上限使以太坊更能抵御基于 Gas 的 DoS 攻击，因为攻击者无法再强迫验证者处理超大交易。它还有助于保持区​​块验证时间的可预测性，从而使节点更容易保持同步。主要极端情况是，少数规模非常大的合约部署可能无法满足上限要求，需要重新设计或拆分为多个部署步骤。

总体而言，EIP-7825 旨在加强网络防范滥用，保持节点需求合理，提高区块空间使用的公平性，并确保随着 Gas 上限提高，区块链仍能保持快速稳定运行。

EIP-7883：ModExp Gas 费用上涨

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

在某些情况下，ModExp 操作所需的计算量远远超过用户目前支付的费用。这种不匹配会带来风险：如果复杂的 ModExp 调用价格过低，它们可能会成为瓶颈，使网络难以安全地提高 Gas 上限。因为区块生产者可能被迫以极低的成本处理极其繁重的操作。

为了解决这个问题，以太坊需要调整 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 重定价在以太坊中已多次发生，并且已被充分理解。

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

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

EIP-7917：准确预言下一提议者

以太坊需要这项提案，因为网络下一 epoch 的提议者调度无法完全预测。即使在第 N 个 epoch 已知 第 N+1 个 epoch 的 RANDAO 种子，实际的提议者列表仍然可能因第 N 个 epoch 内的有效余额 (EB) 更新而发生变化。

这些 EB 变化可能来自罚没、惩罚、超过 1 ETH 的奖励、验证者合并或新的存款，尤其是在 EIP-7251 将最大有效余额提高到 32 ETH 以上之后。这种不确定性给那些依赖于提前知道下一个提议者的系统（例如基于预确认的协议）带来了问题，这些系统需要稳定且可预测的时间表才能顺利运行。验证者甚至可能试图「刷」或操纵其有效余额，以影响下一个 epoch 的提议者。

由于这些问题，以太坊需要一种方法来使提议者时间表在未来几个 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，以太坊会在第 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 基础费用受执行成本限制

以太坊需要这项提案，因为当前的 Blob 费用系统（源自 EIP-4844）在执行 Gas 成为 Rollup 的主要成本时会失效。

目前，大多数 Rollup 支付的执行 Gas（将 Blob 交易包含在区块中的成本）远高于实际的 Blob 费用。这造成了一个问题：即使以太坊不断降低 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 费用。如果以太坊持续降低 Blob 费用，例如从 200 gwei 降至 50 gwei，再降至 10 gwei，最终降至 1 gwei，总成本几乎也不会改变，仍然保持在 25,000,000 gwei。

EIP-7918 通过引入一个基于执行基础费用的最低「保留价格」来解决这个问题，从而防止 Blob 价格过低，并使 Rollup 的 Blob 定价更加稳定和可预测。

EIP-7918 的核心思想很简单：Blob 的价格永远不应低于一定数量的执行 Gas 成本（称为 BLOB_BASE_COST）。calc_excess_blob_gas() 的值被设置为 2¹³，该机制通过对 calc_excess_blob_gas() 函数进行微小的修改来实现。

通常，该函数会根据区块使用的 blob gas 是否高于或低于目标值来增加或减少 Blob 基础费用。根据此提案，如果 Blob 相对于执行 Gas 变得「过低」，该函数将停止扣除目标 blob gas。这使得多余的 blob gas 增长得更快，从而防止 Blob 基础费用进一步下降。因此，Blob 基础费用现在有一个最小值，等于 BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_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 也有助于以太坊为未来做好准备。随着技术的进步，存储和共享数据的成本自然会降低，以太坊预计会随着时间的推移允许存储更多 Blob 数据。当 Blob 容量增加时，Blob 费用（以 ETH 计）自然会下降。该提案支持这一点，因为保留价格与执行 Gas 价格挂钩，而不是一个固定值，因此它可以根据网络的增长进行调整。

随着 Blob 空间和执行区块空间的扩展，它们的价格关系将保持平衡。只有在极少数情况下，以太坊大幅增加 Blob 容量但未增加执行 Gas 容量时，保留价格才可能过高。在这种情况下，Blob 费用最终可能会高于实际所需。但以太坊没有计划以这种方式扩展——Blob 空间和执行区块空间预计将同步增长。因此，所选值 (BLOB_BASE_COST = 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_COST 单位成本。这是安全的，因为该机制仅提高了最低费用，而设定价格下限不会影响协议的正确性。它只是确保了健康的经济运行。

EIP-7934：RLP 执行区块大小限制

在 EIP-7934 之前，以太坊对 RLP 编码的执行区块的大小没有严格的上限。理论上，如果区块包含大量交易或非常复杂的数据，则其大小可能会非常大。这造成了两个主要问题：网络不稳定和拒绝服务 (DoS) 攻击风险。

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

EIP-7934 通过引入协议级的 RLP 编码执行区块大小上限来解决这个问题。允许的最大区块大小（MAX_BLOCK_SIZE）设置为 10 MiB（10,485,760 字节），但由于信标区块也会占用一些空间（SAFETY_MARGIN），以太坊在此基础上增加了 2 MiB（2,097,152 字节）。

这意味着实际允许的最大 RLP 编码执行块大小为 MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN。如果编码后的块大于此限制，则该块将被视为无效，节点必须拒绝它。有了这条规则，区块生产者必须检查他们构建的每个区块的编码大小，验证者必须在区块验证期间验证此限制。此大小上限独立于 Gas 限制，这意味着即使区块「低于 Gas 限制」，如果其编码大小过大，仍然会被拒绝。这确保了 Gas 使用量和实际字节大小限制都得到遵守。

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

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

在安全性方面，EIP-7934 通过确保任何参与者都无法创建会使网络瘫痪的区块，显著增强了以太坊抵御针对特定区块大小的 DoS 攻击的能力。总而言之，EIP-7934 增加了一条重要的安全边界，提高了稳定性，统一了执行逻辑 (EL) 和 CL 的行为，并防止了与超大区块的创建和传播相关的多种攻击。

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

在此 EIP 之前，以太坊没有内置的操作码来计算 256 位数字中前导零的位数。开发者不得不使用 Solidity 手动实现 CLZ 函数，这需要大量的位移操作和比较。

这是一个很大的问题，因为自定义实现速度慢、成本高，而且会占用大量字节码，从而增加 G as 消耗。对于零知识证明系统来说，成本更高，右移操作的证明成本极高，因此像 CLZ 这样的操作会显著降低零知识证明电路的运行速度。由于 CLZ 是一个非常常见的底层函数，广泛应用于数学库、压缩算法、位图、签名方案以及许多加密或数据处理任务中，以太坊需要一种更快、更经济的计算方法。

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 已支持的简单高效的原语，使以太坊运行速度更快、成本更低，并且对开发者更加友好——降低 Gas 费用、减小字节码大小，并降低许多常见操作的零知识证明成本。

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

在此 EIP 之前，以太坊没有安全、原生的方式来验证使用 secp256r1 (P-256) 曲线创建的数字签名。

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

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 位安全性，并已获得广泛的信任和分析，因此可安全应用于以太坊。

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

总结

下表总结了哪些以太坊客户端需要针对不同的 Fusaka EIP 进行更改。共识客户端下的勾选标记表示该 EIP 需要更新共识层客户端，而执行客户端下的勾选标记则表示该升级影响执行层客户端。某些 EIP 需要同时更新共识层和执行层，而其他 EIP 则仅需更新其中一层。

总而言之，以上就是包含在 Fusaka 硬分叉中的关键 EIP。虽然此次升级涉及共识和执行客户端的多项改进，从 Gas 调整和操作码更新再到新的预编译，但此次升级的核心还是 PeerDAS，它引入了点对点数据可用性采样，从而能够更高效、更去中心化地处理整个网络中的 Blob 数据。