以太坊 Fusaka 升级里的「无级变速」：建立 L2 扩容的快速响应机制

撰文：Zhixiong Pan

背景：Gas Limit 升级无需硬分叉

在 Fusaka 升级之前，以太坊协议层绝大多数核心参数（如区块奖励、难度调整算法等）都被「硬编码」在客户端软件中。这意味着，哪怕只是想修改一个数值，也必须经历漫长的 EIP 提案、测试网演练，并协调全网节点进行一次大规模的硬分叉（Hard Fork），这通常需要半年甚至更久的周期。

在此之前，以太坊协议中唯一的例外是 Block Gas Limit（区块 Gas 上限）。 Gas Limit 并不由硬分叉决定，而是允许验证者（Validators）在打包区块时，通过算法进行微小的调整（比如今年从 30M 提升至 60M）。这种机制赋予了网络一定的弹性。

EIP-7892，BPO（Blob Parameter Only）的出现，正是为了将这种弹性扩展到数据领域。它把 Blob 的关键参数做成了配置驱动，并通过 BPO 这种「只改参数、不改代码」的轻量化硬分叉来生效。从客户端开发的角度看，几乎就像是在做一次参数热更新。

它让以太坊在扩容问题上，摆脱了「每次想调 Blob 数都得等下一次大型硬分叉」的节奏，可以通过小号 BPO 分叉更频繁地调参。

本次调整的核心对象是 Blob。自从坎昆升级（Dencun）之后，大多数 Rollup 不再把大部分交易数据写进昂贵的 calldata，而是迁移到了 Blob 这个专门的「临时数据挂载区」。

Blob 的经济学逻辑非常简单：Blob 是稀缺资源，每个区块能挂载的 Blob 数量是有限的。它的价格来源于供需关系，当 Layer 2 的需求超过供应时，Blob 的单位价格就会增加，导致 L2 手续费变贵。

因此，在保证安全的前提下，尽可能提高 Blob 的数量上限，是降低 L2 用户成本最直接的手段。

在 BPO 的调整计划中，可以看到有两个成对出现的数字（例如 10/15）。这是基于 EIP-4844 机制设定的两个关键阈值：

这是以太坊设定的理想负载量。系统会根据这个值动态调整 Blob 的基础费用（Base Fee）。如果实际使用量 > Target，费用上涨以抑制需求；如果实际使用量 < Target，费用下降。

它决定了网络在正常状态下的吞吐能力和费率基准。

这是为了防止网络瘫痪而设定的物理硬上限。无论需求多高，协议强制规定单个区块包含的 Blob 数量不得超过此值，以防止节点因处理过大数据而宕机或掉线。

它是网络承载能力的极限天花板。

另外，从 Pectra 之后，主网的 blob 参数基本遵守「Max = 1.5 × Target」的模式：6/9、10/15、14/21，都是这个比例。

本次扩容并非在 12 月 3 日一步到位，而是采用了一个严谨的「先部署技术，后释放容量」的三阶段策略：

参数状态：Target: 6 / Max: 9（与之前的 Pectra 版本保持一致，无变化）。

Fusaka 升级激活了 PeerDAS（数据可用性采样）这一核心技术。虽然技术上具备了处理更多数据的能力，但为了安全起见，开发者选择在升级首日不增加网络负荷。这是一个「安全观察期」，用于验证 PeerDAS 机制在现有流量下的稳定性。

参数调整：Target: 10 / Max: 15

在 PeerDAS 稳定运行约一周后，通过 BPO 机制进行首次热更新。目标值从 6 提升至 10。这是 Fusaka 周期内的第一次实质性扩容。

参数调整：Target: 14 / Max: 21

在经过一个月的充分压力测试后，进行第二次热更新。相比于 Fusaka 上线时，容量翻了 2.3 倍（6 → 14）。这标志着本次扩容计划的完全落地。

BPO 的引入是里程碑式的。它打破了「每次扩 Blob 都要等一场大型功能硬分叉」的旧范式，把扩容拆成了一系列只改参数的迷你硬分叉。

这意味着，未来的以太坊就像安装了一个「无级变速箱」，以后扩 Blob 不必和大版本强绑定，可以根据 L2 需求和客户端性能，每隔一段时间规划 BPO3、BPO4，用更密集的小步硬分叉来调优吞吐，而不是几年才改一次。

撰文：Zhixiong Pan

它让以太坊在扩容问题上，摆脱了「每次想调 Blob 数都得等下一次大型硬分叉」的节奏，可以通过小号 BPO 分叉更频繁地调参。

因此，在保证安全的前提下，尽可能提高 Blob 的数量上限，是降低 L2 用户成本最直接的手段。