EIP-8135 深度解读：BPO2 硬分叉的 Blob 参数变更与以太坊数据可用性增量扩容

EIP-8135 深度解读：BPO2 硬分叉的 Blob 参数变更与以太坊数据可用性增量扩容

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs

BPO2（Blob-Parameter-Only 2）是以太坊主网继 BPO1 之后的第二次“仅调整 Blob 参数”的网络升级，本篇文章以 EIP-8135 为主干，结合仓库中 EIP-7892（BPO 机制）、EIP-8134（BPO1）、EIP-7840（blob schedule 配置）与 EIP-4844（Blob 交易）等规范，系统梳理 BPO2 的激活参数、配置格式、底层定价机制与历史演进。读完本文，你将掌握 BPO2 的完整参数清单、如何在 eth 客户端 genesis 配置中定位bpo2Time与blobSchedule，以及 blob base fee 更新分式（baseFeeUpdateFraction）背后的计算原理和它对 DA 扩容节奏的影响。

一、背景：从 EIP-4844 到 BPO 系列升级

以太坊的数据可用性（DA）扩容始于 EIP-4844（Shard Blob Transactions）引入的 blob-carrying 交易：Rollup 将大量数据以 blob 形式提交到共识层，同时不增加 EVM 执行负担。EIP-4844 定义了三个核心 blob 协议参数：

• Blob Target（target）：每个区块预期的 blob 数量；
• Blob Max（max）：每个区块允许的 blob 数量上限；
• Base Fee Update Fraction（baseFeeUpdateFraction）：控制 blob gas 价格随区块负载调整的敏感度。

在早期阶段，这三个参数只能随大型硬分叉一起调整，节奏慢、协调成本高。为此，EIP-7892 定义了Blob Parameter Only（BPO）硬分叉机制：一种只通过配置修改 blob 相关参数、不需要任何客户端代码变更的轻量级升级方式。BPO 分叉命名遵循bpo<index>约定（从 1 开始计数），激活时刻通过顶层<fork_name>Time字段指定。

EIP-8135 正是这一机制下的第二个实例——BPO2的 Meta EIP，它记录该升级的激活细节、参数变更与规范引用，为 Surge 路线图下增量数据可用性扩容提供权威的规范登记（canonical reference）。

主网 blob 参数历史演进

仓库中 EIP-8135 明确记录了 BPO2 之前的参数基线：

可以看到，从 Prague 开始 target:max 比例稳定在 2:3（区别于 Cancun 的 1:2），BPO2 直接建立在 BPO1 的参数基线上，将 blob 容量又提升了一个台阶。

二、BPO2 核心规范：激活时间与参数表

EIP-8135 的 Specification 章节以表格形式给出了 BPO2 的权威参数（所有时间戳均以 Unix epoch 秒表示，UTC 时区）：

对上述数值的几点解读：

• 激活时间 1767747671：换算约为 2026-01-07 01:01 UTC（该 EIP 本身只以 Unix 秒作为权威表示，客户端与工具应直接使用该数值）。
• Blob Target = 14 / Blob Max = 21：相对 BPO1 的 10/15 提升 40%，继续维持 2:3 的比例关系。
• Base Fee Update Fraction = 11,684,671：相比 BPO1 的 8,346,193 显著增大。该值越大，blob base fee 对负载偏离的响应越平缓（详见下文第五节）。

BPO2 是 BPO1 之后第二次增量 blob 容量提升，延续了向更高数据可用性上限分阶段推进（staged scaling）的策略。按 EIP-7892 的约定，升级只修改 blob 相关协议参数，不影响任何其他协议行为。

三、数据来源：eth 客户端 genesis 配置中的 blobSchedule

EIP-8135 中的参数值与激活时间来源于 eth 客户端 genesis 配置，对应的 JSON 形态如下（原文档完整示例）：

"bpo2Time": 1767747671, "blobSchedule": { "bpo2": { "target": 14, "max": 21, "baseFeeUpdateFraction": 11684671 } }

这段配置的格式定义来自 EIP-7840（Add blob schedule to EL config files）：客户端配置文件扩展出blobSchedule对象，为每个分叉列出每区块的 target、max 与 baseFeeUpdateFraction。而每个分叉的激活时间则通过顶层<fork_name>Time字段与分叉条目一一绑定（EIP-7892 执行层配置章节）。

EIP-7892 中给出了包含 BPO1、BPO2 的完整示意配置（其中 osaka、bpo1、bpo2 的时间与数值均为示例，实际以各 EIP 与主网 genesis 为准）：

{ "blobSchedule": { "cancun": { "target": 3, "max": 6, "baseFeeUpdateFraction": 3338477 }, "prague": { "target": 6, "max": 9, "baseFeeUpdateFraction": 5007716 }, "bpo1": { "target": 10, "max": 15, "baseFeeUpdateFraction": 8346193 }, "bpo2": { "target": 14, "max": 21, "baseFeeUpdateFraction": 11684671 } }, "cancunTime": 0, "pragueTime": 0, "bpo1Time": 1757387400, "bpo2Time": 1767387784 }

几点说明：

• 为什么cancunTime/pragueTime为 0：由于不存在回填（backporting），这两个分叉的激活时间在 EL 配置中设为 0；只有 Prague 之后发生的分叉才需要提供真实的激活时间戳。
• 主网真实值：EIP-8134 记录的 BPO1 主网激活时间为bpo1Time: 1765290071（换算约为 2025-12-09），EIP-8135 记录的 BPO2 为bpo2Time: 1767747671，两者相差约 28.4 天，体现了 BPO 机制“高频小步”的迭代节奏。
• 字段名差异：不同客户端实现可能以不同格式暴露这些值，EIP 中记录的是主网配置的权威数值（canonical mainnet configuration values）。

四、底层机制：BPO 分叉如何生效

BPO 升级的核心在于“只改配置、不改代码”，其底层支撑来自 EIP-7892 对 blob 费用计算的改造。EIP-7892 修改了 EIP-4844 中定义的get_base_fee_per_blob_gas与calc_excess_blob_gas两个函数，使它们显式使用 blob schedule（与 EIP-7691 更新BLOB_BASE_FEE_UPDATE_FRACTION的处理方式一致，采用当前区块的 blob schedule），并移除冗余的TARGET_BLOB_GAS_PER_BLOCK，改用GAS_PER_BLOB * blob_schedule.target计算：

class BlobSchedule: target: U64 max: U64 base_fee_update_fraction: Uint def calc_excess_blob_gas(parent: Header, blob_schedule: BlobSchedule) -> int: target_blob_gas = GAS_PER_BLOB * blob_schedule.target if parent.excess_blob_gas + parent.blob_gas_used < target_blob_gas : return 0 else: return parent.excess_blob_gas + parent.blob_gas_used - target_blob_gas def get_base_fee_per_blob_gas(header: Header, blob_schedule: BlobSchedule) -> int: return fake_exponential( MIN_BASE_FEE_PER_BLOB_GAS, header.excess_blob_gas, blob_schedule.base_fee_update_fraction )

其中MIN_BASE_FEE_PER_BLOB_GAS与GAS_PER_BLOB由 EIP-4844 定义（分别为1与2**17）。BPO2 激活后，执行层客户端在计算 blob base fee 时便会自动切换到bpo2条目下的target=14与baseFeeUpdateFraction=11684671。

在共识层（CL），EIP-7892 新增BLOB_SCHEDULE配置字段，每条目包含分叉 EPOCH 与MAX_BLOBS_PER_BLOCK：

BLOB_SCHEDULE: - EPOCH: 400000 # A future anonymous BPO fork MAX_BLOBS_PER_BLOCK: 15 - EPOCH: 420000 # A future anonymous BPO fork MAX_BLOBS_PER_BLOCK: 21

BPO 分叉还会影响 P2P 层的 fork digest：compute_fork_digest将当前 epoch 适用的max_blobs_per_block位掩码进 4 字节 digest，ENR 中新增nfd（next fork digest）字段，gossip 主题也会因ForkDigestValue变化而自动轮转。这也是为什么 BPO 虽“参数化”却仍属于硬分叉类别——所有节点必须在同一时刻切换参数，才能维持网络共识一致。

五、Base Fee Update Fraction：参数越大，费用越平缓

baseFeeUpdateFraction直接决定 blob 市场的价格发现速度。在fake_exponential中，该值作为分母参与指数计算：数值越大，blob base fee 对 excess blob gas 的响应越平缓。

EIP-7691（Prague 的 blob 吞吐量提升）给出了直观的参照：当 target:max 从 Cancun 的 1:2 调整为 Prague 的 2:3 后，费用对空块（低于 target 6 个 blob）的响应比对满块（高于 target 3 个 blob）更敏感，因此BLOB_BASE_FEE_UPDATE_FRACTION_PRAGUE取 5,007,716 作为“保持满块与空块响应性平衡”的折中值，使满块时 base fee 约上涨 8.2%、空块时约下降 14.5%。

BPO2 将 fraction 提升到 11,684,671，是 Prague 的约 2.3 倍。结合 target 从 6 升至 14，这说明：在更大的 blob 容量下，单个区块的相对偏离幅度变小，网络有空间采用更平缓的费用调节曲线，避免价格因局部负载抖动而过快波动，从而为持续观测高负载下的网络行为留出余量。

六、Rationale：为什么选择再次增量扩容

EIP-8135 的 Rationale 明确指出 BPO2 的定位：

• BPO1 之后的观测表明，网络能够容忍更高的 blob 上限，但尚未在更宽的运行区间（operating range）内积累足够的数据；
• BPO2 延续同一增量扩容思路，进一步扩大 blob 参数，以便在更高 blob 负载下继续观测网络行为；
• 其目标是为blob 处理、slot 可靠性（slot reliability）与整体网络稳定性收集更多经验数据；
• 需要强调的是，BPO2并非由已证实的市场需求驱动，而是出于以受控方式评估系统极限的需要，同时保留根据观测结果暂停或调整参数的余地。

这与 EIP-7892 的设计哲学一脉相承：通过轻量级参数调整，在“稳定性”与“容量”之间找到更优权衡，为 rollup 生态提供可预期的扩容节奏。

七、安全考量与生态协同

EIP-8135 的 Security Considerations 提示：BPO 升级调整 blob 吞吐参数，可能影响网络负载特征，需要**谨慎监控（careful monitoring）、分阶段推进（staged rollout）与生态协调（ecosystem coordination）**来保障稳定性。

此外，EIP-7892 还给出了跨层一致性要求，同样适用于 BPO2：

• 执行层与共识层客户端必须共享一致的 BPO 分叉计划；
• ELblobSchedule中的 slot 编号必须与 CL 配置中指定 epoch 的起始位置对齐；
• ELblobSchedule的max字段必须等于 CL 配置中的MAX_BLOBS_PER_BLOCK。

八、延伸阅读

• EIP-8134（Hardfork Meta - BPO1）：BPO1 的参数记录（target 10 / max 15，bpo1Time: 1765290071）；
• EIP-7892（Blob Parameter Only Hardforks）：BPO 机制的完整规范，含 EL/CL 配置、费用计算与 fork digest 改造；
• EIP-7840（Add blob schedule to EL config files）：blobSchedule配置对象的定义与设计动机；
• EIP-7691（Blob throughput increase）：Prague 6/9 参数与 base fee 响应性分析；
• EIP-4844（Shard Blob Transactions）：Blob 交易与基础费用模型的源头；
• LICENSE：EIP 系列文档统一采用 CC0 公有领域授权。

总而言之，EIP-8135 以一份简洁的 Meta EIP 形式，为 BPO2 提供了权威、可追溯的参数登记：激活时间 1767747671（约 2026-01-07）、Blob Target 14、Blob Max 21、Base Fee Update Fraction 11,684,671。结合仓库中 BPO1、EIP-7892、EIP-7840 与 EIP-7691 等文档，开发者可以完整还原从 genesis 配置到 blob 费用计算的整条链路，准确理解以太坊在 Surge 路线图下“小步快跑”式数据可用性扩容的工程全貌。

【免费下载链接】EIPsThe Ethereum Improvement Proposal repository项目地址: https://gitcode.com/GitHub_Trending/ei/EIPs