给铭文索引机铺路：ord 需要 txindex、cookie 认证的哪些成本

铭文浏览器背后那台“二次记账”的机器

铭文数据本身躺在比特币区块链里——任何全节点都有原始字节，问题只在于“找得到吗”。ord 项目对自己的官方定义是“索引、区块浏览器与命令行钱包”三合一，并明确标注处于实验阶段。它的工作原理是在比特币节点旁边再跑一台专用记账机：把每个区块里的铭文封套解析出来，按自己的规则给聪编号、登记铭文归属，建出一份可查询的二级索引。换句话说，链没变，多了一本“翻译册”。

前提一：txindex

这台索引机对比特币节点的第一条硬要求来自官方 README：必须有一个同步完成的 bitcoind，并且开启 -txindex。默认节点的默认行为是“按交易 ID 查原始交易做不到”——它只为地址与脚本维护索引。开 txindex 的代价要提前算清：它按交易 ID 为全链每一笔交易建目录，额外占用可观磁盘，开启后首次需要较长时间从头构建（或对已有数据目录做 reindex）；同时它与修剪模式互斥——准备用 -prune 省硬盘的节点没法同时要 txindex，两个功能在源码启动检查里直接互相拒绝。

索引机要通过 RPC 接口读比特币节点的数据。默认配置下，ord 自动读取节点数据目录里的 .cookie 文件完成认证——文件里是随机生成的一次性用户名密码，路径不对时可用 --cookie-file 指定。这里的安全要点恰好相反：不是“要配好密码”，而是“别让 RPC 端口出门”。比特币节点的 RPC 通信本身不加密，cookie 也只是随机口令而不是强认证，RPC 地址应当只监听本机、绝不暴露公网，远程访问靠自己的隧道解决。

成本与角色的三条提醒

第一，磁盘是双份的：ord 在自己的数据目录里再维护一整套索引，节点链数据加索引数据叠加，准备容量时别按单份算。第二，它是个额外信任面：查铭文归属时你信的是 ord 的解析规则与它的索引状态，而不是直接问全节点，重要核对可以换一台干净节点重放验证。第三，角色要分清：README 同时自称索引、浏览器和钱包，但自托管职责应当留在你习惯的钱包与硬件设备里，对命令行钱包保持与任何实验性软件同等的谨慎——“实验阶段”四个字在官方文档里是白纸黑字的风险提示，不是谦辞。本文依据 ord 官方 README 与比特币节点源码参数说明整理，核验于 2026 年 9 月，不构成任何资产建议。

同步顺序与踩坑地图

正确的搭建顺序是：先把比特币节点完整同步，再开 txindex 让索引重建或干脆在首次同步前就打开参数让它随链一起建，最后启动 ord 让它的索引从零追赶。顺序颠倒的常见症状是 ord 长时间看似卡住——它在等节点追平，而节点还在补 txindex。另一类高频坑是环境不一致：官方文档说明，如果 bitcoind 不在主网、不是同一用户运行、用了非默认数据目录或端口，就得给 ord 显式传参，否则它按默认路径找不到 cookie 文件或连错网络。日志里出现连不上 RPC 的报错，第一嫌疑是路径与用户隔离，而不是网络故障。

浏览器的信任面与一条常被忽略的警告

官方 README 里对自带的网页浏览器有一句值得单独摘出的提醒：服务承载的是不可信的 HTML 与 JavaScript，这意味着把它当作普通网站访问时，你面对的是一道真实的网页攻击面——脚本内容取决于索引到的链上数据，而链上数据是可以被任何人写入的。正确姿势是把它与自托管钱包的角色彻底分开：网页用来观察与检索，签名永远回到自己核对过来源的钱包设备里完成；给这台机器配置独立浏览器与最小权限也是合理的隔离手段。再叠加它自称“实验阶段”的定位，整条链路的安全边界可以概括为：可以借用它做检索，不要把私钥放进任何实验性软件，也不要让实验软件替你决定签名内容。