铭文封套解剖：OP_FALSE OP_IF 里塞进链上的数据长什么样

一段永远不会跑的脚本

比特币脚本有个冷知识：解释器执行到 OP_IF 时，如果栈顶条件为假，它会跳过分支内容直到 OP_ENDIF——跳过的过程中，分支里的数据推送被解析但不被执行，也不留下任何执行痕迹。Ordinals 协议把这条“死代码”通道用到了极致：铭文的正文图片、网页、JSON，全都躺在这样一段永远不会被执行的脚本里。ord 协议文档称这种结构为封套（envelope）：形如 OP_FALSE OP_IF 开头、OP_ENDIF 收尾，中间是若干数据推送。因为 OP_FALSE 先入栈，OP_IF 条件恒假，整段内容对共识层是纯数据、对脚本层是无操作——它不改变所在脚本的语义，和任何正常锁币脚本都能组合。

从标签到字节：封套字段读法

按 ord 文档的示例展开一个最小封套：OP_IF 之后第一个推送是字符串 ord，用于把铭文与其他使用同类封套的协议区分开；接着的 OP_PUSH 1 表示“下一段是内容类型”，例如文本类或图片类的 MIME 标签；再接着的 OP_PUSH 0 标记正文开始，之后的所有推送依次拼上即为铭文内容本体。这里有个硬约束值得记住：Taproot 规则下单次数据推送不得超过 520 字节，因此大文件必然被切成多段连续推送——链上看到的不是“一块 500 KB 的图”，而是一串 520 字节的碎片序列。内容如何落到 witness：铭文不放在锁币脚本主体，而是放在一笔 Taproot 输出的 script-path 里，花掉这笔输出时揭示出完整脚本，数据随之进入交易见证区。

提交、揭示与铭文 ID

因为 script-path 的承诺在创建输出时只露出哈希，协议天然是两步：第一笔提交交易创建包含封套脚本哈希承诺的 Taproot 输出；第二笔揭示交易花掉它，把完整脚本连数据一起带进 witness，节点历史自此多了一份不可篡改的副本，铭文即宣告存在。铭文 ID 的格式是揭示交易的交易号加一个 i 后缀数字（文档示例形如一串十六进制加 i0）：后缀编号按揭示交易输入中容纳铭文的数量与顺序展开——哪个输入带了几条铭文、编号如何接续，文档给了明确的对照表。编号秩序则按揭示交易进入区块的先后与交易内封套顺序排定，全体铭文由此获得一个从 0 起的全局序列号。

索引器视角与两个常见误会

共识层其实“不认识”铭文：区块校验不会因为一段封套更大或更小而对它做价值判断，数据有效性由协议外的索引器（ord 实现）按同一套规则离线重放整条链得出。这带来两个容易被误读的现象。误会一：“铭文占用了区块链存储空间所以每笔都变贵。”占用与费率市场的关系是概率性的：多占权重多付费用是市场规则而非协议惩罚，空块时段成本压力小，费用账本在拥堵期才显性。误会二：“铭文改动了比特币协议。”没有硬分叉、没有新指令——它是对既有脚本规则的社会性创意使用，共识节点照常执行与验证，这段数据在解释器眼里只是一段被跳过的死区字节。

钱包侧的现实提示

封套数据永远跟着承载它的聪走：花掉带铭文的聪，铭文随交易输出迁移（这是“聪的携带物”心智模型的由来），这也是不识别 Ordinals 规则的钱包在合并选择 UTXO 时可能把铭文当普通零钱顺带转出的根源。理解封套结构本身不能替代钱包兼容性核验——持有铭文前确认你的钱包会报告与管理铭文，是这条技术链上最实际的一层防御。另外提醒一次时间属性：封套数据一旦上链就与比特币账本同寿，任何后来者都会下载并存储它——这既是不容篡改的保证，也是内容创作者需要掂量的永久性：写入什么，就是写进一份全人类不可删除的公共账本。

风险提示：本文为协议机制解读，不构成任何投资或收藏建议；铭文交易涉及链上手续费与市场波动风险，操作前请核验所用钱包的兼容说明。