---
title: "弗萨卡 🦓"
metaTitle: Fulu-Osaka (弗萨卡)
description: 了解弗萨卡协议升级
lang: zh
template: upgrade
authors: ["Nixo", "Mario Havel"]
---

**以太坊备受期待的弗萨卡升级已于 2025 年 12 月 3 日上线**

弗萨卡网络升级紧随[佩克特拉](/roadmap/pectra/)之后，带来了更多新功能，并改善了每位[以太坊](/)用户和开发者的体验。该名称由执行层升级 Osaka（大阪）和以 Fulu（附路星）命名的共识层版本组成。以太坊的这两个部分都得到了升级，将以太坊的扩展性、安全性和用户体验推向未来。

<Alert variant="update">
<AlertContent>
<AlertDescription>
弗萨卡升级只是以太坊长期发展目标中的一步。了解更多关于[协议路线图](/roadmap/)和[以往升级](/ethereum-forks/)的信息。
</AlertDescription>
</AlertContent>
</Alert>

<VideoWatch slug="fusaka-upgrade-explained" />

## 弗萨卡升级的改进 {#improvements-in-fusaka}

### 扩展斑点 {#scale-blobs}

#### PeerDAS {#peerdas}

这是弗萨卡分叉的_重头戏_，也是本次升级中添加的主要功能。二层网络 (l2) 目前以斑点的形式将其数据发布到以太坊，斑点是专门为二层网络 (l2) 创建的临时数据类型。在弗萨卡之前，每个全节点都必须存储每个斑点以确保数据存在。随着斑点吞吐量的上升，必须下载所有这些数据变得极其消耗资源，令人难以承受。

借助[数据可用性采样](https://notes.ethereum.org/@fradamt/das-fork-choice)，每个节点将只负责斑点数据的一个子集，而无需存储所有斑点数据。斑点在网络中的节点之间均匀随机分布，每个全节点仅保存 1/8 的数据，从而在理论上实现了高达 8 倍的扩展。为了确保数据的可用性，可以使用将错误或丢失数据的概率降低到密码学上可忽略的水平（约 10<sup>20</sup> 分之一到 10<sup>24</sup> 分之一）的方法，从任何现有的 50% 整体数据中重建任何部分的数据。

这使得节点的硬件和带宽要求保持在合理范围内，同时实现了斑点扩展，从而为二层网络 (l2) 带来更大的扩展性和更低的费用。

[了解有关 PeerDAS 的更多信息](/roadmap/fusaka/peerdas/)

**资源**：

- [EIP-7594 技术规范](https://eips.ethereum.org/EIPS/eip-7594)
- [DappLion 谈 PeerDAS：今日扩展以太坊 | ETHSofia 2024](https://youtu.be/bONWd1x2TjQ?t=328)
- [学术：以太坊 PeerDAS 文档 (PDF)](https://eprint.iacr.org/2024/1362.pdf)

#### 仅斑点参数 (Blob-Parameter-Only) 分叉 {#blob-parameter-only-forks}

二层网络 (l2) 扩展了以太坊——随着其网络的发展，它们需要向以太坊发布更多数据。这意味着随着时间的推移，以太坊将需要增加可供它们使用的斑点数量。虽然 PeerDAS 能够扩展斑点数据，但这需要逐步且安全地进行。

因为以太坊是在数千个独立节点上运行的代码，这些节点需要就相同的规则达成共识，所以我们不能像部署网站更新那样简单地引入增加斑点数量等更改。任何规则更改都必须是一次协调升级，其中每个节点、客户端和验证者软件都在同一个预定区块之前进行升级。

这些协调升级通常包含大量更改，需要大量测试，而这需要时间。为了更快地适应不断变化的二层网络 (l2) 斑点需求，仅斑点参数分叉引入了一种增加斑点的机制，而无需等待该升级计划。

仅斑点参数分叉可以由客户端设置，类似于 gas 上限等其他配置。在以太坊的重大升级之间，客户端可以同意将 `target` 和 `max` 斑点增加到例如 9 和 12，然后节点运营商将进行更新以参与这个微小的分叉。这些仅斑点参数分叉可以随时配置。

在登昆升级中首次将斑点添加到网络时，目标是 3。在佩克特拉中增加到了 6，而在弗萨卡之后，现在可以独立于这些重大网络升级以可持续的速度增加。

![Chart showing average blob count per block and increasing targets with upgrades](./average-blob-count-per-block.webp)

图表来源：[Ethereum Blobs - @hildobby, Dune Analytics](https://dune.com/hildobby/blobs)

**资源**：[EIP-7892 技术规范](https://eips.ethereum.org/EIPS/eip-7892)

#### 受执行成本限制的 blob 基础费用 {#blob-base-fee-bounded-by-execution-costs}

二层网络 (l2) 在发布数据时需要支付两笔费用：blob 费用和验证这些斑点所需的执行 Gas。如果执行 Gas 占主导地位，blob 费用拍卖可能会螺旋下降至 1 Wei，并失去作为价格信号的作用。

EIP-7918 在每个斑点下固定了一个成比例的保留价格。当保留价格高于名义 blob 基础费用时，费用调整算法会将该区块视为超出目标，停止压低费用并允许其正常增加。因此：

- blob 费用市场始终对拥堵做出反应
- 二层网络 (l2) 至少为它们强加给节点的计算支付了有意义的一部分费用
- 执行层 (EL) 上的基础费用飙升不再会使 blob 费用停滞在 1 Wei

**资源**：

- [EIP-7918 技术规范](https://eips.ethereum.org/EIPS/eip-7918)
- [Storybook 讲解](https://notes.ethereum.org/@anderselowsson/AIG)

### 扩展一层网络 (l1) {#scale-l1}

#### 历史数据过期和更简单的收据 {#history-expiry}

2025 年 7 月，以太坊执行客户端[开始支持部分历史数据过期](https://blog.ethereum.org/2025/07/08/partial-history-exp)。这丢弃了早于[合并](https://ethereum.org/roadmap/merge/)的历史记录，以便在以太坊不断发展的同时减少节点运营商所需的磁盘空间。

此 EIP 位于“核心 EIP”之外的部分，因为该分叉实际上并未实施任何更改——它是一个通知，要求客户端团队必须在弗萨卡升级前支持历史数据过期。实际上，客户端可以随时实施此功能，但将其添加到升级中具体地将其列入了他们的待办事项列表，并使他们能够结合此功能测试弗萨卡的更改。

**资源**：[EIP-7642 技术规范](https://eips.ethereum.org/EIPS/eip-7642)

#### 为 MODEXP 设置上限 {#set-upper-bounds-for-modexp}

到目前为止，MODEXP 预编译合约几乎接受任何大小的数字。这使得它难以测试、容易被滥用，并对客户端稳定性构成风险。EIP-7823 设定了明确的限制：每个输入数字最长只能是 8192 位（1024 字节）。任何更大的数字都会被拒绝，交易的 Gas 会被销毁，并且不会发生任何状态更改。它非常轻松地满足了现实世界的需求，同时消除了使 gas 上限规划和安全审查复杂化的极端情况。此更改提供了更高的安全性和 DoS 保护，而不会影响用户或开发者体验。

**资源**：[EIP-7823 技术规范](https://eips.ethereum.org/EIPS/eip-7823)

#### 交易 gas 上限封顶 {#transaction-gas-limit-cap}

EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) 增加了每笔交易 16,777,216 (2^24) Gas 的上限。这是主动的 DoS 加固，通过在我们提高区块 gas 上限时限制任何单笔交易的最坏情况成本来实现。它使验证和传播更容易建模，从而允许我们通过提高 gas 上限来解决扩展问题。

为什么恰好是 2^24 Gas？它远小于今天的 gas 上限，足以满足实际合约部署和繁重的预编译合约需求，而且 2 的幂使其易于在各个客户端中实现。这个新的最大交易大小类似于佩克特拉之前的平均区块大小，使其成为以太坊上任何操作的合理限制。

**资源**：[EIP-7825 技术规范](https://eips.ethereum.org/EIPS/eip-7825)

#### `MODEXP` Gas 成本增加 {#modexp-gas-cost-increase}

MODEXP 是一个预编译合约内置函数，用于计算模幂运算，这是一种用于 RSA 签名验证和证明系统的大数数学。它允许合约直接运行这些计算，而无需自己实现它们。

开发者和客户端团队将 MODEXP 视为提高区块 gas 上限的主要障碍，因为当前的 Gas 定价通常低估了某些输入所需的计算能力。这意味着一笔使用 MODEXP 的交易可能会占用处理整个区块所需的大部分时间，从而减慢网络速度。

此 EIP 通过以下方式更改定价以匹配实际计算成本：

- 将最低收费从 200 Gas 提高到 500 Gas，并在一般成本计算中取消 EIP-2565 的三分之一折扣
- 当指数输入非常长时，更大幅度地增加成本。如果指数（作为第二个参数传递的“幂”数）长于 32 字节 / 256 位，则每增加一个字节，Gas 收费的攀升速度就会快得多
- 对较大的底数或模数也收取额外费用。其他两个数字（底数和模数）假定至少为 32 字节——如果其中任何一个更大，成本将按其大小成比例上升

通过更好地将成本与实际处理时间相匹配，MODEXP 不再会导致区块验证时间过长。此更改是旨在确保未来安全提高以太坊区块 gas 上限的几项更改之一。

**资源**：[EIP-7883 技术规范](https://eips.ethereum.org/EIPS/eip-7883)

#### RLP 执行区块大小限制 {#rlp-execution-block-size-limit}

这为允许的区块大小设定了上限——这是对通过网络_发送_的内容的限制，并且独立于限制区块内_工作量_的 gas 上限。区块大小上限为 10 MiB，其中保留了少量余量 (2 MiB) 用于共识数据，以便所有内容都能完美契合和传播。如果出现的区块大于该值，客户端将拒绝它。
这是必要的，因为非常大的区块需要更长的时间在网络中传播和验证，并且可能会产生共识问题或被滥用为 DoS 攻击媒介。此外，共识层的 gossip 协议已经不会转发超过约 10 MiB 的区块，因此将执行层与该限制对齐可以避免出现“一些人看到，另一些人丢弃”的奇怪情况。

具体细节：这是对 [RLP](/developers/docs/data-structures-and-encoding/rlp/) 编码的执行区块大小的上限。总共 10 MiB，其中 2 MiB 的安全裕度保留给信标区块成帧。实际上，客户端定义了

`MAX_BLOCK_SIZE = 10,485,760` 字节和

`SAFETY_MARGIN = 2,097,152` 字节，

并拒绝任何 RLP 有效负载超过以下值的执行区块：

`MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN`

目标是限制最坏情况下的传播/验证时间，并与共识层 gossip 行为保持一致，在不改变 Gas 记账的情况下降低重组/DoS 风险。

**资源**：[EIP-7934 技术规范](https://eips.ethereum.org/EIPS/eip-7934)

#### 将默认 gas 上限设置为 6000 万 {#set-default-gas-limit-to-60-million}

在 2025 年 2 月将 gas 上限从 3000 万提高到 3600 万（随后提高到 4500 万）之前，该值自合并（2022 年 9 月）以来一直没有改变。此 EIP 旨在将持续扩展作为优先事项。

EIP-7935 协调执行层 (EL) 客户端团队，在弗萨卡升级中将默认 gas 上限提高到目前 4500 万以上。这是一个信息性 EIP，但它明确要求客户端在开发网上测试更高的上限，收敛到一个安全值，并在其弗萨卡版本中发布该数字。

开发网规划的目标是约 6000 万的压力（具有合成负载的满区块）和迭代提升；研究表明，最坏情况下的区块大小病态不应在约 1.5 亿以下受到限制。推出应与交易 gas 上限封顶 (EIP-7825) 相结合，以便在上限提高时，没有任何单笔交易可以占据主导地位。

**资源**：[EIP-7935 技术规范](https://eips.ethereum.org/EIPS/eip-7935)

### 改善用户体验 (UX) {#improve-ux}

#### 确定性提议者前瞻 {#deterministic-proposer-lookahead}

借助 EIP-7917，信标链将能够感知下一个时段即将到来的区块提议者。对哪些验证者将提议未来区块拥有确定性的视图，可以实现[预确认](https://ethresear.ch/t/based-preconfirmations/17353)——这是一种与即将到来的提议者达成的承诺，保证用户交易将包含在他们的区块中，而无需等待实际区块。

此功能有利于客户端实现和网络安全，因为它防止了验证者可能操纵提议者时间表的边缘情况。前瞻还降低了实现的复杂性。

**资源**：[EIP-7917 技术规范](https://eips.ethereum.org/EIPS/eip-7917)

#### 计算前导零 (CLZ) 操作码 {#count-leading-zeros-opcode}

此功能添加了一个小型的 EVM 指令：**计算前导零 (CLZ)**。EVM 中的几乎所有内容都表示为 256 位值——这个新的操作码返回前面有多少个零位。这是许多指令集架构中的常见功能，因为它能够实现更高效的算术运算。在实践中，这将当今手动编写的位扫描折叠为一个步骤，因此查找第一个设置位、扫描字节或解析位段变得更简单、更便宜。该操作码成本低且固定，经基准测试与基本加法相当，这削减了字节码并为相同的工作节省了 Gas。

**资源**：[EIP-7939 技术规范](https://eips.ethereum.org/EIPS/eip-7939)

#### 支持 secp256r1 曲线的预编译合约 {#secp256r1-precompile}

在固定地址 `0x100` 引入了一个内置的、通行密钥风格的 secp256r1 (P-256) 签名检查器，使用许多二层网络 (l2) 已经采用的相同调用格式并修复了边缘情况，因此为这些环境编写的合约可以在一层网络 (l1) 上无需更改即可工作。

用户体验升级！对于用户而言，这解锁了设备原生签名和通行密钥。钱包可以直接利用 Apple Secure Enclave、Android 密钥库、硬件安全模块 (HSM) 和 FIDO2/WebAuthn——无需助记词，用户引导更顺畅，并且多因素流程感觉就像现代应用程序一样。这带来了更好的用户体验、更轻松的恢复以及与数十亿设备已经执行的操作相匹配的账户抽象模式。

对于开发者而言，它接受 160 字节的输入并返回 32 字节的输出，从而可以轻松移植现有库和二层网络 (l2) 合约。在内部，它包括无穷远点和模比较检查，以消除棘手的边缘情况，而不会破坏有效的调用者。

**资源**：

- [EIP-7951 技术规范](https://eips.ethereum.org/EIPS/eip-7951)
- [关于 RIP-7212 的更多信息](https://www.alchemy.com/blog/what-is-rip-7212) _（请注意，EIP-7951 已取代 RIP-7212）_

### 元数据 (Meta) {#meta}

#### `eth_config` JSON-RPC 方法 {#eth-config}

这是一个 JSON-RPC 调用，允许您询问您的节点正在运行什么分叉设置。它返回三个快照：`current`、`next` 和 `last`，以便验证者和监控工具可以验证客户端是否已为即将到来的分叉做好准备。

实际上，这是为了解决 2025 年初佩克特拉分叉在 Holesky 测试网上线时发现的一个缺点，当时轻微的配置错误导致了无法最终确定的状态。这有助于测试团队和开发者确保在从开发网转移到测试网，以及从测试网转移到主网时，主要分叉将按预期运行。

快照包括：`chainId`、`forkId`、计划的分叉激活时间、哪些预编译合约处于活动状态、预编译合约地址、系统合约依赖项以及分叉的斑点时间表。

此 EIP 位于“核心 EIP”之外的部分，因为该分叉实际上并未实施任何更改——它是一个通知，要求客户端团队必须在弗萨卡升级前实现此 JSON-RPC 方法。

**资源**：[EIP-7910 技术规范](https://eips.ethereum.org/EIPS/eip-7910)

## 常见问题解答 {#faq}

### 此次升级是否会影响所有以太坊节点和验证者？ {#does-this-upgrade-affect-all-ethereum-nodes-and-validators}

是的，弗萨卡升级需要更新[执行客户端和共识客户端](/developers/docs/nodes-and-clients/)。所有主要的以太坊客户端都将发布支持该硬分叉的版本，并标记为高优先级。您可以在客户端的 GitHub 存储库、他们的 [Discord 频道](https://ethstaker.org/support)、[EthStaker Discord](https://dsc.gg/ethstaker) 中了解这些版本何时可用，或者通过订阅以太坊博客以获取协议更新。为了在升级后保持与以太坊网络的同步，节点运营商必须确保他们运行的是受支持的客户端版本。请注意，有关客户端发布的信息具有时效性，用户应参考最新更新以获取最新详细信息。

### 硬分叉后如何转换 ETH？ {#how-can-eth-be-converted-after-the-hardfork}

- **您的 ETH 无需任何操作**：在以太坊弗萨卡升级之后，无需转换或升级您的 ETH。您的账户余额将保持不变，并且您目前持有的 ETH 在硬分叉后仍将以其现有形式可供访问。
- **谨防诈骗！** <Emoji text="⚠️" /> **任何指示您“升级”您的 ETH 的人都是在试图诈骗您。** 关于此次升级，您无需执行任何操作。您的资产将完全不受影响。请记住，保持知情是防范诈骗的最佳方法。

[有关识别和避免诈骗的更多信息](/security/)

### 斑马是怎么回事？ <Emoji text="🦓" /> {#whats-with-the-zebras}

斑马是开发者为弗萨卡选择的“吉祥物”，因为它的条纹反映了 PeerDAS 基于列的数据可用性采样，其中节点托管某些列子网，并从每个对等节点的时隙中采样一些其他列，以检查斑点数据是否可用。

2022 年的合并[使用熊猫](https://x.com/hwwonx/status/1431970802040127498)作为其吉祥物，以标志执行层和共识层的结合。从那时起，每个分叉都会非正式地选择吉祥物，并在升级时以 ASCII 艺术的形式出现在客户端日志中。这只是一种有趣的庆祝方式。

### 包含哪些针对二层网络 (l2) 扩展的改进？ {#what-improvements-are-included-for-l2-scaling}

[PeerDAS](/roadmap/fusaka/peerdas) 是该分叉的主要功能。它实现了数据可用性采样 (DAS)，为汇总解锁了更多的可扩展性，理论上将斑点空间扩展到当前大小的 8 倍。blob 费用市场也将得到改善，以有效应对拥堵，并保证二层网络 (l2) 为斑点强加给节点的计算和空间支付有意义的费用。

### BPO 分叉有何不同？ {#how-are-bpo-forks-different}

仅斑点参数 (Blob Only Parameter) 分叉提供了一种机制，在 PeerDAS 激活后持续增加斑点数量（目标值和最大值），而无需等待全面的协调升级。每次增加都被硬编码为在支持弗萨卡的客户端版本中预先配置。

作为用户或验证者，您无需为每个 BPO 更新您的客户端，只需确保遵循像弗萨卡这样的主要硬分叉即可。这与以前的做法相同，不需要采取特殊行动。仍然建议在升级和 BPO 期间监控您的客户端，并在主要版本之间保持更新，因为硬分叉后可能会有修复或优化。

### BPO 时间表是什么？ {#what-is-the-bpo-schedule}

BPO 更新的确切时间表将随弗萨卡版本一起确定。请关注[协议公告](https://blog.ethereum.org/category/protocol)和您客户端的发行说明。

它可能看起来像这样的示例：

- 弗萨卡之前：目标 6，最大 9
- 弗萨卡激活时：目标 6，最大 9
- BPO1，弗萨卡激活几周后：目标 10，最大 15，增加三分之二
- BPO2，BPO1 几周后：目标 14，最大 21

### 这会降低以太坊（一层网络 (l1)）上的费用吗？ {#will-this-lower-gas}

此次升级不会降低一层网络 (l1) 上的 Gas 费用，至少不会直接降低。主要重点是为 Rollup 数据提供更多斑点空间，从而降低二层网络 (l2) 上的费用。这可能会对一层网络 (l1) 费用市场产生一些副作用，但预计不会有重大变化。

### 作为质押者，我需要为升级做些什么？ {#as-a-staker-what-do-i-need-to-do-for-the-upgrade}

与每次网络升级一样，请确保将您的客户端更新到标记为支持弗萨卡的最新版本。关注邮件列表中的更新和[以太坊基金会博客上的协议公告](https://blog.ethereum.org/category/protocol)，以了解有关发布的信息。
要在弗萨卡在主网上激活之前验证您的设置，您可以在测试网上运行验证者。弗萨卡会[更早在测试网上激活](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement)，为您提供更多空间来确保一切正常运行并报告错误。测试网分叉也会在邮件列表和博客中宣布。

### “确定性提议者前瞻” (EIP-7917) 会影响验证者吗？ {#does-7917-affect-validators}

此更改不会改变您的验证者客户端的运行方式，但是，它将提供对您未来验证者职责的更多洞察。请确保更新您的监控工具以跟上新功能。

### 弗萨卡如何影响节点和验证者的带宽要求？ {#how-does-fusaka-affect-bandwidth-requirements-for-nodes-and-validators}

PeerDAS 对节点传输斑点数据的方式进行了重大更改。所有数据被分成称为列的片段，分布在 128 个子网中，节点仅订阅其中一些子网。节点必须托管的子网列数量取决于其配置和连接的验证者数量。实际的带宽要求将取决于网络中允许的斑点数量和节点类型。在弗萨卡激活时，斑点目标保持与以前相同，但借助 PeerDAS，节点运营商可以看到其斑点的磁盘使用量和网络流量有所减少。随着 BPO 在网络中配置更多数量的斑点，所需的带宽将随着每个 BPO 的增加而增加。

即使在弗萨卡 BPO 之后，节点要求仍处于[推荐的范围内](https://eips.ethereum.org/EIPS/eip-7870)。

#### 全节点 {#full-nodes}

没有任何验证者的常规节点将仅订阅 4 个子网，为 1/8 的原始数据提供托管。这意味着在斑点数据量相同的情况下，节点下载它们的带宽将缩小八 (8) 倍。普通全节点的斑点磁盘使用量和下载带宽可能会减少约 80%，降至仅几 Mb。

#### 独立质押者 {#solo-stakers}

如果节点用于验证者客户端，它必须托管更多列，因此处理更多数据。添加验证者后，节点至少订阅 8 个列子网，因此处理的数据量是常规节点的两倍，但仍少于弗萨卡之前。如果验证者余额高于 287 ETH，将订阅越来越多的子网。

对于独立质押者来说，这意味着他们的磁盘使用量和下载带宽将减少约 50%。然而，要在本地构建区块并将所有斑点上传到网络，则需要更多的上传带宽。在弗萨卡时期，本地构建者将需要比以前高 2-3 倍的上传带宽，而在 BPO2 目标为 15/21 个斑点的情况下，最终所需的上传带宽将必须高出约 5 倍，达到 100Mbps。

#### 大型验证者 {#large-validators}

订阅的子网数量随着节点中添加的余额和验证者的增加而增长。例如，在余额约为 800 ETH 时，节点托管 25 列，并且将需要比以前多约 30% 的下载带宽。所需的上传带宽与常规节点类似地上升，至少需要 100Mbps。

在 4096 ETH（2 个最大余额验证者）时，节点成为“超级节点”，托管所有列，因此下载并存储所有内容。这些节点通过将丢失的数据贡献回来来主动修复网络，但也需要更多的带宽和存储空间。由于最终的斑点目标比以前高 6 倍，超级节点将必须存储约 600GB 的额外斑点数据，并具有约 20Mbps 的更快持续下载带宽。

[阅读有关预期要求的更多详细信息。](https://ethpandaops.io/posts/fusaka-bandwidth-estimation/#theoretical-requirements)

### 实施了哪些 EVM 更改？ {#what-evm-changes-are-implemented}

弗萨卡通过新的微小更改和功能巩固了 EVM。

- 为了在扩展时保证安全，单笔交易的最大大小将[限制为 1670 万](https://eips.ethereum.org/EIPS/eip-7825) Gas 单位。
- EVM 中添加了[新的操作码计算前导零 (CLZ)](https://eips.ethereum.org/EIPS/eip-7939)，这将使智能合约语言能够更高效地执行某些操作。
- [`ModExp` 预编译合约的成本将增加](https://eips.ethereum.org/EIPS/eip-7883)——使用它的合约在执行时将收取更多 Gas。

### 新的 1600 万 gas 上限如何影响合约开发者？ {#how-does-new-16m-gas-limit-affects-contract-developers}

弗萨卡引入了将[单笔交易的最大大小限制为 1670 万](https://eips.ethereum.org/EIPS/eip-7825) (2^24) Gas 单位的限制。这大致是以前平均区块的大小，这使其足够大，可以容纳会消耗整个区块的复杂交易。此限制为客户端提供了保护，防止未来在更高的区块 gas 上限下发生潜在的 DoS 攻击。扩展的目标是使更多交易进入区块链，而不会出现单笔交易消耗整个区块的情况。

普通用户交易远未达到此限制。某些边缘情况，如庞大且复杂的去中心化金融 (DeFi) 操作、大型智能合约部署或针对多个合约的批量交易，可能会受到此更改的影响。这些交易将必须被划分为更小的交易或以其他方式进行优化。在提交可能达到限制的交易之前，请使用模拟。

RPC 方法 `eth_call` 不受限制，将允许模拟比实际区块链限制更大的交易。RPC 方法的实际限制可以由客户端运营商配置，以确保防止滥用。

### CLZ 对开发者意味着什么？ {#what-clz-means-for-developers}

像 Solidity 这样的 EVM 编译器将在底层实现并利用用于计算零的新函数。如果新合约依赖于此类操作，它们可能会从节省的 Gas 中受益。请关注智能合约语言的发布和功能公告，以获取有关潜在节省的文档。

### 我现有的智能合约会有任何更改吗？ {#what-clz-means-for-developers-2}

弗萨卡没有会破坏任何现有合约或改变其行为的直接影响。引入执行层的更改具有向后兼容性，但是，请始终关注边缘情况和潜在影响。

[随着 `ModExp` 预编译合约成本的增加](https://eips.ethereum.org/EIPS/eip-7883)，依赖它的合约在执行时将消耗更多 Gas。如果您的合约严重依赖于此并且对用户来说变得更加昂贵，请重新考虑如何利用它。

如果执行您合约的交易可能达到类似大小，请考虑[新的 1670 万限制](https://eips.ethereum.org/EIPS/eip-7825)。

## 延伸阅读 {#further-reading}

- [以太坊路线图](/roadmap/)
- [Forkcast：弗萨卡](https://forkcast.org/upgrade/fusaka)
- [弗萨卡元数据 EIP](https://eips.ethereum.org/EIPS/eip-7607)
- [弗萨卡测试网博客公告](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement)
- [Bankless：弗萨卡和佩克特拉将为以太坊带来什么](https://www.bankless.com/read/what-fusaka-pectra-will-bring-ethereum)
- [Bankless：以太坊的下一次升级：弗萨卡、格拉姆斯特丹及更远未来（与 Preston Van Loon 访谈）](https://x.com/BanklessHQ/status/1956017743289020633?t=502)
- [弗萨卡档案](https://www.youtube.com/playlist?list=PL4cwHXAawZxpz-erUbKKUnnGoQNdF8s7Z)
- [PEEPanEIPs 讲解](https://www.youtube.com/playlist?list=PL4cwHXAawZxoIenfk7OJry4rxcqX-eqBt)
