一份证明带到任何地方：CAIP-380 便携证明的 qHash 锚与五分钟时效

不是登录协议的一条规范

编号 380 的便携证明协议（Portable Proof）在 frontmatter 里声明依赖编号 2 与 10 两个标识规范，创作于 2025 年 10 月，写作时状态为 Draft（草案）。原文特意写了一段非目标声明：它不是认证或会话协议，只是定义一个链无关、由钱包签名的证明信封，让应用离线验证一次，之后无论链上链下都用同一个锚点引用它。登录是应用在这个信封之上自己叠加的事。这与 登录消息到底让你签了什么：CAIP-122 的 SIWx 数据模型逐项拆 那种面向登录场景的数据模型是两条清楚的分工线。

规范子集与确定性序列化

信封里参与哈希计算的核心子集恰好五个字段：did（CAIP-10 账户标识）、verifierIds（验证器标识数组）、data（应用负载）、signedTimestamp（签名时刻的 Unix 毫秒时间戳），以及 chainId 与 chain 二选一的链绑定——EVM 档案必须用数字 chainId，非 EVM 用 CAIP-2 字符串。签名之外的一切扩展属性（如 signature、meta）必须放在核心子集之外，验证方算锚点时要忽略它们。序列化走 RFC 8785 的 JSON 规范化路线：键按 Unicode 码点字典序排序、无重复键、数组保序、无空白、UTF-8 编码。

qHash：一个锚点多种引用

把规范化字节喂给 SHAKE-256 取 32 字节输出，加 0x 前缀写成 64 位小写十六进制，就是这份证明的锚点 qHash。同一份核心子集在任何环境算出同一个哈希，这就是「带到任何地方」的数学依据。验证方比对重算的 qHash 与信封携带的值，不一致即拒绝；规范还建议在持久化、建索引或传输时按 qHash 去重。

六行签名消息与绑定规则

EVM 档案下，签名针对的是固定六行文本：固定标签行、Wallet: 加地址、Chain: 加数字链 ID、Verifiers: 加逗号连接的验证器列表、Data: 加规范化 JSON、Timestamp: 加毫秒时间戳。行结束符只许 LF，字符串先做 NFC 归一化。绑定规则把六行与信封锁死：地址行必须等于 did 里地址部分的小写形态，链行等于 chainId，时间戳行等于 signedTimestamp。签名编码要求 0x 前缀小写十六进制。

验签顺序与时效窗口

服务器端的合规动作有明确顺序：先原样重构六行文本，再 EVM 下尝试 EIP-191 恢复，失败转 EIP-1271 合约验证，仍失败只在部署证明有效时接受 EIP-6492；恢复出的地址必须与 did 相符，chainId 与 chain 同时出现或同时缺失都要拒绝。时效是硬规定：签名时刻早于验证时间 5 分钟、或超前 60 秒（时钟容差），验证方必须拒绝，默认值可调但默认必须如此。这份时效观与 ERC-7964 跨链 EIP-712 签名：一份签名怎么只在该用的那条链上有效 讨论的跨链签名域绑定解决的是不同问题：那边管「签名只在该用的链上有效」，这边管「证明别被过期复用」。

为什么锚点选 SHAKE-256

原文对锚点算法的选择没有长篇论证，但效果值得点一句：SHAKE-256 是可变长度输出的散列，这里固定取 32 字节，配合全小写十六进制的写法，锚点形态与 EVM 世界熟悉的哈希书写习惯兼容。更重要的是幂等性——同一信封重复提交得到同一锚点，索引与去重逻辑因此可以放心地把 qHash 当主键。反过来说，锚点不携带任何语义：它不能告诉你 data 里写了什么、签名是谁的，一切要靠信封字段与验签流程补齐，拿锚点直接当「证明编号」对外承诺内容是不可行的。

非 EVM 档案的替换项

同一份规范给 Solana 这类非 EVM 链留了对称的档案：签名改用 Ed25519 覆盖同样的六行文本，签名编码从十六进制换成 base58 的 64 字节；第二行钱包地址换成大小写敏感的 base58 账户，第三行链标识从数字换成 CAIP-2 字符串（例如 solana:mainnet）。信封骨架、锚点算法、时效窗口完全复用——这正是「链无关」的含义：变的是签名档案，不变的是结构与规则。钱包侧的建议是支持 EIP-1271 与 EIP-6492，即合约账户与未部署账户的签名也要能验通，验证顺序与 合约钱包签不动的协议：EIP-1271 兼容性的断层在哪 讨论的合约钱包兼容性断层接得上。

可选凭证与未来方向

规范建议（用词 SHOULD 而非 MUST）为每条目标链提供一个按 EIP-7683 兼容格式构造的凭证，以 qHash 为键，创建应受访问控制且幂等——这是把链下证明搬上链做索引或传输的通道，不约束结算设计。EIP-712 typed data 变体被列在未来工作里，当前版本只定义了 EIP-191 字符串这一种规范签名。用户侧的直觉是：这类签名带五分钟寿命，弹窗出现时看不懂字段就不要签，事后也无法替你做「证明还有效」的背书。本文为协议机制说明，不构成任何投资建议。