以太坊 Fusaka 升级带来了哪些改进

Fusaka 网络升级

Fusaka 网络升级紧随 Pectra 之后，为所有以太坊用户和开发者带来了更多新功能并改善了体验。 其名称由执行层升级 Osaka 和共识层版本 Fulu 星 的名字组合而成。 以太坊的两个部分都将获得升级，推动以太坊在可扩展性、安全性和用户体验方面迈向未来。

该升级计划于 2025 年第四季度 发布。

Fusaka 升级只是以太坊长期发展目标中的一步。 了解更多关于 以太坊协议路线图 和 以往的网络升级。

扩展 Blobs

PeerDAS

这是 Fusaka 分叉的核心亮点，也是此次升级新增的主要功能。

目前，Layer 2 会将其数据以 blob 的形式发布到以太坊上，blob 是专门为 Layer 2 创建的一种短暂数据类型。在 Fusaka 之前，每个全节点都必须存储所有 blob，以确保数据存在。但随着 blob 吞吐量的增加，下载所有这些数据的资源消耗将变得难以承受。

借助 数据可用性抽样（Data Availability Sampling），每个节点不再需要存储全部 blob 数据，而是只需负责其中一部分。 在网络中，blobs 会被均匀随机分布到各个节点上，每个全节点仅需保存大约 1/8 的数据，从而实现理论上高达 8 倍的扩展性。

为了保证数据可用性，可以通过任意 50% 的数据重建整个数据集，且错误或丢失数据的概率被控制在密码学上可忽略的水平（约 10^-20 至 10^-24 之间）。

这一机制让节点的硬件和带宽需求保持在合理范围内，同时实现 blob 数据扩容，使 Layer 2 能以更低费用获得更高吞吐量。

👉 了解更多关于 PeerDAS

相关资源：

• EIP-7594 技术规范
• DappLion：Scaling Ethereum Today | ETHSofia 2024
• 学术论文：A Documentation of Ethereum’s PeerDAS (PDF)

仅调整 Blob 参数的分叉（Blob-Parameter-Only Forks：BPO）

Layer 2 通过扩展来提升以太坊的可扩展性。 随着它们网络的增长，需要向以太坊发布更多数据。 这意味着以太坊需要随着时间推移逐步增加可用的 blob 数量。

虽然 PeerDAS 允许扩大 blob 的容量，但这一过程必须渐进且安全。

由于以太坊运行在数千个独立节点上，所有节点必须遵循相同规则达成一致，因此我们不能像更新网站那样随意修改 blob 数量。 任何规则变更都必须经过协调的网络升级——即每个节点、客户端与验证者都必须在同一个预定区块高度前完成升级。

这些协调升级通常包含大量变更，需要长时间测试。为了让以太坊能更快适应 Layer 2 对 blob 数量变化的需求，“仅调整 blob 参数的分叉”引入了一种机制，可以在不等待大型升级的情况下，单独增加 blob 的数量。

客户端可以像配置 gas limit 一样，通过参数设置 target 和 max 的 blob 数量。 例如，在两次主网升级之间，客户端可以约定将目标和最大 blob 数分别提高到 9 和 12，节点运营者只需更新配置即可参与这一小型分叉。 这种 blob 参数调整可以在任何时间进行。

最初在 Dencun 升级中，网络中每个区块的目标 blob 数为 3； Pectra 将其提升到 6；Fusaka 之后，这个数量可以在主网升级之外，以更灵活的节奏持续提升。

图表来源：Ethereum Blobs - @hildobby, Dune Analytics

相关资源： EIP-7892 技术规范

将 Blob 基础费用与执行成本挂钩

Layer 2 在发布数据时需支付两种费用：一是 blob 费用，二是 验证这些 blob 所需的执行 gas。 如果执行 gas 成为主要成本，blob 费用可能会被压到 1 wei，从而失去作为价格信号的作用。

EIP-7918 提出了一个解决方案： 为每个 blob 设置与其执行成本成比例的保底价格。 当保底价高于名义 blob 基础费时，算法会将该区块视为超出目标值，停止继续压低费用，允许其正常上升。 因此可以实现以下效果：

• blob 费用市场始终能对网络拥塞作出反应
• Layer 2 至少支付与其计算消耗相匹配的合理成本
• 执行层的 base-fee 激增不再导致 blob 费长期停留在 1 wei

相关资源：

• EIP-7918 技术规范
• Storybook 解读文档

扩展 L1

历史数据到期与更简化的收据（History expiry and simpler receipts）

自 2025 年 7 月起，以太坊执行层客户端开始支持部分历史数据到期（partial history expiry）。这意味着节点将丢弃早于 The Merge 之前的历史记录，从而在以太坊持续增长的过程中，降低节点运营者所需的磁盘空间。

该 EIP 被列在“核心 EIP（Core EIPs）”之外，因为此次分叉本身并未引入任何协议更改——它更像是一个通知：客户端团队必须在 Fusaka 升级前支持历史数据到期功能。实际上，客户端可以在任何时间实现该特性，但将其加入 Fusaka 升级计划，意味着它被正式纳入开发清单，并可与 Fusaka 的其他变更一同测试。

参考资源： EIP-7642 技术规范

为 MODEXP 设置上限

在此之前，MODEXP（模幂运算）预编译合约可以接受几乎任意大小的输入数字。这种无限制的设计导致难以测试、容易被滥用，也对客户端稳定性造成潜在风险。 EIP-7823 为此设定了明确的限制：每个输入数字最长不得超过 8192 位（1024 字节）。超过此限制的交易会被拒绝，其 Gas 将被消耗，但不会对状态造成任何更改。 这个上限仍然足以覆盖所有现实世界的需求，同时去除了那些使 Gas 计算和安全审查变得复杂的极端情况。 此改动在不影响用户或开发者体验的前提下，提供了更高的安全性和拒绝服务（DoS）防护。

参考资源： EIP-7823 技术规范

交易 Gas 限制上限

EIP-7825 为每笔交易增加了一个 Gas 上限： 16,777,216（2²⁴）gas。

这是一种主动的 DoS 防御措施，用于在未来提升区块 Gas 上限时，限制单笔交易的最坏情况成本。 它使验证和传播更容易建模，从而为通过提高区块 Gas 上限来扩展以太坊做好准备。

为什么是 2²⁴ gas？ 这个数值比当前区块 Gas 上限小得多，但足以支持真实的合约部署和复杂预编译调用。 同时，它是一个 2 的幂，方便在所有客户端中统一实现。 该新上限与 Pectra 升级前的平均区块大小相当，是对以太坊上各种操作的合理约束。

参考资源： EIP-7825 技术规范

MODEXP Gas 成本上调

MODEXP 是一个内置预编译函数，用于执行模幂运算（modular exponentiation）——这是一种在 RSA 签名验证和零知识证明系统中常见的大数运算。它允许合约直接调用，而无需自行实现复杂算法。

开发者和客户端团队发现，MODEXP 是提升区块 Gas 上限的主要障碍之一，因为现有 Gas 定价常常低估某些输入的实际计算量。 结果就是：一笔使用 MODEXP 的交易可能消耗与整个区块相当的处理时间，从而拖慢网络。

该 EIP 重新校准了计算成本，使其更符合真实的资源消耗：

• 将最低费用从 200 提高到 500 gas，并移除了 EIP-2565 引入的三分之一折扣。
• 对较长的指数输入（第二个参数，即幂次）加速提高 Gas 成本：当指数超过 32 字节（256 位）时，每增加一个字节，费用上升得更快。
• 对较大的底数或模数也收取额外费用：若底数（base）或模数（modulus）超过 32 字节，其费用按比例上升。

通过让 Gas 成本更贴近真实计算时间，MODEXP 将不再导致区块验证时间过长。 这项更改是未来安全提升区块 Gas 上限的重要前置条件之一。

参考资源： EIP-7883 技术规范

RLP 执行区块大小限制

此改动为区块引入了一个最大大小上限——它限制的是通过网络传输的区块大小，不同于 Gas 限制（后者约束区块内部的计算量）。 区块大小上限被设定为 10 MiB，其中预留 2 MiB 作为共识层数据的缓冲，以保证传播顺畅。 如果某个区块超过此上限，客户端将直接拒绝它。

这是必要的，因为过大的区块会延迟在全网的传播与验证，可能引发共识问题或被用于 DoS 攻击。 此外，共识层的 gossip 协议已经拒绝转发大于约 10 MiB 的区块，因此执行层与之对齐能避免出现“部分节点看到区块、部分节点丢弃区块”的异常现象。

具体参数如下（针对 RLP 编码 的执行区块）：

MAX_BLOCK_SIZE = 10,485,760 bytes
SAFETY_MARGIN = 2,097,152 bytes
MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN

目标是限制最坏情况下的传播与验证时间，使执行层与共识层行为保持一致，从而降低重组（reorg）与 DoS 风险，而无需更改 Gas 计算逻辑。

参考资源： EIP-7934 技术规范

将默认 Gas 上限提升至 6000 万

在 2025 年 2 月以太坊将区块 Gas 上限从 3000 万提升至 3600 万（随后至 4500 万）之前，该值自 Merge（2022 年 9 月）以来一直未变。 EIP-7935 旨在将持续扩容设为优先目标。

该 EIP 协调执行层客户端团队在 Fusaka 升级中将默认 Gas 上限提升至 4500 万以上。 它是一项信息性（Informational）EIP，但明确要求客户端在开发网络（devnet）上测试更高上限，收敛出安全数值，并在 Fusaka 发布版中采用该数值。

开发网络目标为约 6000 万 Gas 的压力测试（使用合成负载的满块），并逐步递增。 研究显示，最坏情况下的区块大小问题不会在约 1.5 亿 Gas 以下触发。 同时，此更改需与交易 Gas 上限（EIP-7825）配套，以确保当区块上限上升时，单笔交易不会独占过多资源。

参考资源： EIP-7935 技术规范

改善用户体验（Improve UX）

确定性的提议者预览（Deterministic proposer lookahead）

通过 EIP-7917，信标链（Beacon Chain）将能够提前获知下一个 epoch（时期）中的区块提议者（block proposer）。 这种对未来提议者的确定性视图，使得预确认（preconfirmations）成为可能——用户可以与即将成为提议者的验证者提前达成承诺，保证其交易会被包含在该验证者所提议的区块中，而无需等待该区块实际产生。

这一特性对客户端实现和网络安全都有好处，因为它避免了验证者通过操纵提议者顺序表而造成的边界问题（edge cases）。同时，提前的可预见性也降低了实现的复杂度。

资源：EIP-7917 技术规范

计数前导零（Count leading zeros, CLZ）操作码

此特性为 EVM 增加了一条小型指令：count leading zeros (CLZ)。 EVM 中几乎所有数据都是以 256 位数值表示的——新的操作码返回该数值前面有多少个“0”位。这是许多指令集体系结构中常见的功能，因为它能让算术运算更加高效。

在实际应用中，它将以往手写的位扫描逻辑压缩为单步操作，使得诸如查找首个被置位的比特、扫描字节或解析位字段的任务更简单且更省 Gas。 该操作码具有固定的低成本，其性能已被基准测试证实与一次普通的加法操作相当，从而减少字节码大小并节约 Gas。

资源：EIP-7939 技术规范

支持 secp256r1 曲线的预编译合约

此升级在固定地址 0x100 处引入了一个内置的 secp256r1（P-256）签名验证预编译合约， 其调用格式与许多 L2 已采用的标准保持一致，并修复了边界情况（edge cases）， 因此在 L2 环境下编写的合约无需修改即可在 L1 上运行。

这是一项重大用户体验升级！ 对用户而言，这意味着解锁了“设备原生签名”和“Passkey”功能。 钱包可以直接调用 Apple Secure Enclave、Android Keystore、硬件安全模块（HSM）以及 FIDO2/WebAuthn 接口—— 无需助记词，支持更顺畅的注册与多因素身份验证，体验更接近现代应用。 这带来了更好的用户体验、更容易的账户恢复，以及与数十亿设备一致的账户抽象模式。

对开发者而言，该预编译接受 160 字节输入并返回 32 字节输出，使移植现有库与 L2 合约更加方便。 在底层实现中，它包含了“无穷点检查”（point-at-infinity）与模比较验证，以排除复杂的边界情况而不破坏合法调用。

资源：

• EIP-7951 技术规范
• 关于 RIP-7212 的更多信息 (注意：EIP-7951 已取代 RIP-7212)

元信息（Meta）

eth_config JSON-RPC 方法

这是一个新的 JSON-RPC 调用，允许你查询节点当前运行的分叉配置。它会返回三个快照：current（当前）、next（下一次）与 last（上一次），以便验证者与监控工具检查客户端是否为即将到来的分叉正确配置。

实际上，该提案是为了解决 2025 年初 Pectra 分叉在 Holesky 测试网上线时出现的小规模配置错误， 这些错误导致网络无法完成最终确定（non-finalizing）。 此功能帮助测试团队与开发者确保从开发网到测试网、再到主网的重大分叉行为一致、可预测。

返回的快照包括：chainId、forkId、计划的分叉激活时间、已启用的预编译合约及其地址、系统合约依赖关系、以及该分叉的 blob 调度（blob schedule）。

该 EIP 被放在「核心 EIP」之外，因为此分叉本身不引入协议更改——它只是通知客户端团队必须在 Fusaka 升级前实现该 JSON-RPC 方法。

资源：EIP-7910 技术规范

常见问题（FAQ）

这个升级会影响所有以太坊节点和验证者吗？

是的。Fusaka 升级要求同时更新执行层客户端与共识层客户端。 所有主要以太坊客户端都将发布支持此次硬分叉的高优先级版本。 你可以通过客户端的 GitHub 仓库、它们的 Discord 频道、 EthStaker Discord，或订阅 Ethereum 官方博客来获取最新协议更新。

为确保在升级后继续与以太坊网络同步，节点运营者必须运行受支持的客户端版本。 请注意，这些发布信息是时间敏感的，请始终参考最新官方更新。

升级后需要转换 ETH 吗？

• 不需要任何操作。 在 Fusaka 升级后，你的 ETH 无需转换或升级。账户余额保持不变，你现有的 ETH 会如常可用。
• 警惕诈骗！ 任何让你“升级 ETH”的人都是诈骗。 你无需针对本次升级执行任何操作。你的资产不会受到影响。 请保持警惕，信息透明是防诈骗的最好方式。

了解更多如何识别与避免诈骗

为什么是斑马？

斑马是 Fusaka 的开发者选定的“吉祥物”，因为它的条纹象征着 PeerDAS 的列式数据可用性采样（column-based DAS）—— 节点各自保存部分列子网，并从每个对等节点的 slot 中采样几列数据，以验证 blob 数据是否可用。

2022 年的 The Merge（合并） 以熊猫作为吉祥物，象征执行层与共识层的结合。从那以后，每次分叉都会非正式地选定一个吉祥物，并在客户端日志中以 ASCII 艺术的形式出现，以示庆祝。

这次升级对 L2 扩展有什么改进？

PeerDAS 是本次分叉的主要特性。 它实现了数据可用性采样（DAS），大幅提升 rollup 的可扩展性，理论上可将 blob 空间扩大至当前的 8 倍。 同时，blob 手续费市场也将得到改进，使其能更高效地应对网络拥堵，并确保 L2 为节点所消耗的计算与存储资源支付合理费用。

什么是 BPO 分叉？

Blob Only Parameter（BPO）分叉 提供一种机制，使得在 PeerDAS 激活后，可以持续增加 blob 数量（目标值与最大值），而无需等待完整的协调性升级。每次增加的参数都将在支持 Fusaka 的客户端版本中预设。

作为用户或验证者，你无需为每次 BPO 更新客户端——只需关注像 Fusaka 这样的主要硬分叉即可。这与之前的做法相同。当然，仍建议在升级与 BPO 期间监控客户端状态，并在主要版本之间保持更新，以获取修复与性能优化。

BPO 的时间表是什么？

BPO 更新的具体时间表将在 Fusaka 发布时确定。 你可以关注 协议公告 以及客户端的发布说明以获取最新信息。

示例时间线如下：

• Fusaka 前：target = 6，max = 9
• Fusaka 激活时：target = 6，max = 9
• BPO1（Fusaka 激活后几周）：target = 10，max = 15（增长约 2/3）
• BPO2（BPO1 后几周）：target = 14，max = 21

此升级会降低以太坊（L1）手续费吗？

不会直接降低 L1 的 Gas 费。 本次升级的主要目标是为 rollup 扩充 blob 空间，从而降低 L2 成本。 这可能会对 L1 的费用市场产生一定间接影响，但不会有显著变化。

作为质押者，我需要为这次升级做什么？

与每次网络升级一样，请务必将你的客户端更新至带有 Fusaka 支持 标记的最新版本。 请关注邮件列表中的更新，以及 以太坊基金会博客上的协议公告，以便及时了解发布情况。

在 Fusaka 主网上线之前，你可以在测试网上运行验证者来验证自己的设置。 Fusaka 通常会先在测试网激活，这给你提供了充足的时间来确认一切运作正常并报告潜在问题。 测试网分叉同样会在邮件列表与博客中公布。

“确定性提议者预览”（EIP-7917）会影响验证者吗？

该更改不会改变验证者客户端的基本功能，但它会让你对验证者的未来职责有更清晰的了解。请确保你的监控工具能支持这一新特性。

Fusaka 升级对节点与验证者的带宽需求有何影响？

PeerDAS 改变了节点传输 blob 数据的方式。所有数据会被分割为称为“列”（columns）的碎片，分布在 128 个子网（subnets） 中，每个节点只订阅其中部分子网。

节点必须保管的子网列数量取决于其配置与所连接的验证者数量。 实际带宽需求取决于网络中允许的 blob 数量及节点类型。

在 Fusaka 激活时，blob 的目标数量与之前相同，但由于 PeerDAS 的引入，节点运营者可能会看到 blob 磁盘占用与网络流量的下降。 随着后续 BPO（Blob Parameter Only） 逐步提高网络中的 blob 数量， 每次 BPO 都会相应增加所需带宽。

即使在 Fusaka BPO 之后，节点需求仍处于推荐范围内。

完整节点（Full nodes）

普通节点（未运行验证者）只会订阅 4 个子网，仅保管原始数据的 1/8。这意味着相同数量的 blob 数据下，下载带宽需求会减少 8 倍。 普通完整节点的 blob 磁盘占用和下载带宽预计可减少约 80%，仅需数兆字节级别。

独立质押者（Solo stakers）

若节点同时运行验证者客户端，它需要保管更多列，从而处理更多数据。 加入验证者后，节点至少订阅 8 个子网列，因此数据量约为普通节点的两倍， 但仍比 Fusaka 之前更少。当验证者余额超过 287 ETH 时，节点会订阅更多子网。

对独立质押者而言，这意味着磁盘占用与下载带宽将减少约 50%。 但由于需本地构建区块并上传所有 blob 到网络，上传带宽需求将显著增加。 在 Fusaka 激活时，本地构建者需要比之前高出 2–3 倍 的上传带宽；当达到 BPO2（15/21 blobs） 目标时，上传带宽需求将提升至约 5 倍，即 100 Mbps。

大型验证者（Large validators）

随着节点余额与验证者数量增加，订阅的子网数量也会增长。例如，当余额约为 800 ETH 时，节点需保管 25 列，下载带宽需求约比原先高 30%，上传带宽同样增加，至少需要 100 Mbps。

当余额达到 4096 ETH（即两个满额验证者）时，节点成为 超级节点（supernode），需保管所有列，也就是下载并存储全部数据。 这类节点通过回传缺失数据来积极修复网络，但同时需要更多带宽与存储。 在最终 blob 目标提高至原先的 6 倍时，超级节点需额外存储约 600GB blob 数据，并维持 约 20 Mbps 的持续下载带宽。

阅读更多关于节点需求的详细信息

Fusaka 引入了哪些 EVM 变化？

Fusaka 通过一些小幅改动与功能增强进一步稳固 EVM：

• 为了在扩容时提升安全性，单笔交易的最大大小将被限制为 1670 万 Gas 单位。
• 增加了新的操作码 count leading zeros (CLZ)， 允许智能合约语言更高效地执行某些运算。
• ModExp 预编译合约的成本将上调， 使用它的合约将消耗更多 Gas。

新的 1670 万 Gas 限制对合约开发者有何影响？

Fusaka 将单笔交易的最大 Gas 限制设定为 1670 万（2^24）， 大约相当于一个普通区块的容量。 这足以容纳复杂交易，但能防止单个交易占满整个区块。 此限制有助于保护客户端，防止未来在更高区块 Gas 上限下的潜在 DoS 攻击。 扩容的目标是让更多交易能同时进入区块链，而不是让某一笔交易独占区块。

普通用户交易远未达到此限制。 但某些边界情况可能受影响，例如大型 DeFi 操作、复杂智能合约部署或批量多合约调用。 这些交易需拆分成更小的部分或进行优化。 在提交可能接近此上限的交易前，请使用模拟进行验证。

RPC 方法 eth_call 不受此限制，可模拟超过实际链上限制的交易。 客户端运营者可自定义 RPC 限制，以防止滥用。

CLZ 对开发者意味着什么？

EVM 编译器（如 Solidity）会在底层实现并利用新的“计数前导零”函数。 依赖此类运算的新合约可能节省一定 Gas。 请关注智能合约语言的后续版本与功能公告，了解潜在收益。

现有智能合约会受影响吗？

Fusaka 不会直接破坏任何现有合约或改变其行为。 执行层的改动保持向后兼容。 但仍应关注边界情况与潜在影响。

由于ModExp 预编译成本上升，依赖该功能的合约在执行时将消耗更多 Gas。 若你的合约对此依赖较重、导致用户成本上升，可考虑调整实现方式。

此外，若执行你的合约的交易可能接近新的 1670 万 Gas 限制，请提前优化。

延伸阅读（Further reading）

• 以太坊路线图
• Forkcast: Fusaka
• Fusaka Meta EIP
• Fusaka 测试网公告
• Bankless: Fusaka 与 Pectra 将为以太坊带来什么
• Bankless 访谈：以太坊的下一个升级 — Fusaka、Glamsterdam 及未来（与 Preston Van Loon）

是否希望我帮你把整篇 Fusaka 中文版（包含前后所有部分）整理成一份可发布的完整文档（带目录、统一格式）？

• 本文转载自： ethereum.org/zh/roadmap/... , 如有侵权请联系管理员删除。