一枚链上的 HTML 铭文，能不能”知道自己是谁”？在中心化的网页里，页面查询自己的编号需要后端告诉它；而在 ord 的铭文体系里，这件事被写成了协议级的约定。Ordinal Theory Handbook 的 Self-Reference 一节规定：铭文 ID 为 INSCRIPTION_ID 的铭文，其内容必须从 URL 路径 /content/<INSCRIPTION_ID> 提供。只要任何索引器遵守这条规则，铭文里的 JavaScript 就能用一行代码读出自己的编号：window.location.pathname.split("/").pop()。
这行看似平淡的语句，是链上生成艺术的一块关键拼图。生成艺术的核心是”用算法加随机种子产出成品”：同一份代码，喂进不同种子，输出不同画面。传统做法要么把每张成品图分别上传，要么依赖外部服务器提供参数；而自引用让铭文本体充当种子源——同一个合约、同一份 HTML，因为每枚铭文的 ID 天然唯一，从自己路径里取到的字符串就天然唯一。把 ID 哈希一下喂进绘图算法，一万个编号就渲染出一万个画面，全程没有一行数据在链外。画面与身份互相锁定：改编号等于换作品，换作品必然换编号，这比”链上哈希指向链下参数表”的架构少了一个可以被悄悄改写的中间层。
规则还处理了一个容易被忽略的细节：委托铭文（delegate）的路径语义。若铭文 X 的字段声明委托到铭文 Y，手册明确要求 X 的内容仍然必须从 /content/X 提供，而不是 /content/Y。也就是说，自引用的”自我”指铭文自己的 ID，而不是内容实际存放处的 ID。对使用者，这保证了两件事：其一，委托只是共享内容存储的记账安排，X 的展示逻辑仍然以 X 的身份运行；其二，凡是页面逻辑依赖”我的编号”的铭文，委托与否都不会让算法拿到别人的种子。
配套的边界也值得写明。HTML 与 SVG 铭文在 ord 浏览器里被装进带 sandbox 属性的 iframe，并以 Content-Security-Policy 头返回，禁止引用链外资源——这正是铭文”不可变”叙事的一部分：页面不能悄悄加载外部脚本，能读的只有自己与同链上其他铭文（通过内容 API 的递归引用）。因此自引用不是”页面联网获取信息”的口子，而是链上身份在浏览器沙箱内的合法透传。核验一枚自引用铭文时，可以比较不同索引器是否在 /content/ 路径下返回同样内容；若某站点的画面与 ord 官方实例不一致，问题多半出在对方的实现没有遵守这条路径与沙箱约定。
把这条机制放到整个生成艺术的谱系里看，它解决的是老问题”种子在哪里、谁能动它”。链下生成的作品，种子通常存在发行方服务器里，观众只能选择相信；参数上链、图片回传的方案，则多出一个”回传流程可以被做手脚”的中间层。自引用方案里，种子就是铭文 ID 本身，而铭文 ID 由共识层保证唯一且不可改写——发行方自己也无法在不换编号的前提下喂进新种子。代价同样清楚：算法写死在 HTML 铭文里，想调配色就得发新版本页面；同一算法的成品审美高度一致，同质化风险由作者自担；依赖浏览器端 JavaScript 的渲染还受展示端沙箱策略影响，遇到不执行脚本的索引器，画面可能只剩占位。核验一枚自引用作品最干脆的办法，是在本地用同一文件开一个新的 ord server，让两个实现各自渲染、逐张比对，一致与否一目了然。
顺带说说委托（delegate）与自引用配合出的省钱结构：多枚铭文把展示内容委托给同一枚”母内容”，母内容里读取的却是各自访问者的 ID 路径——按手册规则，展示 X 时走 /content/X，于是同一份脚本能为每枚委托铭文渲染出不同画面，存储只付一次。这是递归之外另一种”用规则省字节”的正统用法，也解释了为什么有些合集页面看起来各不相同、链上却只存了一份代码。核验时别急着断言”图片没上链就是假的”，先查它是不是委托结构，再看渲染端有没有按路径规则执行。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。