很多人把 Blob 理解成一种”塞在交易里的附件”，但对照 EIP-4844 的规范看，Blob 根本不住在交易里。交易本体只携带一组承诺哈希，Blob 数据本身走的是另一条通道，EVM 从头到尾碰不到它。搞清楚这种分离，才算理解这条为二层数据上链专门开的费用市场。本文逐字段拆一遍这种被称为类型三交易的结构，以及它的两个配套部件。
类型三交易本体：字段清单
EIP-4844 在 EIP-2718 的交易类型框架下注册了类型字节 0x03。交易体按 RLP 序列化的字段依次是：链标识、随机数、优先费上限、每 gas 总费上限、gas 上限、to、价值、data、访问列表，再加两个新面孔——max_fee_per_blob_gas 与 blob_versioned_hashes，最后是签名字段。前十个字段的语义与 EIP-1559 类型交易一致，新东西只有两个：前者是发送方愿意为每个 blob gas 支付的单价上限，后者是一串版本化哈希。
blob 本身去哪里了？答案是侧车。包含 Blob 的完整数据被拆到区块主体之外的旁路结构里，经共识层网络传播，由信标链节点保管，执行层区块体和 EVM 执行环境都不包含它。这正是设计目的：数据要公开可得，但不必进入每条合约执行的必经之路。区块头里额外携带一个字段，记录本区块所有 Blob 承诺经 KZG 多项式承诺方案聚合后的根。
版本化哈希：blob 如何被交易引用
每个 Blob 是一段 4096 个域元素、每个 32 字节的数据块，先由发送方算出一个 KZG 承诺，再做一步版本化变换：首字节固定写成 0x01，后 31 字节取承诺的哈希摘要，拼成一个 32 字节的版本化哈希，塞进交易的 blob_versioned_hashes 列表。EVM 里配了一个新操作码，让合约能按索引读出这笔交易声明的第几个版本化哈希。为什么绕一道哈希而不是直接放承诺？规范的解释是版本兼容：首字节标记方案版本，将来换承诺体制时老合约不受牵连。验证发生在另一头——共识层要求侧车里的每个承诺和每个数据块一一对应，承诺与数据错配的交易整个无效。
点求值预编译：链上验一个点
合约层唯一能碰到的验证部件，是地址 0x0A 上的点求值预编译合约，单次调用固定收 50000 gas。它接受一个 Blob 承诺、一个求值点、一个声称的值和一个 KZG 证明，验证”该承诺对应的多项式在这个点上确实等于这个值”。这套交互让无需下载 Blob 本体的参与方也能核验其中一个片段——挑战者抽查某个坐标，证明方当场给出该点取值和证明，代价是一次预编译调用。它也是未来从”全部下载”过渡到分片采样方案时预留的接口。
定价与两个容易踩的误区
Blob 有独立的费用市场。规范给每个 Blob 记 131072 的 blob gas，参数表里写定目标值 393216 与上限 786432，换算下来就是规范在动机部分说的每区块约 0.375 MB 目标、约 0.75 MB 上限；基础费按区块实际用量相对目标的增减做指数调节，用量持平则费用不变。常见误区一：把这些数字当成永久不变的”带宽”——参数会随后续升级小步上调，写死任何数值都有过期风险，落账前应对照客户端参数表。误区二：以为交易里的 to 可以留空。规范明确 to 不得为空，因此类型三交易不能用于部署合约，发 Blob 的程序必须先存在于链上。
还有一个保鲜期问题。Blob 只在共识层保留一段窗口，规范常量写作 4096 个纪元，按 32 个时隙一个纪元、每时隙 12 秒折算约 18 天，之后节点即可删除，这也是为什么”过期删除”与”长期归档由谁负责”是二层必须各自回答的问题。对普通用户，这一切落在感知层面只有一条：二层把批次发进 Blob 费用市场而不是 calldata 后，数据费由这条独立市场定价，费用构成和拥堵表现都与主网操作费解耦。本文仅为协议机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。