切成 520 字节：铭文数据塞进脚本”不执行分支”的门道

很多人以为铭文是把图片”上传到比特币”，实际上比特币没有上传这回事。铭文是把数据以特定格式嵌进了一笔交易的脚本里，而这段脚本正常情况下根本不会被执行。本文拆开这个嵌法。

信封：一段永远不被执行的脚本

Ordinals 官方文档把铭文内容的存放方式叫做信封（envelope）：用 OP_FALSE OP_IF 开头、OP_ENDIF 结尾，把任意多个数据推送包起来。因为条件永远为假，这段脚本里的内容只被当成数据、从不执行，文档的原话是信封实际上等同于空操作——它不改变所在脚本的任何语义，可以和任何锁定脚本组合。一段写着 Hello, world! 的文本铭文序列化后长这样：OP_FALSE、OP_IF、推入字符串 ord（用来和其他用途的信封区分）、OP_PUSH 1 后面跟内容类型 text/plain;charset=utf-8、OP_PUSH 0 后面跟正文、最后 OP_ENDIF。

为什么会被切成小段：520 字节上限

Taproot 脚本对单个数据推送有一个不大的限制：不能超过 520 字节。所以一张几十 KB 的图片必须切成一串推送依次排开，这就是你在原始交易数据里看到铭文被”剁成很多块”的原因。切分不影响内容：索引器按顺序把所有推送拼回来，仍然得到完整字节流。

信封活在哪里：见证数据与两步流程

铭文信封写在交易的见证数据里，准确说是 tapscript 的支出路径里。这正是 Ordinals 采用 commit 与 reveal 两步的原因：Taproot 的脚本路径支出必须花掉一个已经存在的 Taproot 输出，所以第一步 commit 交易先造一个承诺了这段脚本哈希的输出，第二步 reveal 交易花掉它，把完整的 tapscript 连同信封一次性广播上链。reveal 交易被区块收录的那一刻，数据才算真正刻进比特币历史。Taproot 脚本路径的数据按见证权重计费，同样体积的数据放在这里的计费重量低于放进普通输出，这是铭文相对可行的成本前提。

它能说明什么

这套结构说明两件事。其一，铭文内容是不可删改的历史记录：数据进了区块，就跟着整条链的共识一起保存，没有任何服务器可以把它撤下来。其二，内容的总量直接抬高交易权重，费用随数据量线性上升，“多刻几 KB”在比特币上从来不是免费行为。它也解释了铭文与图片网站的本质区别：你支付的是一次性的区块空间，换来的是不依赖任何托管方的永久副本，代价是一份数据全网每个全节点都保存。

常见误区

一是把”数据在链上”理解成”图片文件单独存放在某个链上字段”，实际上只是交易脚本里的数据推送序列。二是觉得信封”钻了协议空子”——文档明确说，Taproot 见证数据本来就允许在未执行分支里放任意数据推送，这是协议设计内的能力，不是漏洞。三是把 reveal 确认前的中间状态当成刻写完成，commit 之后 reveal 之前，链上还看不到任何内容。

从信封看费用与验证的平衡

理解信封结构后，Ordinals 的费率逻辑变得直观：数据字节数决定交易权重，权重决定基础费用，费率倍数再决定成交速度。同时别忘了验证侧的代价——每个全节点都要存储并校验包含这些信封的区块。铭文的“便宜”是相对普通输出计费而言的结构性折扣，绝对成本仍然由内容体积说话。评估任何刻写方案时，把“要存多少字节、愿意让全网替你存多久”作为第一个问题，几乎所有参数讨论都能落回这两行。 顺带一提，HTML 与 SVG 类铭文在展示端会被强制放进沙箱环境，禁止引用链下资源，正是为了保证递归引用的内容全部来自链上，这一展示层规则与信封机制配合，共同构成了铭文不可篡改叙事的另一半（另文详述）。

风险提示：本文仅介绍 Ordinals 的链上数据结构，不构成任何投资建议。