元数据也在链上：Art Blocks 把描述与渲染代码一起存进合约的方案

大部分 NFT 的元数据是一条链接，链的那头是别人的服务器。Art Blocks 官方文档给自家方案的定位正对着这个软肋：其代币把元数据完全存储在链上，以此向收藏者保证作品永远可访问、不可变更。这句话在每个字上都值得推敲——链上存的是什么、由谁组装、用什么渲染，官方两页文档给了完整答案。

先看链上生成器这一页。它的职责是把艺术家的脚本、代币哈希和依赖库三样东西，从链上存储的数据里拼装成一份浏览器可渲染的完整 HTML 文档——强调一遍，全部原料来自链上数据。这就是 tokenData 的对象结构要解决的问题：一枚代币的画面不是某个服务器缓存的成品图，而是每次展示时按同一算法、同一种子现场重算的确定性结果。文档同时点明 tokenData 结构与艺术家脚本的技术要求相关，脚本本身按平台规范部署进链上存储。

再看这条链上 HTML 的取回路径，官方文档给的方法很具操作感：对合约调用返回 HTML 的函数（getTokenHtml 一类），拿到文本后直接就是生成该代币输出的网页代码；还可以调用 getTokenHtmlBase64EncodedDataUri，取回 base64 编码的 data URI 形式，粘贴进浏览器地址栏，就能看到该代币的画面。这个演示看似炫技，实际是最硬的验证——渲染不依赖任何外部请求时，粘贴 data URI 出图这件事本身，就证明了作品不欠任何服务器一份字节。

依赖问题的处理常被忽略。生成艺术很少从零写起，艺术家会用到公共库；如果库文件在链下，不可变性就有裂缝。文档给出的答案是 Dependency Registry：一个完全链上的软件登记库，可选择把依赖发行版直接存上链，也可以指向偏好的存储网络。换句话说，链上元数据的承诺是分层兑现的——核心脚本与参数在链上，第三方依赖通过登记库管理，收藏者可以顺着登记库核对一枚代币实际引用了哪个版本的哪个库。

把这套方案放进更大的坐标系。多数项目的元数据方案是链上指针加链下内容，验证靠哈希；完全链上方案把内容与描述都搬进区块，验证变成重放。代价同样明确：体积受区块容量约束，渲染算力发生在用户的浏览器里，Gas 成本推高发行门槛。它也不意味着与世隔绝——前文机制篇讲过 PostParams 可以按预设规则改参数、Transfer Hooks 可以在转账时挂逻辑，这些都是协议内声明过的可变面。

给收藏者的启示可以归成一句：看元数据形态时问三个问题——描述文件在链上还是链外、渲染时要不要发外部请求、依赖版本能不能审计。三个答案决定一枚 NFT 十年后还能不能原样打开，也决定平台服务器宕机那天与你有多大关系。本文为机制说明，不构成任何投资建议。

对内容创作者的启示也值得写下来。完全链上元数据是一条可以模仿的技术路线而不是 Art Blocks 专利：任何合约都可以把元数据 JSON 直接编进合约返回值，用 base64 的 data URI 返回，跳过所有外部主机。代价是每条字节都要付铸造费，适合文本、参数和小型脚本，不适合原片视频。理解这条光谱再谈去中心化：链下指针、IPFS 哈希、data URI、完全链上 HTML 是四档不同承诺，宣传语常常跨档引用——看到永存字样，先看它对应哪一档，再看指针与依赖能不能审计。

普通读者还可用一个极简测试给任何 NFT 做体检：打开浏览器开发者工具的网络面板，进项目的官方页面加载一枚代币，看渲染请求里除了区块链节点 RPC，是否还向图片服务器、CDN 或第三方 API 拉取资源。全链上方案的网络面板应当近乎干净；依赖列表越长的 NFT，对外部主机的债务越多。这个测试不需要任何专业知识，十几秒就能给一枚 NFT 的耐久性一个经验读数，也顺带解释了为什么同一合约系列里，有的作品断网也能打开，有的离了前端就只剩空白。