连接时还有两件事没说出口
一份 JSON 说清「哪条链、哪些方法、哪几个账户」：CAIP-217 授权作用域语法 讲的授权作用域解决的是「哪条链、哪些方法、哪几个账户」，但一次连接里还有两个常被默认拍板的问题：双方说的 RPC 接口是不是同一个版本——同一个方法名在不同节点实现里参数和返回可以悄悄不同；以及请求实际发到哪些节点——内置默认、配置文件里写的，还是对方当场塞过来的。编号 211 的草案把这些含糊地带写成显式协商，写作时状态为 Draft，性质标记为 Informational。
两个有序数组
语法落在授权作用域对象的两个属性上。rpcDocuments 数组的每个成员必须是一个能解引用到稳定文档的有效 URI——那份文档描述这套 RPC 接口的版本与定义；原文建议 URL 做规范化并全小写，减少假性不匹配。rpcEndpoints 数组的每个成员必须是可用于连接的 RPC 端点 URI。两者都是有序数组，顺序不是装饰：它是冲突时裁决优先级的依据。
assumed、implicit、explicit
原文把取值分三层。assumed（假定值）是带外传来的：命名空间有一套公认的权威 RPC 定义与端点集合，钱包预配置好或首次连接时从权威注册表按 CAIP-2链标识应该怎么解析？ 的链标识取回；共识成熟后，这些值可以写进该命名空间对本规范的 profile。implicit（隐式值）是命名空间内人人默认的通用值。explicit（显式值）才是双方在握手时当场写进作用域的。三层从「难验证但省事」到「啰嗦但可审计」排开，草案的态度是：低信任、高欺诈风险的环境里，显式协商是安全和用户体验的双重需要。
冲突与未知值怎么办
安全考量一节点出主要风险：多个 RPC 文档定义同一术语、或不同端点给出不同结果时，行为会产生歧义。解法就是协商语境下的数组顺序定优先级，会话开始前先对齐优先级。遇到从未见过的值时，钱包有三条合规路：测试或以权威源校验那些未知端点；直接丢弃请求；或者反提案一个只列自己已知端点的作用域。原文还提醒，渐进式追加授权放到会话后期更稳妥，初始连接阶段少交信息就少一分去匿名化与指纹识别的暴露面。
和相邻规范的关系
这份规范自己不传输任何请求，只定义「先谈妥什么」的语法，因此它嵌在 网站记忆和钱包实况对不上？CAIP-312 给会话权限装了一个查询接口 那种查询接口和编号 25 的会话交换仪式之上生效。实践中，一个支持能力协商的钱包与一个提供端点声明的应用之间才存在这套对话；任何一侧没实现，行为就退回各家用法，接口差异以双方文档现网版本为准。
一次握手的示范
把语法串起来看：某 EVM 生态的应用在连接请求的作用域里写 rpcDocuments: ["https://rpc.example.org/spec/v1.1"] 与 rpcEndpoints: ["https://rpc-a.example.org", "https://rpc-b.example.org"]。钱包收到后先查自己的假定值表：如果它内置的该链权威定义就是 v1 且端点另有权威清单，它可以选择接受对方的显式值（信任来源）、反提案只含自家端点的作用域、或按原文的安全建议丢弃请求。若该命名空间后来为这份规范写了 profile，假定值与隐式值就能在握手时简写成引用，不必每次全量罗列——这正是原文说「命名空间级 profile 写好后隐式值更容易协商或显式化」的含义。
用户视角能做什么
这套协商对普通用户基本不可见，但它决定你点「连接」之后查询与交易实际流向哪里。能落地的自查有两条：其一，在钱包的已连接站点详情里查看会话授予了哪些链与方法，这至少覆盖了作用域的大半（见 连接和登录合成一次弹窗：CAIP-222 的 wallet_authenticate 把两步并作一步 弹窗里那一步的展开）；其二，出现「需要添加网络」「切换到自定义端点」类提示时，把端点域名当地址一样核验，而不是当按钮一样点掉。本文为协议机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。