NFT 元数据里的 dStorage 字段：ERC-5625 想让你查到账存在哪

一枚 NFT 的链上记录通常只指向一个 tokenURI，指向的 JSON 里再给出图片地址。图片文件本身存在哪——某家公司的网页服务器、IPFS 节点，还是 Filecoin 存储商——现有元数据格式并不要求说清楚。ERC-5625 就是补这一块的：它在 ERC-721 和 ERC-1155 的元数据 JSON 架构上增加一个可选的 dStorage 键，专门描述资产文件在去中心化存储系统上的存放信息。该提案状态为 Final（最终标准），创建于 2022 年 9 月 8 日。本文只解释字段机制，不构成任何购买建议。

六个子字段各自回答什么问题

按规范，dStorage 对象内的六个子字段都是必填：platform 写存储平台名，比如 Filecoin、Arweave、Swarm 之类；description 是对该平台的一句话说明；persistence_mechanism 描述持久化或激励结构，比如是基于区块链的还是基于合约的；challenge_mechanism 描述平台如何验证数据仍然可用，规范举的例子是 Arweave 的 proof-of-access；consensus 写平台用的共识机制；dstorage_note 则放一条可回溯的存储凭证，例如 Filecoin 的 deal id 或者 Crust 下单交易的哈希。

它是元数据扩展，不是存储协议

要理解 ERC-5625 的边界：它不搬运任何文件，也不和任何存储网络对话。它只是要求发行方在 JSON 里”自报家门”。而且这个键是 OPTIONAL 的——合约可以完全不用；就算用了，写入的也是一段声明文本。标准原文的定位就是促进去中心化存储信息的可读性，并不是提供存储证明。

这个字段能证明什么、不能证明什么

诚实填写的 dstorage_note 给了核验的入口：拿着 deal id 去存储网络查交易记录，能确认当初确实下过单、付过存储费。但它不能证明三件事：文件今天是否还有节点在提供（激励到期、副本过少都会让内容悄悄消失）；链上 JSON 里的 dStorage 与当前文件是否一致（元数据可能指向合约或服务器上的可变内容）；发行方填的是不是真凭证（字段本身不验证签名）。换句话说，它把”你存在哪”从空白变成可查询，但核验动作仍然在你这边。

查看一枚 NFT 时可以走的顺序

1. 读 tokenURI 指向的 JSON，先看有没有 dStorage 键；没有不代表文件一定丢失，只是发行方没按这个扩展披露。
2. 有 dStorage 时，逐项比对 platform 与实际服务、dstorage_note 与链上或存储网络的可查记录。
3. 对 image 字段指向的地址做实际请求测试，看返回的是原始文件还是占位图。
4. 注意元数据 JSON 本身放在哪里：一个链下可变 JSON 里的 dStorage 声明，随时可以被改掉。

标准在动机部分点名了一个现实：主流市场自定的元数据字段（external_url、attributes 这一类）早已被其他平台默认跟随，但这套事实标准同样不携带任何存储信息。ERC-5625 选择把扩展加在元数据 JSON 上而不是给合约加接口，图的是沿用现有工具链——钱包与市场解析 JSON 时顺手就能读到 dStorage。

普通读者最实用的一课，是分清这条指针链：链上代币记录指向 tokenURI，tokenURI 指向的 JSON 里 image 字段再指向资产文件，dStorage 则描述文件存放在哪个存储系统。链条里任何一环指向可改写的地址，整条链的”永久”都站不住。真正稳妥的自查是把图片与 JSON 都下载留档，再拿 dstorage_note 反向去存储网络找凭证，确认发行方至少曾经付过存储费——这属于声明核验，不是所有权保障。

还有一点常被误解：dStorage 是可选扩展，合规实现完全可以在不用它的情况下把文件存得很好，也有合集填了字段却指向随时改名的域名。因此这个字段适合当”发行方愿意披露多少”的参考指标，而不是”能不能买”的门槛。同一份规范里还有个细节值得留意——六个子字段一旦被启用就全部必填，缺项的 dStorage 说明发布者连模板都没走完，反而是可以当面追问的信号。

存储声明只是线索，不是保险单；评估藏品耐久度时请结合自己的下载与验证结果，本文不构成任何投资建议。