EIP-4844: 片段 Blob 交易规范 (Proto-Danksharding)

EIP-4844 是以太坊坎昆（Cancun-Deneb）硬分叉的核心升级，引入了专门面向 Layer 2 Rollup 的临时数据载体——携带 Blob 的交易（Blob-carrying Transactions，Type-3）。

在 EIP-4844 之前，Rollup 依赖执行层的 calldata 存储批量交易压缩包，成本昂贵且永久占用全节点磁盘。EIP-4844 将数据发布与 EVM 执行解耦，建立了独立的暂时性存储通道与动态费用市场。

Type-3 交易结构与执行层隔离

EIP-4844 引入了新的 EIP-2718 交易信封类型 0x03。

1. 交易物理负载解耦

Type-3 交易在网络传输层包含两套数据结构：

执行层可见负载（Execution Payload）：包含交易基础字段（nonce、gas_limit、to、value、data）以及两个新字段：
- max_fee_per_blob_gas：用户愿意为每单位 Blob Gas 支付的最大单价。
- blob_versioned_hashes：包含若干 32 字节哈希的数组，每个哈希对应一个挂载的 Blob。
共识层临时附件（Blob Sidecar）：包含具体的 128 KB Blob 原始字节、KZG 多项式承诺（Commitment）以及对应的开值证明（Proof）。

flowchart TD
  subgraph BlobTransaction["Type-3 交易负载 (P2P 广播)"]
    direction TB
    Tx[执行层交易体<br/>max_fee_per_blob_gas<br/>blob_versioned_hashes]
    Sidecar[共识层 Sidecar<br/>128 KB Blob 原始数据<br/>KZG Commitment & Proof]
  end

  Tx -->|进入区块并在 EVM 结算| EL[以太坊执行层 Execution Layer]
  Sidecar -->|在共识层 P2P 传播并暂存 18 天| CL[以太坊共识层 Consensus Layer]

  EL -.->|仅暴露 BLOBHASH 操作码| SmartContract[L1 智能合约<br/>Rollup 核心逻辑]

2. 为什么 EVM 无法直接读取 Blob 明文？

EIP-4844 规定：智能合约在 EVM 执行环境中严禁直接访问 Blob 的原始数据字节。

吞吐保护原理：如果 EVM 能够在智能合约中逐字节读取 128 KB 甚至上兆字节的 Blob 数据，区块执行的计算开销将导致节点验证出现严重延迟，破坏网络去中心化。
版本化哈希操作码 BLOBHASH： EVM 仅新增了一个操作码 BLOBHASH (0x49)：
```
// 从交易中读取第 index 个挂载的 blob 对应的 32 字节哈希
bytes32 versionedHash = blobhash(index);
```
versionedHash 的首字节固定为版本标识符（当前为 0x01），后 31 字节为对应 KZG Commitment 的 SHA-256 哈希截断。Rollup 仲裁或验证合约通过比对该哈希与链下提交的点值证明，在零知识或交互式欺诈证明中证明某笔交易确实存在于该 Blob 中。

密码学基石：KZG 多项式承诺

每个 Blob 包含 4096 个有限域上的标量元素（Field Elements，标量属于 BLS12-381 曲线标量域），对应 128 KB 数据大小。

1. 从数据向量到多项式

Blob 数据被视作多项式在特定单位根（Roots of Unity）子群上的取值：

$$ p(\omega^i) = d_i \quad (i \in [0, 4095]) $$

协议通过拉格朗日插值法，将 128 KB 数据隐式映射为唯一的最高 4095 次多项式 $p(x)$。

2. KZG 承诺与验证机制

利用以太坊启动仪式（Trusted Setup）生成的 SRS（Structured Reference String）参数，KZG 机制允许定序器在无需暴露完整多项式的情况下生成固定 48 字节的椭圆曲线承诺点：

$$ C = [p(\tau)]_1 \in \mathbb{G}_1 $$

点值证明（Opening Proof）：若需证明多项式在某点 $z$ 处的取值为 $y$（即 $p(z) = y$），证明者可构造商多项式 $q(x) = \frac{p(x) - y}{x - z}$ 的承诺 $\pi = [q(\tau)]_1$。
点式高效验证：L1 验证合约通过预编译合约 point_evaluation（地址 0x0A）在一次椭圆曲线配对（Pairing）计算中完成判定： $$ e(C - [y]_1,; [1]_2) \stackrel{?}{=} e(\pi,; [\tau - z]_2) $$

独立的多维动态费用市场 (Blob Gas)

EIP-4844 在以太坊原有的常规执行 Gas 之外，引入了独立的 Blob Gas 计费体系，二者互不干扰，彻底阻断了 Rollup 批量上链导致常规用户转账 Gas 暴涨的问题。

1. 目标容量与动态调价算法

目标容量（Target）：每个区块目标包含 3 个 Blob（384 KB）。
最大容量（Limit）：每个区块最多容纳 6 个 Blob（768 KB）。

Blob 基础费用（blob_base_fee）完全独立于 EIP-1559 执行层基础费用，基于指数调整机制根据历史区块的 Blob 供需状态自适应浮动：

$$ \text{blob_base_fee}_{t+1} = \text{blob_base_fee}_t \times \exp\left( \frac{\text{actual_blobs} - \text{target_blobs}}{\gamma} \right) $$

其中 $\gamma$ 为平滑常数。当近期区块的平均 Blob 数量持续高于目标值 3 时，Blob 单价呈指数级上升；当需求低迷时，单价回落至最低下限（1 wei）。

存储生命周期与剪枝规范

Blob 数据并非以太坊永久历史状态的一部分：

维度	常规 Calldata	EIP-4844 Blob
存储层级	执行层（Execution Layer）永久持久化	共识层（Consensus Layer）暂存
全节点保留时长	永久保存（全历史节点）	固定保留 4096 个 Epochs（约 18 天）
EVM 可读性	任意智能合约均可完全解析	仅能读取 32 字节 `BLOBHASH`
Gas 消耗类型	消耗常规执行 Gas（每非零字节 16 Gas）	消耗专用 Blob Gas（独立动态定价）
灾备与历史重构	随时可从主网全节点重放完整历史	18 天后全网自动剪枝，需依赖外部归档基础设施

Xu's Blog