把图片放进 IPFS，会拿到一个由内容算出的 CID，这是对内容本身做哈希得到的指纹，改一个字节，指纹全变。这个性质让 IPFS 擅长证明文件没被动过，却天然不适合我需要以后更新这个文件的需求。NFT 元数据恰好两样都要：既要可验证，又要可修订。官方概念文档里承担可修订这一半职责的，就是 IPNS，全称 InterPlanetary Name System。
先看清楚它要填的坑。IPFS 文档对内容寻址的原话很直白：内容寻址在本质上是不可变的，文件算出的哈希就是它的标识。想让指向跟着内容走，最直觉的办法是在别处维护一张映射表，先解析名字、再拿到真正的 CID。传统 DNS 就是这种思路，但它把信任交给了注册机构。IPNS 的答案完全不同：不引入任何注册方，让一个密钥对替你签名。
拆开 IPNS 记录本身，文档给出的结构是三样东西加一个签名。第一样是内容路径，也就是这条记录当前指向的 CID；第二样是序列号，文档写明只有当内容路径发生变化时序列号才递增，接收方用它判断新版本是不是真的更新；第三样是有效期与 TTL 一类的生命周期字段，共同决定记录能被缓存多久。这三样拼在一起，再用地基私钥做密码学签名，就构成一条完整的 IPNS 记录。只要签名验证通过，拿到记录的人不需要询问任何服务器，就能确认这条指向确实是密钥主人发布的。
由此能理解一个容易被误解的设定：IPNS 名称本身就长得像一个 CID。文档举的例子显示，那串 k51 开头的名称其实是公钥的 CIDv1 编码，也就是说名字是从密钥推导出来的，谁握着私钥，谁就能发布新版本。没有注册表、没有管理员，也就没有找回流程，私钥丢了，这个指针就永远停在最后一次发布的版本上。这跟域名可以走注册商申诉的逻辑截然相反。
发布和解析的路径也值得交代。按文档的说明，新版记录随时可以由私钥持有者签名发布，通常发布到 DHT 这类分布式哈希表里；文档同时提醒，也可以用网关方式发布和解析 IPNS 名称，两条路各有成本与延迟。读取者拿着 IPNS 名字去解析，拿到的记录里是当前指向的 CID，再去取内容。缓存的 TTL 设置得越长，解析越快，但更新生效越慢，这是同一根杠杆的两端。
放进 NFT 元数据的场景对比一下就清楚了。一种做法是 tokenURI 直接写死 CID：不可更新，但永远可验证，作者之后没有任何通道能换掉文件。另一种是写死一个普通网址：可以换内容，但换到什么完全取决于那台服务器，验证能力为零。IPNS 介于两者之间，tokenURI 指向一个 IPNS 名称，名称不变、指向可换，每次换指向都需要作者私钥签名，链上读者能验签名、能查序列号有没有跳号。它保留了可撤销性，把谁有权变这件事从服务器权限收回到了密钥本身。
最后给三条使用侧的提醒。第一，验证一个 IPNS 指针的历史是否清白，靠的是能否比对多份带签名的历史记录，只有最新一条记录时无法审计作者有没有偷偷改过指向。第二，把 NFT 元数据指向 IPNS，等于承认元数据可更新，这与直接指向 IPFS 的不可更新承诺是两种不同契约，购买前应当弄清属于哪种。第三，密钥保管决定一切，用硬件或多签保护签名密钥，比选哪种指针技术重要得多。本文为机制说明，不构成任何投资建议。
顺带把 IPNS 与两条近邻路线摆在一起。data URI 把小文件直接编码进链上或链上指针，体积昂贵但零依赖；Arweave 类永久存储把内容一次写死，检索依赖网络健康度；IPNS 负责的是第三条光谱——内容可以搬来搬去，签名固定不变。三种形态没有绝对优劣，只对应不同的契约：data URI 承诺永不改，永久存储承诺不再搬，IPNS 承诺改得可验证。一个成熟的项目常常三样混用——封面走 data URI，长尾内容挂 IPNS，静态档案进永久存储——读方案时按每样资产各自的光谱位置评估，比给整套方案贴一个去中心化标签诚实得多。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。