绝大多数协议的写法是：先立规范，再照着写代码。Runes 官方规范页开头反着来，第一段就把姿态摆明：本文件不是 Runes 的规范——对 Runes 而言，参考实现 ord 的代码就是规范，这里的和别处的文字描述都只是一份指南，ord 的代码的行为才是最终的。如果你之前按“读白皮书”的习惯研究 Runes，这句话会改变整个阅读姿势。
更少见的是它承认会出现“代码错了也照旧”的情形。原文的表述是：在 ord 的行为存在错误的地方，文字会如实记录这些错误，除非改变行为造成的破坏太大——那样的话，改文档，不改代码。这句话等于告诉读者：协议已经运行在真实资产上，兼容既有账本的权重高于理论纯洁；文字描述与代码若冲突，以代码为准，哪怕代码本身带着已知的毛刺。
这个声明对三类人意味着三件事。对使用者：一切“我的代币怎么没到账”“数量对不上”的争议，最终裁判是 ord 程序算出的账，而不是任何一篇教程或页面文案。对钱包、浏览器、索引器等集成方：手册 Runes 一章有句被加粗的建议——强烈建议集成方用 ord 本身来判定铭刻、代币与余额，换句话说，把 ord 当作事实来源，自己造轮子的人自担与主流账本分叉的风险。对替代实现者：规范页同样写明，任何替代实现必须实现本页描述的全部内容，任何偏离都会冒与 ord 交互时不可预知行为的风险——你按文字实现、别人按代码实现，两边可能根本对不上。
理解“以代码为准”，最好配合该页的另一半内容：Runestone 的数据模型。规范页用一张字段表描述 Runestone 由哪些部件构成：edicts（指令清单）、etching（刻印参数）、mint（铸取）、pointer（指向）；etching 内含 divisibility（可分性）、premine（预挖）、rune（名称）、spacers（垫字）、symbol（符号）、terms（条款）；terms 里是 amount、cap、height、offset 等开放期参数；Edict 本身是 id、amount、output 三元组，RuneId 写成 BLOCK:TX 的文本形式，例如 1:0，名称采用修正的 26 进制 A 到 Z。这张表描述的是“账本里有什么字段”，而字段边界值、溢出、垫字怎么算这类细节，全部要回到代码看——这也解释了为什么官方不肯让文字冒充规范。
还有一个容易被略过的版本边界，规范页与手册都写了：Runestone 协议在区块高度 840,000 激活，出现在更早区块里的 Runestone 会被直接忽略。判断任何一笔 Runes 交易的归属与有效性时，这是第一道闸。
把这一章翻译成用户可执行的三件事。第一件，查状态认权威：mint 之后对数量有疑虑，用 ord wallet balances 这类走 ord 索引的查询做基准，而不是只看某个数据面板的显示值。第二件，读面板问出处：看到“Runes 余额”“铸造进度”之类的第三方数字，先找它的数据源标注——自建索引、第三方服务商还是 ord 实时查询，出处不同，出错方式不同。第三件，冲突时留证据：如果钱包、面板、区块浏览器三方数字打架，把争议交给运行 ord 的一方复算是最快的收敛路径；对集成方而言，这句“用 ord 来判定状态”从建议升级成验收标准也不为过。顺带一句版本注脚：协议在 840,000 块激活、更早的 Runestone 被忽略，这条规则本身也写在代码里——包括“哪些旧区块里的 Runestone 被历史性地无视”这类考古问题，答案同样以 ord 的判定为准。
多说一句，为什么“没有规范”反而更不能跳过这篇文字：字段表与解码步骤仍是带你在代码里定位的最完整地图，读代码时拿它导航、拿代码验证文档，顺序不能反过来。
普通收藏者怎么用这一章？三句话：查余额与铸造结果以 ord 或运行 ord 的服务为准；读第三方数据面板时记住它可能自有一本账；遇到教程、面板、钱包互相矛盾时，先信代码这一边，再把争议反馈给面板方。Runes 的写法不优雅，但在“账本一致性优先”这件事上，它是把丑话说在了前面。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。