深度解读 EIP-7918：Blob 交易费用新“保底价”机制详解
虽然 if 语句中的阈值因常量变更而发生变化，但 EIP-7918 的规范代码仍仅有两行。原始常量设定了一个较低的最低 blob 基础费用，同时仍能保证正常的费用市场运作。新提议使用的常量将根据 blob 对节点造成的工作量更合理地提高最低费用，同样也确保市场正常运行。本文其余部分主要探讨这一建议背后的逻辑与影响，并对 blob 相较于单点验证操作对节点造成的总工作量进行比较。
作者 ｜ Anders Elowsson
🔗 原文链接：https://notes.ethereum.org/@anderselowsson/EIP-7918E
在 EIP-7918 的讨论阶段，Ben Adams 建议，不应通过摊销到多个 blob 的 TX_BASE_COST 来计算最低 blob 基础费用，而应直接使用 POINT_EVALUATION_PRECOMPILE_GAS（点验证预编译的 gas 成本）来估算。这个设计方案具有一定价值，本文基于 Ben、Francesco D’Amato、Justin Traglia、Toni Wahrstätter 和 Marius Van Der Wijden 的讨论与反馈进行分析。
摘要
虽然 if 语句中的阈值因常量变更而发生变化，但 EIP-7918 的规范代码仍仅有两行。原始常量设定了一个较低的最低 blob 基础费用，同时仍能保证正常的费用市场运作。新提议使用的常量将根据 blob 对节点造成的工作量更合理地提高最低费用，同样也确保市场正常运行。本文其余部分主要探讨这一建议背后的逻辑与影响，并对 blob 相较于单点验证操作对节点造成的总工作量进行比较。
背景
EIP-4844（Dencun 升级）
EIP-4844 引入了以太坊数据可用性采样（DAS）路线图的第一阶段。在共识层，验证者需通过验证 KZG 证明，确保 payload 中的 KZG 承诺与提供的 blob 相对应。执行层（EL）的节点也必须验证 tx_payload_body，并对每个进入 mempool 的 blob 进行数据（包括 blob、承诺和证明）的验证。MEV-boost 也会在 blob 被打包进 payload 时通过 flashbots_validateBuilderSubmission 端点进行类似验证（至少在 Nethermind 客户端中如此）。
验证整个 blob 的 KZG 证明所需计算量略高于验证 blob 上某个点的证明，后者即 POINT_EVALUATION_PRECOMPILE_GAS（设为 50000 gas）所对应的操作。虽然通过 MEV-boost 直接传入的 blob 不会让 EL 节点承担 p2p 验证负担，但 MEV-boost 并不属于协议内机制。协议应按 blob 通过 p2p 传播的常见最坏情况进行计费，而这正是目前常见的情形，因为 blob 中的 MEV 较少。
EIP-7594（Fusaka 升级）
EIP-7594 引入了 PeerDAS，计划随 Fusaka 升级上线。这改变了计算需求，因为验证依赖于 blob 的“单元格”（cells）及其对应的证明。规范尚未最终定稿，但基本流程如下：
EL 节点需为每个 blob 批量验证 CELLS_PER_EXT_BLOB = 128 个单元格证明（如使用 verify_cell_kzg_proof_batch）。该验证大约是一个 POINT_EVALUATION_PRECOMPILE_GAS 所代表计算量的 15 倍。
完整节点需验证 4 个托管列（custodied column），每列包含所有 blob 中的一个 cell，且可批量验证。
超级节点需验证 128 个托管列（即每 blob 一列），同样可批量验证。
不同等级的验证者可能会托管 4 至 128 个列。
节点每个 slot 会 peer-sample 8 个列用于验证，同样支持批量验证。
在 CL 中，批量处理所有 blob 的列可以降低每个 blob 的平均验证成本。然而，即使列是批量验证的，如果逐列顺序执行，总体计算量仍很大。这也可以进一步优化为并行处理。虽然 rollup 使用预编译函数进行的点验证也具备并行化潜力，但相比逐列验证 blob，其计算量依旧较低。因此两者的比较仍具参考价值。
图 1 展示了每个 blob 的验证时间，除以一次点评估操作的实际执行时间（该操作由 VerifyKZGProof 预编译合约执行），在不同配置下的对比结果。该测试在 C-KZG-4844 库的早期测试基础上进行了扩展，通过改变列中的 blob 数量、将列联合批处理或并行计算来进行测试。相关的 vibe 代码和测试结果可在此处查看。每一列中的单元格始终由共识层（CL）进行批处理，但如何处理多个列的配置方式是变化的。
计算得到的“点评估倍数”在共识层 blob 数量增加时（图中的棕色和粉色线）会下降，这是批处理带来的性能收益。
虚线青色曲线显示，这种关系大致呈现出与目标 blob 数量的对数函数成反比的趋势。而执行层（EL）在 PeerDAS 中的 mempool 验证步骤（红色线），涉及单元格证明验证，在最坏情况下不会因 blob 数量的增加而受益。
该图表明，根据当前 Fusaka PeerDAS 规范，blobs 会给节点带来相当大的计算压力——尤其是与智能合约中一次点评估证明验证（其 gas 成本为 POINT_EVALUATION_PRECOMPILE_GAS）相比。
例如，一个全节点需要对所有通过 p2p 传播的 blobs 执行执行层（EL）的 mempool 验证（这一过程本身就比单次点评估高出 15 倍的计算成本）。此外，节点还需对 8 列进行采样，在目标为 32 个 blobs 的情况下，若按顺序处理（每列单独批处理），所需时间是点评估的 2 倍。而节点还需托管 4 列指定的列，这部分的计算成本与点评估大致相当。
如前所述，并行化验证是否可以视为等效还有待进一步细致讨论，这在更广泛的场景中同样是一个复杂的问题。
由于 KZG 证明验证会在多种不同的上下文中执行，如何对其定价是一个复杂的问题。在当前条件下，将最低价格设定为 POINT_EVALUATION_PRECOMPILE_GAS 可作为一种合理的折中或下限，代表对 blob 数据基本验证单位赋予的 gas 成本。
设计
为了确保 blob 交易能对验证者在验证其 KZG 证明时所带来的计算开销做出相应补偿，该提案建议引入一个按 blob 计的保底价格（reserve price），其基准为 POINT_EVALUATION_PRECOMPILE_GAS，经过重新换算后以 blob gas 的形式计费。具体通过以下 if 条件语句实现：
if POINT_EVALUATION_PRECOMPILE_GAS * parent.base_fee_per_gas > GAS_PER_BLOB * get_base_fee_per_blob_gas(parent):尽管该预编译合约的 gas 成本是用于特定的合约级操作，但它可以作为衡量与 blob 相关的基础计算工作的一个可理解的参考指标。由于执行层（EL）验证带来的最坏情况需要考虑，因此在计算中不会对多个 blob 进行摊销处理。
因此，协议将对 blob 基础费用（blob base fee）设置一个保底值：
b_blob = 50000 × b_exec / 2^17其中，b_exec 表示执行层的 base fee。
意义
通过这项变更，协议所表达的立场是：blob 交易在计算资源上的使用权并不优于其他交易，除非它们按当前市场价格（即执行层 base fee）为所占计算资源支付公平的费用。因此，blob 交易必须支付至少相当于一次 POINT_EVALUATION_PRECOMPILE_GAS 的 blob base fee，这构成了新的 保底价格（reserve price），并通过 blob gas 来支付。
此外，blob 数据本身的费用依旧是另外计算的，完全由市场出清价格决定，但该价格会考虑保底费作为下限。
从机制设计角度看，该提案（EIP）将解决两个独立的问题：
确保 blob 使用者至少为他们引发的计算负担付费，而关于数据本身的其他费用则由独立的 blob 费用市场决定；
确保 blob 费用更新机制能正常运行，通过设立一个与最低执行成本相当的价格底线（这是前文中提到的理由）。
通过将证明验证的成本纳入 blob base fee，这两个目标（1 和 2）可以同时达成。任何在独立费用市场中加在计算成本之上的费用，都是针对数据本身的。由于这个 base fee 是以 blob gas 支付的，而 blob gas 全部被销毁，因此不会产生额外的优先费成本（尽管 blob 交易仍可为自身设置优先费）。
而且由于 POINT_EVALUATION_PRECOMPILE_GAS > TX_BASE_COST，所以在构建有效的费用市场机制时无需再单独考虑交易开销。这可以理解为一种复合型费用市场设计，即以“基础”资源（执行层计算）的成本作为“次级”资源（blob 数据）的保底价格。
需要注意的是：该变更会显著提高 blob 的最低费用，相较于此前的提案更加昂贵。因为此方案不进行任何摊销处理，每个 blob 都需单独承担其成本，而 POINT_EVALUATION_PRECOMPILE_GAS = 50000，是 TX_BASE_COST = 21000 的两倍多。因此，最低 blob base fee 大约是执行层 base fee 的 38%：
POINT_EVALUATION_PRECOMPILE_GAS / GAS_PER_BLOB = 50000 / 131072 ≈ 0.38举例说明：
若执行层 base fee 为 1 gwei，则最低 blob base fee 为 0.38 gwei；
若执行层 base fee 为 2.62 gwei，则最低 blob base fee 为 1 gwei；
若 blob base fee 为 1 gwei，ETH 价格为 $2500，则协议对一个 blob 的最低收费为 131072 × 1 × 2500 / 10^9 = 0.33 美元；
若执行层 base fee 为 26.2 gwei，则最低 blob base fee 为 10 gwei，费用则高达 $3.3 美元/每个 blob。
但重要的是要理解：blob 使用者实际是在为他们确实带来的计算负担付费，而这一费用本质上也同样适用于智能合约（通过 POINT_EVALUATION_PRECOMPILE_GAS 计费）。这不是一个任意设定的费用，而是一种中立、公平的方式，用于解决当前费用市场设计中存在的两个问题。
此外，当执行层计算资源紧张、价格上涨时，交易在 L1 上的费用也会与最低 blob base fee 一样，以相同比例上涨。
替代设计
如图 1 中青色曲线所示，共识层（CL）每个 blob 的验证成本似乎随着处理的 blob 数量增加而近似呈对数下降。如果未来执行层（EL）对 blob 的处理效率得到提升，那么最低的 blob base fee 也可以依据这种细致的摊销方式，随着 blob 数量的增加而递减。
不过，遗憾的是，执行层中并没有内建的对数函数。一个简洁的方式是，通过计算目标 blob 数量的 bit 长度减去 1，即可得到 base-2 对数的整数部分（⌊log₂N⌋）。这个计算过程等价于 Python 中的表达式：(target).bit_length() - 1。
将最低 blob base fee 与执行层 base fee 挂钩，确保了 blob 使用者根据当前节点计算资源的供需状况支付相应费用。然而，直接使用常量 POINT_EVALUATION_PRECOMPILE_GAS 虽然目前看起来合理，但从长远看可能并非最优方案。毕竟，POINT_EVALUATION_PRECOMPILE_GAS 本身在未来也可能因高证明成本等原因而被调整。
此外，即使计算成本确实对应于 POINT_EVALUATION_PRECOMPILE_GAS，以太坊也可能出于战略目的，在数据可用性（DA）方面愿意“亏本引流”（loss-leader），从而在初期选择以更低的常数进行定价。
实证分析
图 2 和图 3 展示了在两个时间段内的价格演变情况：2024 年 11 月（三周期间平均执行层 base fee 约为 16 gwei）和 2025 年 3 月（平均约为 1.3 gwei）。图中用黑色表示实际观测到的费用，用蓝色表示 POINT_EVALUATION_PRECOMPILE_GAS 的成本，并按机制要求将其换算为最低的 blob base fee。
EIP-7918 采用这两条曲线中较大的一个作为 blob 的费用下限，图中用较深颜色表示这一值。可以明显看出，当执行层 gas 价格较高时，最低 blob 费用也随之变得相当可观；而当执行 gas 较便宜时，最低费用也会相应降低。
图 4 显示了从 2024 年 11 月（图 2 数据期开始）至 2025 年 3 月（图 3 数据期结束）这四个月期间观测费用及两条曲线较大值的直方图，涵盖约 90 万个区块，起始区块号为 22075724。直方图采用每十倍区间 100 个对数间隔的分箱，并通过宽度为 21 的汉宁窗进行平滑处理，边缘采用镜像反射。
欢迎关注 ETHPanda 获取更多资讯！
