以太坊Fusaka主网升级今日启动，深入解析9大EIP提案

目录

• EIP-7594：PeerDAS ——节点数据可用性采样
• EIP-7823：为MODEXP 设置1024 字节上限
• EIP-7825：交易1670 万Gas 上限
• EIP-7883：ModExp Gas 费用上涨
• EIP-7917：准确预言下一提议者
• EIP-7918：Blob 基础费用受执行成本限制
• EIP-7934：RLP 执行区块大小限制
• EIP-7939：计算前导零(CLZ) 操作码
• EIP-7951：支援现代硬体的签名
• 总结

计划于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（共识层）的组合名称。它代表着以太坊向高度可扩展、数据丰富的未来迈出的又一步，在这个未来中，La​​yer 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 上限为4,000 万，任何单笔交易的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 函数，这需要大量的位移操作和比较。

这是一个很大的问题，因为自定义实现速度慢、成本高，而且会占用大量字节码，从而增加Gas 消耗。对于零知识证明系统来说，成本更高，右移操作的证明成本极高，因此像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 数据。

以上就是以太坊Fusaka主网升级今日启动，深入解析9大EIP提案的详细内容，更多关于Fusaka升级的资料请关注币圈188其它相关文章！