登录要记住的两件事太多
传统 web3 登录要求用户同时记住「我用哪个钱包」和「我的地址是什么」。钱包、签名器、链越来越多之后，这道记忆题只会更难。CAIP-275 的思路是把记忆外包给域名：人只需要记住自己的域名名字，剩下的查找交给一段标准化的记录解析流程。规范面向的对象是「加密域名」——通常以 NFT 形式登记在链上的域名，名字背后关联着一个地址。
查找链的第一环：文本记录
规范给兼容的域名 NFT 定了一个硬性要求：必须有一条 key 为 authenticator 的文本记录，值是一个 URL，其中用 {} 占位符代表用户的完整域名。应用取到记录后，把占位符替换成实际域名拼出最终地址，再发一个 HTTP GET 去取配置。以 ENS 域名为例，实现路径是按 ENSIP-5 规范写入文本记录，应用用 text(node, key) 这类 getter 接口查询，node 是域名哈希、key 就是字符串 authenticator。这条记录本身只回答一个问题：登录配置在哪家服务器上取。
查找链的第二环：登录流程清单
GET 回来的 JSON 必须符合规范给出的 Draft 7 结构：必填字段是 address（用户想用的钱包地址，任意链、外部账户或智能账户皆可）与 authFlows 数组；chain 字段按 CAIP-2 写法，只在智能账户需要指明链时提供。authFlows 的每一项描述一条可行通道：platform 区分浏览器或移动端等场景；connection 指明连接方式，取值如扩展 extension、WalletConnect 的 wc、移动钱包协议 mwp；URI 可以是一串带域名占位符的 URL、通用链接、按 网页怎么在一堆钱包扩展里找对的那个：EIP-6963 与多钱包共存 规范的钱包 rdns，或直接写 injected 表示用页面注入的钱包。数组顺序即尝试顺序。
应用的执行规则
规范给应用定的动作也不含糊：先剔除当前环境不支持的流程——平台对不上、所需钱包没装的都算不支持——再按序逐条尝试，遇到需要用户动作的环节（扫码、在钱包里点确认）就停下等待用户完成或取消，直到某条流程成功。对用户来说，这一段的体感是：输入域名后，登录弹窗一层层自动降级尝试，而不是把一堆连接方式摆在面前让人挑。顺序因此变得有意义：配置里排在前面的通道会被优先执行，域名持有者调整数组顺序，等于调整了别人登录你账户时先撞见哪种连接方式。
和其他登录方式的拼图关系
这条协议不自己发明登录凭证，它只负责「找到钱包、建立连接」这一段。连接建立之后真正证明「这个地址归我」的动作，仍然由签一条登录消息完成——那是另一套数据模型的工作，本文不重复展开。把流程拆成两段来看就不容易混淆：CAIP-275 管前半段（从域名到钱包通道），签名协议管后半段（从通道到身份证明）。这也是它和纯钱包发现类提案的差异：发现类协议解决「页面上有哪些钱包可选」，这条解决「这个人的钱包惯常用哪几条通道」，问题方向一个横向、一个纵向。对开发者，两者常常叠着用：先按域名配置缩小候选通道，再落回通用的钱包发现与配对流程。
域名一侧的操作顺序
假设你要给自己的域名开这种登录方式，合理动作序列是：第一步，在域名管理系统里确认该域名支持自定义文本记录，ENS 走 ENSIP-5 风格的记录写入，其他名字系统按各自接口；第二步，选定一家你信任的登录流程托管服务，取回它带 {} 占位的配置 URL；第三步，把 URL 写入 key 为 authenticator 的文本记录，等解析生效；第四步，在托管服务里把 authFlows 至少配一条你真实在用的通道——比如浏览器扩展一条、手机通用链接一条，并把顺序排成你的主力优先。每一步都可以回读核验：记录值用查询接口重取一遍，配置 JSON 用浏览器直接 GET 看结构是否合法。该提案为草案（Draft），2024 年 4 月起草、6 月更新，实际支持以各登录组件与域名系统现文为准。本文仅作机制说明，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。