签名之外的两件事
绝大多数用户只让钱包做一类密码学工作：签名。但一个密钥对天然还能干另外两件事——加密给它的消息需要有人解密，验证”这确实是你”的声明有时需要出示一份带时间权限的凭证。EIP-2844 在 2020 年 8 月 1 日提交的正是这两块：给 JSON-RPC 增加 did_authenticate、did_createJWS、did_decryptJWE 三个方法，前缀 did_，让钱包支持去中心化标识（DID）和 IETF 的 JOSE 家族格式（JWS 签名、JWE 加密）。作者 Joel Thorstensson 的理由很直接：应用只要知道某人的 DID，就能解析出他的 DID 文档，从中拿到用于加密和验签的公钥——“爱丽丝只凭鲍勃的 DID 就能发现鲍勃的公钥”。状态至今 Stagnant（停滞）。
三个方法各管一段
did_authenticate 是一次授权握手：应用给出随机 nonce、目标受众 aud 和一组 paths，钱包提示用户同意后，返回一份用 JWS 通用序列化格式签名的凭证，内含用户选择的 DID、被授权的路径列表、有效期 exp、可选受众，签名头里带 kid 指向具体密钥片段。有了这份凭证，did_createJWS 可以让钱包替你签一份声明——明文里若出现此前已授权过的 path，就不再弹窗；did_decryptJWE 负责解密，规范同样写明”已授权路径的解密应当无需用户确认”。这套权限系统的设计目标，是把重复的密码学操作收敛到一次带范围的同意。提案不绑定任何具体 DID 方法与 JOSE 算法，实现自由。
它想替换的旧状态
在 EIP-2844 之前，钱包加密主要靠 2016 年前后的老办法：用 x25519-xsalsa20-poly1305 的非标准编码打包密文。提案在 Motivation 里点出两个硬伤：一是绕开了 IETF 已有的 JOSE 标准，各做各的；二是光有一个以太坊地址，对方没法反查你的 x25519 加密公钥——你签名的密钥和解密的密钥不是一对一自动对应的，中间缺一条发现通道。DID 文档恰好就是为”按标识发布多把公钥”设计的，所以三件套里第一个方法才叫 authenticate：先把标识和授权谈定，JWS 与 JWE 才有落点。
为什么停在 Stagnant
提案列出的实现只有少数身份库——基于 3ID 的 IdentityWallet 和 Ceramic 生态的 did:key 提供者，说明落地范围停留在特定身份栈。更大的背景是：此后数年 DID 生态整体推进缓慢，钱包产品也没有把”收件箱式加密消息”做成主流功能，通用钱包缺少实现动力；而隐私与身份的方向在 2022 年前后转向了账户绑定标识与零知识凭证等其他形态。提案本身质量不低，是需求侧没有跟上——这在接口类 EIP 里是常见死法。
用户今天会遇到什么
对普通用户，识别这套机制的现状有个实用切面：如果你的钱包或 dApp 提到”请钱包解密一条消息""用你的 DID 登录”，先意识到这不是 personal_sign 那种零风险的展示性签名——解密与授权凭证意味着你的标识、路径权限被写入一份可转手的凭证。核对三件事：请求方域名是否就是你操作的那一站（授权有受众绑定，跨域即异常）；有效期 exp 是否短得合理；已授权路径清单是否最小化，宁缺毋滥。任何加密、解密、身份声明类的同意窗口，都不该被”跳过详情”的快捷按钮代签。
与普通签名的边界课
把 personal_sign、EIP-712 结构化签名（参见 签名前先写明给谁验：EIP-7749 与预期验证者绑定的签名方法 讲的预期验证者绑定思路）和这套 did_* 放在一起看，钱包签名类请求的信任梯度其实很清楚：展示型签名不花 Gas、不上链，风险在”内容含授权语义却看不出来”；结构化签名把类型和验证者锁进摘要；而 DID 方法引入的是带有效期的可复用授权，一次点头可能被多次使用。梯度越往后，弹窗之外的台账管理越重要。可以把这套机制当作一面镜子：它预言了今天钱包必须回答的一类问题——弹窗之外的授权台账存在哪里、由谁展示、如何撤销。今天各钱包陆续上线的”已连接的网站""签名历史”页面，做的就是这类台账。养成定期翻一遍这些清单的习惯，撤掉不再使用的连接与授权，其价值不亚于一次权限审计。目前主流钱包对 did_* 方法本身的支持寥寥，遇到声称支持的产品，更该问它凭证存在哪里、清单在哪里可撤销。任何涉及身份与数据的请求都不构成交易，但都不该盲签。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。