以太坊知多少｜深入 EIP-4844 费用机制

作者：Jason, ETHconomics Research Space

目录

• 写在前面
• Type 3 交易费用
• EVM 维度
• Blob 维度
• 多维资源定价
• 多维资源定价解决的问题
• Blob Base Fee 更新算法
• Blob Base Fee 的自适应特性
• Blob Base Fee 的冷启动过程
• 相邻区块 Blob Base Fee 的波动范围
• Blob Base Fee 更新算法与现有 EIP-1559 的关系
• Blob Base Fee 是否会被销毁？
• Blob 是否有 Priority Fee ?
• Rollup 的数据可用策略
• 总结
• 相关资料

写在前面

EIP-4844 主要分为两块：支持 blob 交易（Type 3 交易）以及专属 blob 的费用市场。前者更侧重新架构设计与实现，因而更受开发者的关注。实际上，后者的设计和细节颇多，属于以太坊经济学的范畴。EIP-4844 经济学系列主要针对后者进行深入分析，希望读者能感受到以太坊经济学的趣味之处。

EIP-4844 经济学系列：

• EIP-4844 经济学#1: 深入 EIP-4844 费用机制（本文）
• EIP-4844 经济学#2: 深入 Rollup 数据可用策略
• EIP-4844 经济学#3: 深入多维资源定价
• EIP-4844 经济学#4: 深入 Type 3 交易打包策略

Type 3 交易费用

先以一笔 Type 3 交易为例，让大家对 EIP-4844 的费用机制有个直观的概念。本文撰写时 EIP-4844 仍未上线主网（计划于 2024 年 3 月 13 日上线）。因此，我们以一笔 sepolia 测试网的 Type 3 交易为例进行分析。

实际上，Type 3 交易费用分为两个维度：EVM 维度以及 Blob 维度

• Type 3 交易与其他类型的交易同样具有触发 EVM 执行的能力，EVM 维度的费用覆盖该成本。

• Type 3 交易不同于其他类型的交易，能够携带 Blob，Blob 维度的费用覆盖该成本。

EVM 维度

利用 Etherscan，我们可以洞察 EVM 维度费用的计算方式

EVM 维度费用的计算跟其他类型交易类似

• 该交易在 Etherscan 上似乎是一笔 0 ETH 的转账交易（Gas: 21,000），而实际上是一笔 Type 3 Blob 交易（Txn Type 字段标记为 3）

• Etherscan 的费用只覆盖了 EVM 维度

Blob 维度

若要观察 Type 3 交易中的 Blob 部分需要有另外的观察工具 blobscan。

不同于 EVM 维度的费用市场，Blob 维度的费用市场是独立的。

• 这笔 Type 3 交易携带了 6 个 Blob

• 根据 EIP-4844 的规范，每个 Blob 大小为 128 KB，消耗 的 Data Gas。
• 该交易携带总计 768 (= 128 * 6) KB 的 Blob，需要消耗 的 Data Gas。

• Type 3 交易类似于 Type 2 交易（EIP-1559）可以指定 max_fee_per_data_gas，防止 Blob 维度费用过高。

• Type 3 交易中的 Data Gas 与 EVM Gas 无关，没有可比性

• Type 3 交易中的 Data GasPrice 与 EVM GasPrice 无关，没有可比性

多维资源定价

大家或许没有发现上文展示的二维计价模式对于以太坊而言实际上是很特别的。习以为常的思路应该是当引入新的资源 Blob 时，在规范给 Blob 设置一个合理的 Gas 即可。

EIP-4844 实际上是以太坊通往多资源定价的里程碑：

• 区分 Blob 数据资源以及现今以 EVM Gas 计价的资源（计算资源，存储资源 等）
• Blob 数据资源的价格只取决于自身的供需

多维资源定价解决的问题

多维资源定价主要解决了以往大一统 Gas 带来的问题：

• 不同资源间的相对 Gas 常常需要调整，而调整 EIP 需要硬分叉才能生效。因此，具有准确度不高且更新效率低下的问题。
• 不同资源耦合在一起，互相作用，带来副作用。下面举例说明：

1. 存储资源的需求（如 SSTORE 的使用）变高，导致 GasPrice 上涨，从而存储资源的成本上涨
2. 即使计算资源的需求（如 ADD 的使用）不变，由于 GasPrice 上涨，计算资源的成本也随之上涨
3. 然而，计算资源成本不变，存储资源成本上升，更为合理。

在多维资源定价下，

• 不同资源的 Gas 是相互独立和定价的，因此不需要调整。
• 资源的价格只受自身的供需决定，定价更为合理。

Blob Base Fee 更新算法

类似于 EIP-1559，EIP-4844 有着一个由网络根据 Blob 供需决定的 Blob Base Fee。具体使用的是指数型 EIP-1559 更新算法。区块 n 的 Blob Base Fee 由以下公式决定：

• ：MIN_DATA_GASPRICE
• ：区块 n-1 为止累计的 Data Gas 消耗超过目标的数量。
• 值得注意的是 ，即当累计的 Data Gas 低于目标，则 Data GasPrice 会被设置为 MIN_DATA_GASPRICE。
• ：DATA_GASPRICE_UPDATE_FRACTION，即更新幅度因子，用于限制相邻区块 Blob Base Fee 的变化幅度。

Blob Base Fee 的自适应特性

Blob Base Fee 具有自适应的特性：

• 当区块消耗的 Data Gas 一直高于目标值，Blob Base Fee 会指数上涨
• 当区块消耗的 Data Gas 一直低于目标值，Blob Base Fee 会指数下跌，直至 MIN_DATA_GASPRICE

Blob Base Fee 的冷启动过程

EIP-4844 中 MIN_DATA_GASPRICE 被设置为 1。这意味着在累计的 Data Gas 低于目标时，Blob Base Fee 会一直维持在最小的非零整数 1 上。

一方面，文章 EIP-4844 Fee Market Analysis 中研究发现 Rollup 的历史需求实际上是低于目标的。在刻舟求剑的假设下，Blob Base Fee 会一直保持在 1，而不会启动任何价格发现的流程。

另一方面，Rollup 运营方预计 EIP-4844 上线后 Blob 需求是比较大的，应该会超过目标（3 个 Blob）的。

真正答案可以在 EIP-484 上线后揭晓，我们可以持续关注 Blob Base Fee 的冷启动过程。

相邻区块 Blob Base Fee 的波动范围

基于上述更新算法，可以推算出相邻区块 Blob Base Fee 的波动范围。

根据 EIP-4844 的规范，有如下设置：

• MAX_BLOB_GAS_PER_BLOCK 为 786,432，代表 6 个 blob 消耗的 Data Gas
• TARGET_BLOB_GAS_PER_BLOCK 为 393,216，代表 3 个 blob 消耗的 Data Gas
• DATA_GASPRICE_UPDATE_FRACTION 为 3,338,477

可以得到相邻区块消耗的 Data Gas 的上下限

由于   MAX_BLOB_GAS_PER_BLOCK 是 TARGET_BLOB_GAS_PER_BLOCK 的两倍，因此

相邻区块的 Blob Base Fee 变化率 ratio 为

因此，得到 ratio 的上下限

相邻区块的 Blob Base Fee 变化率与 EIP-1559 中的 Base Fee 类似，都在 12.5 % 以内。值得注意的是，Blob Base Fee 不如 EIP-1559 一般对称（即，上限为 12.5%，下限为 -12.5%）。本质原因在于 Blob Base Fee 采用指数型的 EIP-1559 机制。

Blob Base Fee 更新算法与现有 EIP-1559 的关系

实际上，指数型 EIP-1559 机制和现有 EIP-1559 机制是同源的。

尝试对 exp(x) 进行泰勒展开，当 x 足够小时，exp(x) 约等于 x+1，可以推导出现有的 EIP-1559 机制：

在此近似下，相邻区块的变化率是对称的。

Blob Base Fee 是否会被销毁？

类似于 EIP-1559 中的 Base Fee，Blob Base Fee 也是会被销毁的。Blob Base Fee 会在 Type 3 交易在 EVM 中执行前销毁。即使在 EVM 中执行失败，Blob Base Fee 也不会退回。当前从 Etherscan 以及 Blobscan 等工具无法得知 Blob Base Fee 销毁的情况。我们可以通过 beaconcha.in 洞察 Blob Base Fee 销毁的情况：

Blob 是否有 Priority Fee ?

在 EIP-1559 中，Gas Price 由 Base Fee 和 Priority Fee 组成：

类比 EIP-1559，Blob 理应有 Priority Fee。然而，Blob 实际上是没有 Blob Priority Fee 的，即只由 Blob Base Fee 组成：

基于直觉考虑，Priority Fee 是用于激励区块提议者的方式，否则区块提议者没有动力去打包交易，毕竟 Base Fee 都被销毁掉了。

然而，Blob 实际上是不需要 Priority Fee 的。即使没有 Priority Fee，仍有激励区块提议者的方式：

1. 可以利用 EIP-1559 下定义的 Priority Fee。然而，Priority Fee 的计算基数是 。因此，在此场景下，需要进行转换，而 Rollup 运营方完全有能力做好这些转换。

• ：愿意在 EVM 维度给的 Priority Fee
• ：愿意在 Blob 维度给的 Priority Fee

1. 在 PBS 的架构下，Rollup 运营方可以利用隐私交易服务（如 flashbots）直接给 builder 转账津贴以达到 Priority Fee 的效果。

实际上，builder 或区块提议者在挑选 Type 3 交易进行打包时需要不同于其他类型的策略。主要考虑到：

• Type 3 交易涉及两个维度的费用，各个维度有自身的约束和不同的性价比，需要综合考虑。
• Type 3 交易的 blob 容易因为传输延迟问题造成区块重组。

在后续系列的文章会对这部分做更深入的分析。

Rollup 的数据可用策略

Rollup 实际在使用 Blob 作为数据可用方案上需要一定的策略。

一方面，主要是因为 Blob 采用的是集装箱的收费模型。因此，对于 Rollup 而言，需要权衡：

• 当 Blob 被完全利用时，数据均摊成本是最低的
• 当 Blob 被完全利用时，数据延迟成本是最高的（等待最长时间才能提交至一层网络）

另一方面，主要是 Blob 作为一种数据可用方案，并非完全优于 Calldata：

• Calldata 的数据均摊成本是不变的，无需如 Blob 般等待数据达到某种量级以降低成本，因此可以做到快速发布，因而有着更低的数据延迟成本。
• 可以预想，有着较少交易量的 Rollup 会更倾向于使用 Calldata。这些 Rollup 需要付出很大的数据延迟成本才能把 Blob 填充完。
• Vitalik 更倾向于限制 Calldata 的使用，让 Rollup 都使用 Blob。
• 对于 Rollup 而言，维护两套机制成本太高。
• Calldata 本身不是为数据可用设计的。

笔者认为在限制 Calldata 的使用后，Rollup 基本都会使用 Blob。Blob 的联合发布实际上可以解决 Blob 数据延迟成本过高的问题。现实世界的集装箱也不限于只装一家的货物。不过，Blob 的联合发布依赖于基础设施的建设，需要等待。

另外，Blob 的联合发布意味着 Rollup 需要分摊各自的成本。一种直觉的分配方案就是按 Blob 中各自的数据比例进行分摊。然而，这并非是完全合理的分配方案。这是因为小型 Rollup 相对于大型 Rollup 在 Blob 的联合发布上有着更大的需求和更多的获益，理应分摊更多的成本，即高于其数据比例。

在后续系列的文章会对这部分做更深入的分析。

总结

EIP-4844 的费用市场有着许多有趣的研究点：对多维资源定价的探索，更符合直觉的指数型 EIP-1559 的应用，Type 3 交易的 tip 巧思与挑选策略，Rollup 数据可用策略以及新型的 Blob 联合发布市场。欢迎加入 ETHconomics Research Space 一起讨论研究。

相关资料

• EIP-4844 spec
  https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md#parameters

• Exponential EIP-1559
  https://dankradfeist.de/ethereum/2022/03/16/exponential-eip1559.html

• EIP-4844 Fee Market Analysis
  https://ethresear.ch/t/eip-4844-fee-market-analysis/15078

• 文中列举截图的交易来源

• https://sepolia.etherscan.io/tx/0x818a970a060796a9426acd7dfc4245edfe24d398bfab9a7e7fc4be23851bb04a
• https://sepolia.blobscan.com/tx/0x818a970a060796a9426acd7dfc4245edfe24d398bfab9a7e7fc4be23851bb04a
• https://sepolia.beaconcha.in/block/5216786#overview

• 文中引用 Vitlalik 的评论来源
  https://x.com/VitalikButerin/status/1750183998523871561?s=20

• RollCall #2.1 Breakout - 4844 Testing
  https://www.youtube.com/watch?v=V8d0fQoMeP4

推荐阅读

/ About  Plancker

PlanckerDAO 是一个专注建设以太坊生态的社区，我们为开发者、产品经理和研究员提供多方面支持，致力于与以太坊共建人类的数字化美好未来。

Website：https://plancker.org/

Forum：http://forum.plancker.org/

Telegram：https://t.me/PlanckerDAO

Notion：https://planckerdao.notion.site/

Twitter：https://twitter.com/PlanckerDAO