EVM 系链用一串数字当链号，比特币系链用创世块哈希，这两条 比特币系链的链身份不是一个数字：CAIP-4 用创世块哈希前 32 位定链 讲过。Cosmos 生态走的是第三条路：链标识直接抄创世文件里那个字符串，抄不动才哈希。CAIP-5 就是这份”抄法说明书”——Blockchain Reference for the Cosmos Namespace，起草于 2019 年 12 月 5 日，现状态 Superseded，内容治理搬到了 ChainAgnostic/namespaces 仓库的 cosmos 目录，规范本体仍然有效可用。
标识来源：创世文件里的 chain_id
CAIP-5 挂靠的父规范是 CAIP-2链标识应该怎么解析？，它定义了两段式链标识 namespace:reference；CAIP-5 负责回答 cosmos 命名空间里 reference 从哪来。答案来自 Tendermint：创世文件里有一个 chain_id 字段，是一段 JSON 兼容的 Unicode 字符串。规范特别立了一条底线：chain_id 为空串必须按错误处理——不是”哈希一下当默认值”，而是直接判非法。对使用者来说，这意味着任何 Cosmos 系链的账本标识都应当能回溯到这个字符串，钱包或节点如果拿不出它，问题在配置而不是格式。
直用与哈希：一条大小写敏感的字符线
能直抄的时候直抄：如果 chain_id 匹配 [-a-zA-Z0-9]{1,32} 这个大小写敏感的字符模式（连字符、字母、数字，最长三十二位），并且不是以 hashed- 开头，就原样作为 reference。条件落在模式之外——太长、含空格、含 emoji、以 hashed- 打头——reference 就改写成”哈希十六进制的前十六个字符”：先把 chain_id 按 UTF-8 编码，做一次 SHA-256，转成小写十六进制，截前 16 位，前面加上 hashed- 前缀。提案测试向量里给了一组可核对的例子：链号 hashed- 算出 cosmos:hashed-c904589232422def，链号 hashed-123 算出 cosmos:hashed-99df5cd68192b33e，单个空格算出 cosmos:hashed-36a9e7f1c95b82ff——这三条按规范公式可复算。注意 hash- 和 hashed 这两个词本身是合法的直用链号，只有带尾随连字符的 hashed- 开头才触发哈希分支。作者的口径也很坦白：写这份规范时没在市场上见过不合字符线的链号，所以哈希分支至今没有真实案例。
验证方法：一个 REST 请求读出链号
要把”眼前这条链到底叫什么”读出来，CAIP-5 给的解析方法是向节点发 REST GET 请求取 /node_info，返回 JSON 里 node_info.network 字段的值就是可作 CAIP-5 标识用的链号。测试向量里的标准长相包括 cosmos:cosmoshub-2、cosmos:cosmoshub-3、币安链时期的 cosmos:Binance-Chain-Tigris，以及 IOV 主网 cosmos:iov-mainnet。对普通用户的含义：钱包里添加一条 Cosmos 系链时，网络表单里那个 Chain ID 一栏就该填这个字符串，填错不会”近似匹配”，只会连不上。
最有信息量的一段：换代等于换链
规范在 Rationale 里记录了一个真实麻烦：Cosmos Hub 的链号换过 cosmoshub-1、cosmoshub-2、cosmoshub-3。每次换号的操作是把当时链状态导出、造一份新创世重启，规范的态度是——技术上这就是不同的链，本规范把它们当不同链处理；至于要不要把前后两段视作”同一资产的历史延续”，那是上层应用的职责，由它们自己定义等价集合。这条口径落到对账场景非常实用：跨换代历史做余额审计时，两套账本、两个链标识，谁也不覆盖谁；钱包导入旧地址的流水，也要接受”历史被链号切成两段”这个事实。
与其他链标识体系怎么拼
一个 cosmos 系链的完整标识体系是三件套：链这一层是 cosmos: 加 reference（CAIP-5 管）；资产这一层，原生币写法见 一条链的原生币怎么写进资产标识？CAIP-20 用 slip44 编号的写法与读法，用 slip44 编号；账户这一层是 CAIP-10账户ID为什么必须带链？ 定义的两段式账户 ID。三层各自独立拼合，谁也不能替谁拍板。日常最容易犯的错，是把 EVM 的十进制链号习惯套过来——往 Cosmos 系链的网络表单里填一串数字——这不是”另一种写法”，字段内容域根本不重叠。
大小写敏感这条线，为什么值得单拎出来
直用模式那条字符线是大小写敏感的：cosmos:CosmosHub-3 与 cosmos:cosmoshub-3 在规范眼里是两个不同的 reference，哪怕现实中大家只认小写写法。这条规矩和哈希分支的”小写十六进制”要求一脉相承——标识一旦允许大小写折叠，跨软件传递就会出现”看着一样、字节不一样”的两套账。落到操作层面，抄链号时以节点接口返回的原文为准，别按输入法习惯统一转小写；配置文件里已生效的链号更动过大小写就当成换链处理，重新核对余额。另一侧的空串规则同样有工程味：空 chain_id 判错而不是给默认值，意味着部署私有链时忘了填链号，会在标识解析这一层最早暴露，而不是让两条私有链悄悄共用同一个号。
风险提示：本文是链标识机制科普，不构成投资建议；链号、节点接口字段以各链现行配置与 namespaces 仓库现文为准，添加网络或核对历史时请以一条已知入账做小额验证。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。