地址后面挂一个下划线：CAIP-363 的链标识通配符怎么读

一句话缺少标准写法

CAIP-2链标识应该怎么解析？ 和 一串字符装下「哪条链的哪个地址」：CAIP-50 多链同址编码怎么读 分别讲了链标识怎么解析、多链同址怎么编码，两篇合起来仍留着一个缺口：钱包或身份系统想声明「这个地址适用于某命名空间下的所有链」时，规范里没有中立写法。有人用枚举全部链 ID 的办法，链一上新就得改名单；有人干脆写个约定俗成的 all 字段，换家软件又不认。CAIP-363 针对的正是这句一直说不标准的话。

通配符的语法

规范的做法很克制：在 CAIP-2 的链标识语法里保留单个下划线 _ 作为「该命名空间全部链」的取值，于是链标识变成「命名空间:（链引用或下划线）」；再把它嵌进 CAIP-10 账户标识，得到 eip155:_:0x59f3… 这样的写法，表示同一个地址在 eip155 命名空间的所有链上。规范还举了 Solana 的例子：solana:_: 加地址，指该账户在主网、测试网、开发网等所有 Solana 链实例上的形态。为了防止以后打架，规范用强制语气规定 _ 不得被任何未来的 CAIP-2 profile 指派为合法的链引用。

它刻意不承诺什么

这条规范最容易被误读的地方在于它「没说的话」。原文写得明白：使用下划线不预设地址怎么派生，也不假设地址在所有链上都有效——它只表达「意在指同一地址」这一层意图。同一助记词派生的 EVM 地址确实在各链同址，但通配符本身不替你担保这一点；某条链上这个地址可能从未启用，甚至该链的账户模型根本不兼容。把 eip155:_: 读成「每条 EVM 链上都有余额」是把意图声明当成了事实清单。

不支持的软件会怎样

规范的兼容性策略是「宁拒勿猜」：尚未支持下划线的现有实现应当把这串标识判为无效并拒绝，而不是自作主张展开。这样做的代价是老工具看到通配符会直接报错，好处是不会出现某个软件悄悄按自己的名单展开链、和另一个软件的展开结果不一致的隐性分歧。支持的实现则需要在匹配逻辑里把 _ 视为命中该命名空间内任意链引用。这条「宁拒勿猜」的纪律和多数链上标识演进一脉相承：解析器面对不认识的写法时，报错永远比猜测更安全——猜错的链引用意味着把资产指向错误的网络，那是一类不可逆的错误，而一句解析失败的提示最多造成不便。

解析器视角的一条规则

对写解析逻辑的人来说，这条提案实现起来只有三处要动：词法上允许链引用段出现单独的下划线；匹配逻辑里把 _ 编译成「该命名空间内任意合法链引用」的集合运算；输出侧想清楚展开策略——是原样保留通配符交给下游，还是当场展开成链名单再处理。前两步没有歧义，第三步才是真正的产品决定：展开看似方便，实际会把「名单更新」的重担转嫁给每一次解析，所以规范的写法（原样携带意图）反而更稳。测试用例也简单：eip155:_:0x… 应当匹配 eip155 命名空间下任意数字链引用的匹配请求；反过来，一个带具体链引用的账户标识不应被通配符标识「授权」到其他链上——通配符表达的是声明方的覆盖意图，不是通配符持有者的跨链通行能力。

什么时候用得上

对普通用户，最可能遇见这条写法的地方是多链身份、跨链配置声明和钱包的默认作用域设置：例如「本授权对所有 EVM 链生效」这类文案背后，理想的数据形态就是一串带下划线的账户标识。遇到它时值得多问一句：声明覆盖所有链，不等于每条链上的账户状态都一样，转账、授权仍然要逐链确认余额与 nonce。该提案为草案（Draft），创建于 2025 年 7 月 1 日，实际写入产品前请确认所依赖的钱包与解析库已支持。本文仅作机制说明，不构成投资建议。