- EIP-4844 经济学#1: 深入 EIP-4844 费用机制（本文）
- EIP-4844 经济学#2: 深入 Rollup 数据可用策略
- EIP-4844 经济学#3: 深入多维资源定价
- EIP-4844 经济学#4: 深入 Type 3 交易打包策略
- Type 3 交易与其他类型的交易同样具有触发 EVM 执行的能力，EVM 维度的费用覆盖该成本。
- Type 3 交易不同于其他类型的交易，能够携带 Blob，Blob 维度的费用覆盖该成本。
- 该交易在 Etherscan 上似乎是一笔 0 ETH 的转账交易（Gas: 21,000），而实际上是一笔 Type 3 Blob 交易（Txn Type 字段标记为 3）
- Etherscan 的费用只覆盖了 EVM 维度
- 这笔 Type 3 交易携带了 6 个 Blob
- 根据 EIP-4844 的规范，每个 Blob 大小为 128 KB，消耗 的 Data Gas。
- 该交易携带总计 768 (= 128 * 6) KB 的 Blob，需要消耗 * 6 = 786,432 的 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 数据资源以及现今以 EVM Gas 计价的资源（计算资源，存储资源 等）
- Blob 数据资源的价格只取决于自身的供需
- 不同资源间的相对 Gas 常常需要调整，而调整 EIP 需要硬分叉才能生效。因此，具有准确度不高且更新效率低下的问题。
- 不同资源耦合在一起，互相作用，带来副作用。下面举例说明：
- 存储资源的需求（如 SSTORE 的使用）变高，导致 GasPrice 上涨，从而存储资源的成本上涨
- 即使计算资源的需求（如 ADD 的使用）不变，由于 GasPrice 上涨，计算资源的成本也随之上涨
- 然而，计算资源成本不变，存储资源成本上升，更为合理。
- 不同资源的 Gas 是相互独立和定价的，因此不需要调整。
- 资源的价格只受自身的供需决定，定价更为合理。
- m：MIN_DATA_GASPRICE
- ：区块 n-1 为止累计的 Data Gas 消耗超过目标的数量。
- 值得注意的是 ，即当累计的 Data Gas 低于目标，则 Data GasPrice 会被设置为 MIN_DATA_GASPRICE。
- s：DATA_GASPRICE_UPDATE_FRACTION，即更新幅度因子，用于限制相邻区块 Blob Base Fee 的变化幅度。
- 当区块消耗的 Data Gas 一直高于目标值，Blob Base Fee 会指数上涨
- 当区块消耗的 Data Gas 一直低于目标值，Blob Base Fee 会指数下跌，直至 MIN_DATA_GASPRICE
- 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
由于 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，仍有激励区块提议者的方式：
- 可以利用 EIP-1559 下定义的 Priority Fee。然而，Priority Fee 的计算基数是 。因此，在此场景下，需要进行转换，而 Rollup 运营方完全有能力做好这些转换。
- ：愿意在 EVM 维度给的 Priority Fee
- ：愿意在 Blob 维度给的 Priority Fee
- 在 PBS 的架构下，Rollup 运营方可以利用隐私交易服务（如 flashbots）直接给 builder 转账津贴以达到 Priority Fee 的效果。
- Type 3 交易涉及两个维度的费用，各个维度有自身的约束和不同的性价比，需要综合考虑。
- Type 3 交易的 blob 容易因为传输延迟问题造成区块重组。
- 当 Blob 被完全利用时，数据均摊成本是最低的
- 当 Blob 被完全利用时，数据延迟成本是最高的（等待最长时间才能提交至一层网络）
- Calldata 的数据均摊成本是不变的，无需如 Blob 般等待数据达到某种量级以降低成本，因此可以做到快速发布，因而有着更低的数据延迟成本。
- 可以预想，有着较少交易量的 Rollup 会更倾向于使用 Calldata。这些 Rollup 需要付出很大的数据延迟成本才能把 Blob 填充完。
- Vitalik 更倾向于限制 Calldata 的使用，让 Rollup 都使用 Blob。
- 对于 Rollup 而言，维护两套机制成本太高。
- Calldata 本身不是为数据可用设计的。
