以太坊blob扩容用到哪了 blob费用为什么降不到零了

扩容的进度条停在一格没填完的表上。以太坊在 2026 年 1 月 7 日执行 BPO2，把每个区块的 blob 配额抬到目标 14 枚、上限 21 枚，此后十个多月没有动过；下一级 BPO3 对应的 EIP-8138 早已写成提案，可"激活时间""目标""上限"三栏还空着。与此同时，需求侧的数字正在朝这条线靠。11 月 5 日凌晨从主网节点连续取回的 300 个区块，平均每块用了 9.43 枚 blob，折合目标的 67%，其中 89 块（29.7%）达到或超过 14 枚，9 块顶满 21 枚。一年多之前上线 Fusaka 时，扩容的说法是"先把管道铺宽，用量自然会跟上来"；现在管道已经铺开，用量也跟上来了大半，下一步到底该什么时候再加宽，反而成了没人愿意先表态的问题。

先把这五级台阶摆齐，才知道停在哪一级

blob 是以太坊给二层网络准备的临时数据通道。二层把用户在链下发生的交易压成一批数据，塞进 blob 交给主网，主网负责在约 18 天内证明这批数据确实存在。每个 blob 固定 128 KiB，每个区块能装几个，由协议参数决定。这条通道的容量在两年多里抬过四次，但每次抬的幅度和方式都不一样。

2024 年 3 月 Dencun 上线时是目标 3 枚、上限 6 枚。2025 年 5 月 Pectra 把两个数翻成 6 和 9。2025 年 12 月 3 日的 Fusaka 做了一件不一样的事：它没有立刻抬数，而是先装上了 PeerDAS，让每个节点只保管八分之一的数据、靠抽样确认其余部分可用，从底层腾出空间；紧接着 12 月 9 日 BPO1 把配额抬到 10 和 15，2026 年 1 月 7 日 BPO2 再抬到 14 和 21。

这一步一步的抬法本身是个新机制。BPO 是"只改参数"的小型分叉，只动目标枚数、上限枚数和费用更新系数，不牵动其他执行逻辑，因此可以按需插入，不必等一个打包十几项改动的大版本。

停在哪一级，可以直接向节点问。以太坊客户端提供 eth_config 这个接口，它返回当前、下一个、上一个分叉的完整快照，其中就包含 blobSchedule。我取到的最新快照写着 target 14, max 21, baseFeeUpdateFraction 11684671，激活时间戳 1767747671，折算为 2026 年 1 月 7 日 01:01 UTC。也就是说，十个月过去，这个数字连一位都没变。

BPO3 那头的情况更直接。EIP-8138 是一份 2026 年 1 月 27 日创建的元提案，专门用来记录 BPO3 的权威参数。文件里写明了推导规则：下一级的目标等于上一级的上限，上限取目标的 1.5 倍向上取整，按这条规则算出来应该是目标 21、上限 32。但参数表里的四行，激活时间、目标、上限、费用更新系数，全是空的。

规则写好了，日期没写

这不是疏忽。协议规范仓库的测试版本说明里提到，原本标记为 BPO3、BPO4 的过渡场景被挪到了 Amsterdam 分叉之后，也就是说客户端团队已经把"BPO3 及以后"排到一个尚未激活的命名分叉后面。以太坊基金会 2025 年 8 月那份扩容说明里给过一个更远的数字：PeerDAS 之后，blob 数量会"每隔几周翻倍一次，直到达到 48 枚的最大值"。48 枚和现在 21 枚之间还隔着好几级，但中间的台阶没有一级写下日期。

为什么会这样，把一年里做的事倒过来看就明白。2024 年底到 2025 年初那一轮拥堵里，blob 用量长期贴着目标跑，费用一度涨到每枚 0.8 mETH 上下。当时扩容是"缺多少补多少"。等 Pectra 把配额翻倍、Fusaka 装上 PeerDAS、两次 BPO 再抬一轮之后，容量从每块 3 枚变成 14 枚，翻了四倍多，而需求并没有同步翻四倍。盘子一下空出大半，后面每加一级，都是在赌需求能不能追上来。

300 个区块的数字：需求回来了一半

论文里最能说明问题的表是这一行：BPO2 全期的平均用量是目标的 30%。2026 年 10 月发表于 arXiv 的《Demand Under a Mechanical Price》用 189.7 万个区块复算了这一区间，得到平均每块 4.20 枚、目标 14 枚。同一位作者此前的统计还显示，用量在 BPO1 阶段是目标的 47%，到 BPO2 反而掉到 30%，因为容量加得太快，分母跑在了分子前面。

但如果只拿 30% 这个数去推"余量还很足"，就会错过最近的变化。我在 2026 年 11 月 5 日凌晨连续取了 300 个区块（约 1 小时），结果如下：

同一个小时里，区块的 blob 用量分布并不均匀：16 块完全没有 blob，21 块用满上限，中间则铺得很开。这种"要么空、要么满"的形态说明 blob 交易是成批到达的，一个二层把积压的交易压缩后会一次吃掉好几枚，而只有零散小额交易时，某个区块可能一枚都不买。这也解释了为什么平均 67%、却有近三成区块越过目标线。

用量回升有没有真实的二层活跃度支撑，而不只是统计噪声？growthepie 的 Base 链日活数据可以作为侧面参照：2026 年 10 月底的日均活跃地址在 30 万上下，10 月 28 日一度冲到 146.7 万，11 月 1 日到 3 日分别是 25.4 万、34.2 万、30.7 万，与前一个月同期的量级接近，没有掉下去。也就是说，需求并没有萎缩，只是被更大的容量稀释了。

为什么 blob 费降不到零：保留价这层底

容量翻了几倍，按常识 blob 费该一路跌到 1 wei 的地板。历史数据确实如此：Dencun 期有 24.8% 的区块停在 1 wei，Pectra 期涨到 48.9%，2024 年第三季度整整一季，所有 blob 手续费加起来只有 0.000004 ETH。可 Fusaka 之后，论文统计的 189.7 万个 BPO2 区块里，停在 1 wei 的比例是 0.0%。

变化来自 EIP-7918，Fusaka 一起带上主网的。它给每个 blob 加了一条与执行基础费挂钩的保留价：当执行一枚 blob 所消耗的执行 gas 折算出的成本，高于 blob 自身的基础费时，协议就不再按"超出目标"的规则继续压价，而是把它当作已经过载处理，让费用往上走。用以太坊基金会文档的说法，这个改动要解决的就是"执行层基础费一涨、blob 费就被压在 1 wei 动弹不得"的局面。

我按这个规则，用同一批 300 个区块算了当前实际水平：平均 blob 基础费约 4,119 wei 每单位 blob gas，折算成一枚 blob 是 0.54 gwei，按 2,425 美元的 ETH 价格，一枚 blob 的成本约 0.0013 美元。同期执行基础费平均 0.304 gwei，按 EIP-7918 的常数算出的保留价约 1,899 万 wei 每单位，比实际 blob 费高约 4,600 倍。300 个区块里，实际 blob 费全部低于保留价。

这两个数放在一起看才有意思。实际 blob 费远低于保留价，说明容量确实还松，费用没有被顶起来；但 blob 费又不会跌到 1 wei，因为保留价把那层地板焊死了。协议在这里做的事，是把 blob 从"免费的附属品"重新定价为"至少覆盖节点计算成本的资源"。它不解决需求，只保证价格信号不会消失。

Binance全球顶级交易所 v3.22.4

类型：金融理财大小：306.2M语言：多国语言[中文]时间：11-2评分：10.0

需求到底有多不敏感，这决定了下一步

《Demand Under a Mechanical Price》最核心的发现是需求弹性。作者拿 Pectra 那次翻倍做了一次天然实验：2025 年 5 月 7 日，配额从 3 枚变 6 枚，费用在一天之内从每枚 0.82 mETH 掉到地板。如果需求对价格敏感，量该大幅上涨。实际结果是 blob 购买量只涨了 24%，95% 区间是 8% 到 40%，对应的价格弹性约 -0.19，最宽松的一端也不超过 -0.31。

这个数在生产上的含义很直接。需求几乎不随价格动，当容量不够时，涨价只是把钱从二层转到协议手里，不会让二层显著少买；当容量过剩时，降价也不会让二层多买多少，只相当于少收了一笔钱。作者据此把 blob 费的福利效应拆成两部分：第一套规则下二层共支付 4,704 ETH（约 1,481 万美元），其中 67% 落在 2024 年第四季度和 2025 年第一季度那两个"容量打满"的季度，本质上是对固定稀缺容量的租金；而在容量宽松时，保底价带来的无谓损失总共只有 0.4 ETH 到 2.6 ETH 的量级，约合 1,241 到 8,039 美元。

更值得留意的是作者对"地板价等于容量闲置"这个直觉的检验。费用停在 1 wei 看着像拍卖失败、只能排队，可 540 万笔 blob 交易的实测是反的：在地板价区间内首次出现的交易，平均只错过 1.03 个区块，是所有状态里最少的，被错过的区块里真正因为价格被筛掉的只占 0.08%。地板价意味着余量，不意味着拥堵。

弹性不敏感，所以扩容的风险在别处

把这三个数并排放：需求弹性接近零、扩容走的是"只改参数"的小分叉、下一级参数表还空着。它意味着一件容易被忽略的事：加容量几乎不会让费用再降一个量级，但不加容量会实实在在地把费用推上去。因为需求不敏感，容量一紧，价格就得涨很多才能把用量压回目标线；而价格一旦涨起来，二层的成本会顺着传递到最终用户，这部分传递在论文里只是初步证据，作者自己标为事后补充分析，衡量的是二层手续费中位数相对下跌了 31%。

所以 BPO3 什么时候上，比的不是"余量还剩多少"，而是"还能容忍费用涨到多高"。按目前的 67% 用量和 3% 触顶比例，距真正的硬约束还有距离；但利用率从 30% 爬到 67% 只用了一部分样本期，若二层继续按现在的节奏增长，下一个十个月里触底 21 枚的区块比例会最先跳出来提醒。

欧易okx交易所 v6.195.1

类型：金融理财大小：549.4M语言：中文时间：11-1评分：10.0

这几条读法，决定了该看什么

第一，看用量要看分布而不是均值。均值 9.43 枚只说明"平均还有余量"，21 枚那一档的区块占比才是硬信号。3% 是个很小的数，但它会在几周之内翻倍，因为 blob 交易成批到达，一旦二层的批处理规模扩大，顶格区块会最先增加。

第二，看 blob 费要有量纲。协议里存的是"每单位 blob gas 的 wei"，一枚 blob 等于 131,072 单位。以太坊基金会文档和多数行情面板直接给 gwei，但有的是每单位、有的是一枚，差 13 万倍，混用会得出相反结论。当前每单位约 4,119 wei，一枚 0.54 gwei，这个换算关系值得记下。

第三，看保留价要看执行基础费而不是 blob 自身。EIP-7918 把两者绑死之后，主网活跃度一上来，执行基础费抬升，blob 的底价跟着抬，即使 blob 需求没有变化，二层的成本也会被推高。这条耦合此前不存在。

第四，把"扩容"和"提速"分开。PeerDAS 改的是节点怎么验证数据，BPO 改的是每块装几枚，两者管的事不同。PeerDAS 已经装上，空间腾出来了；BPO 才是把空间兑现成配额的动作，而这一步现在卡在排期上。

第五，对二层资产的影响要落在成本结构上，而不是容量数字上。二层付给主网的数据成本，在 Dencun 之后长期只占其总成本的一小部分，但在拥堵期曾经接近二层手续费中位数本身。这意味着繁荣期二层的成本弹性比很多人想的大。

三条会推翻上面判断的条件

如果 BPO3 在未来几周内被排期并激活，把目标推到 21 枚、上限 32 枚，那么"容量余量正在收窄"这条判断会被推迟，用量占比可能重新掉回 40% 以下，触顶区块比例也会回落。反过来说，如果这一级迟迟不排，而用量占比在一个月内稳定站在 70% 以上、触顶区块超过 8%，那就是容量真的开始紧了。

如果 EIP-7918 被后续升级改写或撤销，blob 费重新回到可以一路贴到 1 wei 的状态，那么"价格不会归零"这条就失效，二层的成本结构会退回 Dencun 时代的形态。目前没有看到这类提案进入活跃讨论，但改价格机制的门槛比加容量低。

如果在接下来的一两个季度里，二层之间出现明显的数据层迁移，例如某家大规模的二层把数据从以太坊 blob 挪到其他数据可用性层，本文基于"需求在同一条管道里持续积累"的推演就不成立。目前 growthepie 追踪的 25 条二层中，15 条仍把数据发到以太坊 blob，这个格局近期没有变化。

资料来源

• 以太坊基金会博客《Fusaka Mainnet Announcement》（2025 年 11 月 6 日）：https://blog.ethereum.org/2025/11/06/fusaka-mainnet-announcement
• 以太坊官方文档 Fulu-Osaka (Fusaka) 页：https://ethereum.org/roadmap/fusaka/
• EIP-7918《Blob base fee bounded by execution cost》：https://eips.ethereum.org/EIPS/eip-7918
• EIP-8138《Hardfork Meta - BPO3》（2026 年 1 月 27 日）：https://eips.ethereum.org/EIPS/eip-8138
• 以太坊基金会博客《Protocol Update 002 - Scale Blobs》（2025 年 8 月 22 日）：https://blog.ethereum.org/en/2025/08/22/protocol-update-002
• Farbod Ghasemlu《Demand Under a Mechanical Price: Elasticity and Welfare in Ethereum's Data-Availability Market》（arXiv，2026 年 10 月）：https://arxiv.org/abs/2610.16588
• 主网节点实测：eth_config 与 300 个区块的 blobGasUsed / excessBlobGas 采样，2026 年 11 月 5 日 01:35（UTC+8）
• growthepie Base 链活跃地址数据：https://www.growthepie.com/chains/base