结论先说
BPO（Blob Parameter Only）fork 是 Ethereum 在 Fusaka 升级引入的新做法：不动共识逻辑、不改客户端行为，只把 blob 的目标数与上限两个参数调一次，用一个极小的”配置分叉”单独生效。它把”扩容调参”从大版本里拆出来，像给锅炉调阀门一样小步试压。2025 年 12 月的时间线是活教材：Fusaka 主网于 12 月 3 日激活（带 PeerDAS 与基础 blob 参数），BPO1 于 12 月 9 日把每块 blob 目标提到 10、上限 15，BPO2 于 2026 年 1 月 7 日进一步到目标 14、上限 21——从升级生效到吞吐翻倍只用了一个月（时刻与数值见文末官方博客，核验时间 2026 年 7 月 23 日）。
为什么单独开一类分叉
Fusaka 的主角 PeerDAS 让验证者靠采样而非全量下载来核验 blob（机制见PeerDAS会降低L2费用吗？），安全模型因此对”一次把参数拉多高”变得温和：数据带宽压力可以分批释放，出问题也能以同样小的分叉回退。大版本塞大参数调整的老路则相反——2024 年 Dencun 上线 blob 后，参数上调要等下一整个升级周期，L2 费用曲线长期悬在原地（blob 费用基础见以太坊Blob是什么？L2费用为何变低、EIP-7691提高Blob吞吐后费用怎么变？）。BPO 的意图明确：扩容节奏从”年”切到”周”，每一步都可独立回滚。
两个参数各管什么
blob target 是”舒适水位”，决定基础费曲线的中轴：区块平均用量高于目标，blob 基础费上调，低于则下调（与区块 gas 的目标线机制同构，见区块 gas 上限怎么形成？验证者投票与费用波动的关系）。blob max 是”单块硬顶”，配合 PeerDAS 的列采样预算设定。目标与上限的间距，就是网络允许短时冲高的余量。BPO 只动这两个数字及其换算节奏，不碰验证规则——这也是它能用”配置分叉”轻装上阵的前提。
调参的政治学
参数没有数学最优解，只有”当前带宽下的稳健值”。上调太急，带宽不足的区域节点掉线率上升、重同步变慢，伤的是去中心化；上调太慢，L2 费用下不来，伤的是用户。BPO 机制把这场拉扯改写成可逆的小步：先提目标，观察一周带宽与最终性指标，再提下一档。Fusaka 之后两个月连调两档（6/9 起步、经 10/15 到 14/21）体现的就是这种”试压式扩容”。对 L2 团队，BPO 意味着成本模型的更新周期缩短，报价与结算策略要盯配置变更日历而不是等年度公告。
怎么核验与预判
查三处：官方博客的 BPO 时间表（epoch 与 UTC 时刻）、执行客户端版本的 blob schedule（EIP-7840 让客户端可声明各硬分叉的 blob 参数）、以及 eth_blobBaseFee 走势（读数方法见相关 API 专题）。趋势判断上有个安全锚：只要 blob 用量长期低于目标，费用只会阴跌——BPO 上调上限本身不会自动涨价，它给的是”拥堵时才花得动”的额度。反过来，参数没动但 blob 用量逼近目标时，哪怕 max 很高，费用也会先涨。运维侧还有一条：BPO 同样是分叉，节点须在时刻前升级到含新配置的客户端版本，否则会像大版本升级一样滞留在旧参数视图（分叉激活机制见公链升级怎么排期？从 devnet、测试网到预定激活）；跑 RPC 与索引服务的团队，应把 BPO 时刻当作与主升级同级的变更窗口来处理，提前压测列采样与数据检索路径。
风险提示
blob 参数与后续 BPO 排期由核心开发者按网络状况决定，随时可能加密或放缓；本文历史数值均来自官方公告（核验时间 2026 年 7 月 23 日），不构成对费用的任何预测。L2 收费策略请以各链实时报价为准。本文不构成投资建议。
小结
BPO 把”调 blob 参数”从大版本拆成独立小分叉：目标管费用中轴，上限管短时天花板，两次试压式上调换来 L2 成本的阶梯下行。看扩容别只盯”又提高了多少”，节奏可逆、每步可回滚，才是这类机制真正的新意。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。