Fusaka 之后的以太坊 Blob 市场：扩容已成为一项控制工程

0x6b970885c6Ee83A185D1396F884AF20e6B5f46bb
Published Oct 15, 2026

以太坊在 Fusaka 之后的数据可用性控制闭环示意图

以太坊不再要求每个节点搬运每一个字节来扩展 Rollup 数据。新的体系把抽样验证、分阶段调容与费用信号组合成一个必须协同运转的闭环。

研究日期：2026 年 10 月 15 日。 本文严格区分当前协议参数与有明确截止日期的历史观测；内容不构成投资建议。

执行摘要

2025 年 12 月 3 日激活的 Fusaka，与其说是一次性“增加 Blob 数量”的升级，不如说是以太坊重新设计了数据可用性这一稀缺资源的治理方式。PeerDAS 改变物理约束：普通节点无需完整下载所有 Blob，只需抽样部分数据，就能高置信度判断 Rollup 数据是否可用。仅调整 Blob 参数的 BPO 分叉改变运维节奏：网络可按预先写入客户端的步骤调整目标值与上限，不必每次等待下一次大型命名升级。EIP-7918 则修复经济反馈，避免 Blob 基础费与承载这些数据所消耗的执行成本长期脱节。

三者共同构成一套控制系统：Rollup 提交需求；以目标值为中心的费用机制反馈拥堵；开发者通过受监测的阶段逐步释放容量；分布式抽样避免单个节点负担与全网吞吐量一比一增长。结果相当可观：两次既定 BPO 完成后，以太坊从 Fusaka 前每区块目标 6 个、上限 9 个 Blob，提升至目标 14 个、上限 21 个。以太坊基金会在 2026 年 1 月的协议进展中将其概括为目标数据空间约 2.3 倍的提升。

早期证据既不支持盲目庆祝，也不支持悲观结论。一份可复现的主网回放显示，在 2026 年 8 月 6 日至 9 月 4 日的 30 天里，平均每区块为 5.2045 个 Blob，仅相当于 14 个目标值的 37.17%；但第 95 和第 99 百分位分别达到 14 与 19。也就是说，平均需求宽松，尾部却相当尖锐。样本中 4.41% 的区块超过目标，0.525% 触及 21 个的硬上限；任意连续 300 个区块的均值都没有超过 14。这不是持续稀缺，但也绝非没有市场——短促高峰已经会触及容量上沿。

本文的核心判断是：Fusaka 为以太坊赢得了一个运营窗口，而非永久解决扩容。廉价、充裕的 Blob 空间有利于 Rollup 生长，却会压低近期稀缺租金；抽样保护普通节点，但更高的总吞吐量仍会增加部分参与者的网络和存储责任；BPO 提高调容速度，却没有消除“何时扩容”所需的社会判断。机构应观察整个闭环的行为——利用率分布、高峰持续时间、费用响应、节点健康与需求集中度——而不应让单一 TPS 指标代替结论。

从产品发布转向持续运营

Blob 随 2024 年 3 月 Dencun 上线，是专为 Rollup 设计的临时数据容器。它把数据可用性费用从普通执行 Gas 中分离出来，让 Rollup 发布压缩交易数据时不再与一般交易竞价同一块空间。2025 年 5 月激活的 Pectra 将每区块目标从 3 提至 6、上限从 6 提至 9；Fusaka 随后提供继续扩展所需的架构前提。

Fusaka 官方概览确认主网在 2025 年 12 月 3 日激活。根据主网公告，第一次 BPO 于 12 月 9 日把参数提高到 10/15；第二次于 2026 年 1 月 7 日提高到 14/21。日期之所以重要，是因为“Fusaka 支持更多 Blob”掩盖了刻意设计的先后顺序：先启动抽样，观察网络，再以有界步骤增加容量。

timeline
    title 以太坊 Blob 容量阶梯
    2024 年 3 月 : Dencun 启用 Blob
                  : 目标 3，上限 6
    2025 年 5 月 : Pectra 提高容量
                  : 目标 6，上限 9
    2025 年 12 月 3 日 : Fusaka 启用 PeerDAS
                         : 参数暂时维持 6 与 9
    2025 年 12 月 9 日 : BPO1
                         : 目标 10，上限 15
    2026 年 1 月 7 日 : BPO2
                        : 目标 14，上限 21

这套顺序把“协议升级治理”变成“容量运营”。按照 EIP-7892，BPO 写入客户端配置，作用范围限于 Blob 相关参数。它仍需要共识与客户端就绪；“只改参数”并不等于无需治理。但范围更窄，确实降低了协同负担，也使观察、暂停和风险控制比把所有调整塞进低频大型升级更可信。

PeerDAS 为何改变扩容约束

Fusaka 之前，全节点需要下载区块附带的全部 Blob 数据才能检查其可用性。这意味着全网 Blob 吞吐量与单节点带宽负担同步增长。由 EIP-7594规范的 PeerDAS，把 Blob 经过纠删码扩展后分成数据列，再由点对点网络中的节点分担保管。节点请求样本；足够多的随机抽样成功，就能对完整数据可重建形成高置信度判断。

必须区分“可用性”和“执行”。以太坊没有要求每个验证者执行每一笔 Rollup 交易；它要确保重建、挑战或验证 Rollup 所需的数据确实存在。抽样减少普通节点需要取得的数据量，同时保留集体可用性保证，因此全网容量可以比单节点负担增长得更快。

flowchart LR
    A[用户在 Rollup 上交易] --> B[Rollup 压缩并批处理]
    B --> C[携带 Blob 的交易]
    C --> D[纠删编码后的数据列]
    D --> E1[节点抽样所分配的数据列]
    D --> E2[其他节点抽样其他数据列]
    D --> E3[超级节点保管全部数据列]
    E1 --> F{独立样本是否足够}
    E2 --> F
    E3 --> F
    F -->|是| G[高置信度确认数据可用]
    G --> H[Rollup 状态在以太坊结算]
    F -->|否| I[区块不被视为数据可用]

抽样不是“凭空压缩”，其中的不对称尤其重要。ethereum.org 的 PeerDAS 说明明确将其定位为通往完整数据可用性抽样和 Danksharding 的一步，而非终点。持有全部数据列并协助修复缺失数据的“超级节点”承担更重责任。Fusaka 页面估算，在未来目标容量达到 Fusaka 前的六倍时，此类节点需额外保存约 600GB Blob 数据，并维持约 20Mbps 下载带宽。这是路线图情境估算，不是所有当前节点的实测值，却揭示了真实取舍：去中心化依靠分散工作来保护，而不是让工作消失。

容量充裕，但需求并不平滑

Blob 容量阶梯与 2026 年 9 月固定历史样本的对比

容量从 Dencun 的 3/6 提升至 BPO2 后的 14/21。橙色虚线是截至 2026 年 9 月 4 日的 30 日均值，并非实时读数；它同时显示平均余量与尖锐尾部。

本文找到的最有解释力的公开测量，是一份可复现的 90 日主网回放：覆盖 2026 年 6 月 7 日至 9 月 4 日的 645,600 个区块和 286 万个 Blob。其中 8 月 6 日至 9 月 4 日的 30 日明细，为当前 14/21 参数制度提供了清晰切片。

指标（2026/8/6—9/4）

观测值

含义

平均每区块 Blob 数

5.2045

为 14 个目标值的 37.17%

中位数

4

典型区块远低于目标

第 95 / 99 百分位

14 / 19

尾部需求经常进入目标区间

零 Blob 区块占比

18.37%

需求分布不均匀

超过目标的区块

4.41%

推动费用上升的压力偶发

达到 21 个上限的区块

0.525%

硬上限事件存在但罕见

最长连续满载

4 个区块

饱和时间短

均值超过目标的 300 区块窗口

0%

样本内没有持续突破目标

这些数字并非以太坊基金会官方数据，而是第三方按公开方法进行、截止日期固定的回放。其价值恰恰在于样本、假设和修订记录可查。实时状态应另行查看 Blobscan。

分布比均值讲出了更完整的故事。只看每区块 5.2 个，容易得出“以太坊建设过度”；只看第 99 百分位的 19 个，又容易断言“稀缺已经逼近”。两者都忽略控制目标：平均余量用于吸收增长，而费用机制必须在硬上限成为持续服务瓶颈之前，对尾部高峰作出响应。健康的市场完全可以平均利用率不高，同时仍需要对尾部需求给出可信价格。

费用下限修复了信号

Blob 费用围绕目标值调整：持续高于目标，基础费上升；低于目标，基础费下降。但携带 Blob 的交易同样消耗执行 Gas。Fusaka 之前，当 Blob 费靠近最低值时，执行成本可能主导发布总成本；即使 Blob 给节点造成真实计算负担，名义 Blob 价格也可能长期微不足道，拥堵信号因而失真。

EIP-7918把 Blob 基础费与携带 Blob 的交易执行成本建立下界关系。当据此计算的保留价格高于名义 Blob 基础费时，更新规则会阻止价格继续衰减，并允许其恢复。这个机制很细微：它不承诺高费用，不保证 ETH 价值捕获，也不能把闲置容量自动变成收入；它只是让价格信号不容易被钉死在经济上毫无意义的最低点。

对 Rollup 而言，“充裕容量加保留价格”比“空间便宜但反馈失灵”更利于规划。对 ETH 经济性而言，结论更复杂：低数据成本能吸引使用、强化以太坊作为结算与数据可用性层的地位；但低利用率也必然限制近期 Blob 费用销毁。因此，投资逻辑取决于需求能否复利增长并逐渐填充新增容量，而非容量本身存在与否。

活跃度能说明什么，又不能说明什么

L2 活跃度验证了扩容方向。L2BEAT 活跃度面板在 2026 年多次显示 Rollup 活动量为以太坊 L1 的许多倍，但这些是会变化的实时数据，必须结合时间戳与分类口径阅读。它证明执行正大量移出 L1，却不证明所有活动产生相同 Blob 需求：压缩率不同，部分系统使用其他数据可用性安排，高频应用也可能高效批处理。

实际因果链要经过多层过滤：

flowchart TD
    A[L2 用户操作增加] --> B{数据是否发布至以太坊}
    B -->|否| C[不产生以太坊 Blob 需求]
    B -->|是| D[压缩与批处理]
    D --> E[形成 Blob 需求]
    E --> F{平均用量相对目标值}
    F -->|低于目标| G[稀缺收入较低且仍有增长空间]
    F -->|持续高于目标| H[费用上升并出现容量压力]
    H --> I{节点健康与安全余量是否充足}
    I -->|是| J[考虑后续 BPO 增容]
    I -->|否| K[暂缓增容并优化网络]

因此，交易笔数不是完整估值指标。分析者必须把用户操作继续映射到发布字节数、实际支付费用、提交者集中度，以及数据所依赖的安全模型。

对机构参与者的含义

对 Rollup 运营方，扩大的目标容量是一层成本和可靠性缓冲。稳健做法不是假设费用永远接近于零，而是把 Blob 发布视作带有尾部风险的可变投入。即便月均值温和，突发需求仍会让发布时间安排、压缩效率与费用上限具有财务意义。

对节点运营者，均值同样不够。抽样相对“下载全部 Blob”减轻普通节点负担，但峰值流量、对等节点质量、数据列保管职责与存储策略才决定韧性。一个经济上利用不足的网络，仍可能经历短时网络压力。高峰期间的漏签、重建性能与连接质量，比单看费用曲线更有信息量。

对 ETH 持有人和协议投资者，Fusaka 改善了以太坊产品的可扩展性，但产品容量并不等于代币现金流。近期闲置空间是为增长购买的保险。乐观情境是，较低 Rollup 成本催生应用、加深结算需求，最终填满扩大的数据市场；反面情境则是，其他数据可用性层的竞争、更高压缩效率或非 Rollup 架构迁移，使以太坊 Blob 需求长期低于产生可观费用的水平。

对治理观察者，BPO 带来新的问责界面。参数调整应接受透明阈值检验：持续利用率而非孤立满块、费用行为、不同地区和客户端的节点健康、数据重建成功率，以及 Blob 提交者集中度。更快的旋钮只有在使用过程清晰可审计时才有价值。

风险与反方观点

第一是过早扩容。需求远低于目标时继续提高容量，可能推迟价格发现和收入形成，同时把更多带宽与存储负担交给基础设施方。合理回应不是自动冻结容量，而是要求证据证明额外余量创造的用户价值足以补偿运营成本。

第二是隐性中心化。PeerDAS 限制普通节点下载量，但高配超级节点与连接优良的中继可能变得更重要。如果重建能力依赖少数服务方，验证者数量的表面分散会高估实际韧性。

第三是需求集中。少数 Rollup 可能占据大部分 Blob 发布量；它们的软件变更、压缩升级或迁移足以让需求骤变，因此历史利用率未必能平滑外推。

第四是测量歧义。“每区块 Blob 数”忽略每个 Blob 的实际填充度；L2 交易量忽略压缩率和数据可用性选择；费用收入又同时受 ETH 价格、执行成本与 Blob 用量影响。不存在一张面板能够概括全部维度。

最后，这个控制闭环仍部分依赖社会协调。抽样和费用调整是协议机制；是否安排后续 BPO，则体现开发者和社区的风险偏好。以太坊让旋钮更聚焦、更安全，却没有让它脱离政治与治理。

结论

Fusaka 最持久的贡献是改变了运营哲学。PeerDAS 削弱全网吞吐量与普通单节点下载负担之间的绑定，以太坊因而可以通过受监测的步骤扩大 Rollup 数据容量。14/21 参数制度提供了显著余量，而截至 2026 年夏末的最佳公开样本也说明应如何理解这份余量：平均需求不高，尾部需求却真实存在。

下一项关键验证并不是再公布一个更高理论上限，而是以太坊能否把廉价容量转化为持久、分散的需求，同时维持有意义的拥堵信号和可观察的节点健康。如果能够做到，Blob 空间将成为可信基础设施：空闲时便宜，稀缺时定价，而且扩容不会排斥普通运营者。如果做不到，它只会证明技术容量存在，却没有解决赋予容量价值的经济与去中心化取舍。

来源与方法