一串字符串指到合约里的一个数：CAIP-373 函数调用引用怎么读

合约地址之外还差一段

CAIP-10账户ID为什么必须带链？ 讲过，一串账户标识要同时说清链和地址才算完整。但很多应用真正想指的是合约「里面」的一份数据：某个地址的余额、某条挂在合约里的帖子、某个注册表的一项配置。光给出合约地址，别人还得猜你要调哪个函数、传哪些参数、查哪个时点。目前每个应用各自发明寻址方案，换一个钱包、换一个链，这条指路信息就失效了。CAIP-373 就是为了把这段「路」标准化。

引用的语法结构

规范给出的格式是：在标准 CAIP-10 账户标识后面依次追加冒号、方法名、函数数据和可选的区块号，即 account_id 加 :call: 再跟一段十六进制的 function_data，末尾可以再加一个 :区块号。方法段目前只有 call 一个取值，专供 EVM 链使用。function_data 是完整的 ABI 编码调用数据：前四个字节是函数选择器（函数签名的 keccak256 哈希前 4 字节），后面按签名规则拼接参数。区块号省略时，默认按最新区块执行这次调用；写上区块号，就是查那个时点的历史数据。值得注意的是，这段规范明确不给 function_data 设长度上限，因为真实调用里多参数、长字符串的编码长度差异极大，这是有意的取舍。

用例子读一遍

规范自带的测试用例很直观。查主网某 ERC-20 的总供应量，整串引用以账户标识开头，函数数据只有 4 字节选择器 0x18160ddd，不带参数。查某个地址的余额时，函数数据是 0x70a08231 开头再拼上补齐到 32 字节的地址；同一串结尾加 :12345678，就变成查第 12345678 块时该地址的余额。开发者侧不需要手工拼十六进制：用 viem 这类库把 ABI 和参数交给 encodeFunctionData，得到的字符串直接填进引用里即可。

拿到引用之后怎么解析

规范要求解析方按固定顺序走：先拆出账户标识、方法、函数数据和可选区块号；再确认链标识存在且可访问；然后确认该链上这个合约地址确实存在；最后在指定区块（或最新块）执行这次调用，按函数的返回类型处理结果。也就是说，一串引用只是一张「取数说明书」，它不携带数据本身，兑现它需要一条可用的节点通路。

和相邻寻址方式的分工

把这串引用放进已有的标识谱系里更好理解。CAIP-2 管「哪条链」，CAIP-10 管「哪个账户或合约」，CAIP-19 管「哪个资产」，而这条规范填的是「合约里的那一份数据」。它与另一种思路——直接指存储槽编号——的差别值得强调：存储槽寻址绑死在某个具体实现的数据布局上，合约升级、变量顺序一变就读错了；函数调用引用绑的是函数签名这个对外契约，只要合约继续支持同一个 view 函数，内部怎么改都能读出同一份逻辑数据。代价是每次兑现都要真的执行一次调用，需要一条节点通路，而读槽位的方案配合存储证明可以做到不信任节点。两种方案一个偏「按契约取数」，一个偏「按布局取证」，选用时先问自己是哪种需求。

普通用户什么时候会碰到

日常最可能撞见这串字符的场合：某个内容或社交协议把一条帖子、一份档案的「全局编号」写成这样的引用，你把链接贴给另一个应用，对方能独立把原内容取回来；治理或审计工具把某个时点的余额快照引用存档，事后可复核。拿到引用时的自查动作和解析顺序一致：先确认链标识是不是你认识的链，再确认合约地址来自项目官方而非转述，最后才看函数数据合不合理。引用格式本身不验证任何一环，格式合法不等于内容可信。

边界与前瞻

这类引用适合指那些没有统一代币标准的数据——存在映射结构里的评论、档案、配置项。它的语义是「执行这次调用得到的返回值」，而不是「链上某块存储槽」，所以同一份逻辑数据换了实现合约，引用就得重写。规范还把 method 字段设计成通用词，设想未来扩展到非 EVM 链，例如 Solana 的 invoke 或 Cosmos 的 query，但写作时这些只是方向性示例，正文以 EVM 的 call 为准。该提案目前是草案（Draft），落款创建于 2025 年 8 月 15 日，引用前先看钱包或工具是否支持。涉及资产数值时，请以链上实际执行结果为准，本文不构成任何投资建议。