以太坊上的数据上链，近年多了一条比 calldata 便宜得多的通道：blob。ERC-7588 就是顺着这条通道长出来的元数据标准，它的定位很清楚——不是让数据存得更便宜，而是让读的人知道这坨 blob 字节到底该按什么格式解读。
先看背景。EIP-4844 给以太坊交易引入了一种新类型：每笔交易可以附带若干块固定大小的二进制数据（blob），它不进 EVM 的执行环境、不能被合约直接读取，只以承诺形式短暂保留在节点上供验证，所以费用远低于把同样字节塞进 calldata。便宜的另一面是「薄」：数据不在合约状态里，没有类型标注，也没有生命周期。用 blob 记录数据的协议，等于把内容放进一间公共、廉价、但会过期且不写说明书的房间里。
ERC-7588 解决的就是「没有说明书」这一层。按 2024 年 1 月创建、状态为 Final 的规范正文，元数据本身是一个 JSON 对象，它的字符串形式被放在 blob 交易的 data 字段里，而 blob 们挂在同一笔交易的 blob 列表中——也就是说，说明书和货物在同一条交易里一起上链。这份 JSON 有一套预定义的模式：originator 标明 blob 的发起方，description 描述内容，content_type 按 RFC 2046 给出 MIME 类型，extras 放动态附加信息，还有一个可选的 blobs 数组，按顺序为每一块 blob 各自补充 description，与上层字段叠加覆盖。读的人不需要猜：先取 data 字段解析这段 JSON，判断数据类型、分片方式与内容形态，再决定如何组装与渲染。对索引器和展示端来说，这是把「每个协议各写一套私有约定」变成「先读标准字段」，跨工具兼容的成本因此下降。
把这条路线和传统 NFT 对照，差别一眼可见。合约型 NFT 的内容指针在 tokenURI 里，媒体与属性大多存链下；blob 路线的内容本体就在那笔交易的 blob 里，好处是出处链上可查、发行时无需任何合约地址；代价是 blob 数据的可见期由协议的保留策略决定，需要长期保留的对象必须把 blob 内容同时镜像到链下或永久存储，并留下能重建内容的锚点。也正因如此，元数据标准与镜像方案是配套的两件事，缺一件就只剩半条路。
核对这类对象时建议做四件事。第一，确认那笔 blob 交易的 data 字段是否真的是一段可解析的 ERC-7588 JSON，光有 blob 不代表存在标准元数据；顺带核对 originator 与 content_type 是否填了内容，空字段的说明书等于没有。第二，按 JSON 字段里的交易引用去取那笔 blob 交易，别用搜索引擎给出的摘要页替代原始来源。第三，检查内容镜像位置是否仍然可达——把「当时能取到」当成「一直能取到」是这类对象最常见的误判。第四，看清协议自己写的保留与重建说明，注意标准正文的定稿状态与生效版本。作为机制样本，ERC-7588 的价值在于它承认了一件事：廉价数据通道要长期可用，前提是先给数据配一份能被别人读懂的说明书。本文不构成投资建议。
把 ERC-7588 放回铭文演化的时间线里看更有意思。比特币铭文把内容直接放进交易的见证数据，元数据靠协议自身的信封格式承载；以太坊这边早期等价物是把 Data URI 塞进 calldata，费用随字节线性膨胀。blob 通道出现后，同样的内容用 blob 携带，单位成本大幅下降——这不是因为以太坊改了计费规则，而是 blob 本来就不进执行层、只作短期数据可用性存在，验证用途用完即可释放，硬件存储与带宽的账单结构跟 calldata 完全不同。协议方正是在这个背景下考虑给 blob 配说明书的：数据可用性层越来越便宜，缺的只是一个让所有人读得懂的信封格式。说明书补上后，剩下的短板也就清晰了：会过期的仓库不能单独当档案馆，镜像与长期存储必须发生在链下、由某个检索服务兑现。这也是为什么看 blob 类藏品时，标准元数据只是第一道核验，第二道永远是「现在还能不能完整取回那份 blob」。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。