Runes 雕名字为什么要带承诺：防抢先确认的 commitment 机制

广播即暴露：一个名字在内存池里裸奔

Runes 的名字是稀缺资源：协议从 840,000 区块（协议激活高度）起每 17,500 个区块解锁一档更短的名字，先短后长，直到一百万出头区块后单字母名开放。同一名规则下，名字由雕字（etching）交易先到先得。这带来一个经典时序漏洞：你把雕字交易发进网络到被打包的间隙里，交易内容对内存池可见，任何人解析出你要刻的名字，把更高费用的竞争交易插进同一个块，名字就成了别人的。这类”前置运行”在链上不是阴谋论，是手续费市场的物理特性。

规范对此有一句直接的规定：如果 etching 携带的不是保留名，雕字交易必须包含对该名字的有效承诺，否则整个 etching 被忽略。

承诺长什么样

按规范定义，承诺是把目标名字编码成 little-endian 整数、省略尾部零字节后的数据推送，放在一个输入见证的 tapscript 里，并且被花费的那个输入输出必须已有至少六次确认。三个要件合起来才有效：编码对（little-endian、去尾零）、位置对（在输入侧见证脚本内）、来源对（所花输出已确认六次以上）。缺任何一条，这笔雕字交易在协议眼中只是”一笔普通付款”，名字不会被登记。

这套设计的巧妙在于承诺本身不泄露意图给广播前的旁观者之外的人——但更重要的是它绑定了”你早在六块之前就开始操作”这一事实：想抢注别人名字的人，无法在自己刚看到的瞬间就构造出一个合法的六确认承诺，时间差被强制拉开。

保留名与反混淆

顺带理清”保留名”：名字编码用修改过的 base-26（A=0、B=1、AA=26 以此类推），从 27 个 A 开始往上的一切名字都是保留名，雕字不带 rune 字段时协议按公式自动分配一个保留名。带 rune 字段的交易必须选一个当时已解锁的名字，并配承诺。两条路各自干净：你要么抢一个人类可读名并接受承诺约束，要么接受一串机器分配的编号名字。索引器展示时两类名字可能长得很像，分辨方式是查雕字交易里有没有 rune 字段与承诺。

用户侧核对清单

把承诺放进更大的坐标系

防抢注不是 Runes 的发明：BRC-20 社区为同类问题设计过 predeploy 哈希承诺，先把名字的哈希锁进链、再在后续交易中揭示原文。两条路线哲学一致——用密码学承诺把”意图声明”与”实际执行”在时间上拉开距离。差异在成本与粒度：Runes 的承诺直接嵌在雕字交易的见证里，不额外雕铭文字节，主要成本是那笔需要六确认的输入资金的时间占用。理解这一层，你对”名字为什么这么雕”的疑问就都有了答案：不是协议繁琐，而是先到先得的资源必须用可验证的时间戳对抗速度差。抢注纠纷在历史上反复发生，链上承诺记录是唯一仲裁依据。

承诺与两步雕名的关系

熟悉 Ordinals 提交加揭示节奏的读者会注意到相似哲学：Runes 的承诺不改变雕字一笔完成的结构，只是给名字意图加了一枚带时间戳的锚。它也不替代解锁时间表——即使承诺合规，在未解锁档位雕长名以外的名字仍会被忽略。两层门槛叠加，一个管时序、一个管稀缺节奏。理解这一层，你对”名字为什么这么雕”的疑问就都有了答案：不是协议繁琐，而是先到先得的资源必须用可验证的时间戳对抗速度差。

打算雕名发行：先把名字解锁时间表与当前高度对齐；用成熟工具构造承诺，确认承诺输入确已六确认；雕字被忽略时优先排查承诺三要件，而不是重发赌运气。正在评估一只 Runes 代币：查它的雕字交易——名字是一次雕成还是换过、有没有失败的 etching 在前（失败的 etching 不占用名字）、它的名字当时是否属于已解锁档位、承诺是否合规。名字被”抢注”的争议在 Runes 历史里发生过多次，链上承诺记录是唯一仲裁依据，任何社群截图与聊天记录都不算数。名字本身不承载权益，雕字里的 premine、terms 与符号才值得逐字段核对。本文为协议机制科普，不构成投资建议。