算法就是作品本体：Art Blocks 把生成代码永久放在链上的代价

多数 NFT 存的是“作品在哪”：一条 URI 指向某台服务器上的图片。Art Blocks 的协议文档给出的答案不同，它把理念压缩成一句话——算法即艺术品：创作代码永久上链，铸造时生成的链上哈希作为种子喂进脚本，每枚作品都由同一段代码确定性地长出来。这句话里每个词都有具体的工程含义，本文按官方协议文档把三个核心部件讲清楚。

Generator：把数据拼回一幅画

在 Art Blocks 的结构里，一份生成艺术被拆成两块分别存储：渲染脚本（project script）与每枚作品的铸造数据（token data，包括哈希、集合编号、铸造序号等）。渲染时由 Generator 把两者拼回一个页面——脚本从固定的依赖地址加载库，再从链上读取该枚的铸造数据，跑一遍算法，画面在浏览器里当场生成。这个结构意味着页面上没有任何像素是存下来的，存下来的是配方和序号。它的直接后果是确定性成为硬约束：脚本里不允许使用随时间的值、外部请求结果或数学库的非常规函数，否则同一枚作品在不同时间渲染会给出不同结果，官方文档把这些规则逐条列成了允许与禁止清单。

确定性清单为什么这么长

禁止清单看着琐碎，背后只有一个问题：几年之后重放这段代码，画面还一样吗。JavaScript 的 Math.random() 不可复现，被要求换成脚本内实现的伪随机数发生器；Date.now() 让作品随现实时钟变化，直接禁用；调用外部 API 或远程数据会把作品寿命绑在别人的服务器上，同样出局。这份清单其实是一部浓缩的“内容耐久性”教材：凡是让作品依赖链外活体的写法，都被判了死刑。读其他链上生成艺术项目时，把同一张清单拿来当检查表即可——凡画面依赖外部取数的项目，其作品寿命等于那个服务的寿命。

PostParams 与 Transfer Hooks：让作品和规则继续演化

确定性不等于冻结。协议文档里的 PostParams 给项目留了一个链上可配置的参数区，艺术家通过治理流程调整后，已铸造的作品在渲染时可以读取这些新值，作品因此能按规则演化，而每一次演化的依据都是可查的链上状态。另一个部件是 Transfer Hooks：每个项目可以挂一个自定义合约，Engine 核心合约在每次铸造与每次转账时调用它，把版税结算、访问控制、行为记录这类项目定制逻辑放到独立合约里。这两个设计的共同点是分层——标准账本层不动，扩展逻辑各自成块，链上可查。

代价：依赖地址的耐久链条

全链上不是零依赖。官方文档坦承 Engine 作品依赖链上部署的库合约，官方为此维护了把常用库字节码永久固定在地址上的地址簿，以及把渲染页面壳本身也部署到链上的方案。换句话说，一件 Art Blocks 作品的耐久度等于这条链的寿命加上若干依赖合约的寿命，它把“别家的网站倒了”换成了“别家的合约在不在”——风险没有消失，只是从随时可能下架的服务器换成了链上可核验的字节码。这是全链上路线真正兑现的承诺：不是消灭依赖，而是让每一层依赖都变成公开可查、可自建镜像的形态。对收藏者，动作也很明确：作品的脚本地址、依赖库地址、渲染器地址都记进自己的存档，条件允许时跑一份本地渲染副本，作品的生命线就从别人手里接回来一截。本文为机制说明，不构成任何投资建议

三个可核验入口

把协议描述还原成可核验动作，只有三件事要查。第一件，脚本本体：官方把每份 project script 部署成链上合约，地址可以在合约页或集合数据里查到，逐字节比对项目间的脚本是否真的不同，比看“独有算法”的宣传语直接得多。第二件，每枚作品的铸造数据：哈希、集合 id、铸造序号都是合约状态，任何人可读，这也是不同渲染工具应当给出同一画面的原因。第三件，渲染页面的来源：页面壳同样有链上部署路线，遇到渲染器被劫持或域名被换的情况，可以退回“本地加载脚本加链上数据”的方式自证画面没被动过。三件事都能做，说明“作品永久在链上”不只是文案；哪一件做不了，那就是耐久性链条上最先该被问的一环。

本文为机制说明，不构成任何投资建议。