从钱包签名到应用签名
在批量调用接口里，最常见的路径你已经熟悉：网站把一串操作打包发给钱包，钱包弹窗让你确认，你点确认后由钱包完成签名和提交。这是 EIP-5792 定义的批量调用通道，签名权始终在钱包手里。草案阶段的 ERC-7836 提出了一个方向相反的组合：应用先把调用包交给钱包做“准备”，钱包返回一个待签摘要和一组参数，应用拿着摘要自己去签，签完再把结果送回钱包，由钱包执行。两份新方法分别叫 wallet_prepareCalls 和 wallet_sendPreparedCalls。它是草案，不是任何钱包已经保证的功能，读它时把它当作一种接口设计趋势的样本。
两个方法的往返
按原文的参数结构，wallet_prepareCalls 的请求内容与 wallet_sendCalls 几乎一致：一串 calls、每条含目标地址 to、数据 data 和金额 value，外加链标识 chainId、发起地址 from、版本号和一个可选的密钥提示。钱包收到后，按账户的实现把调用包整理成规范要求的形状，返回一个 digest 摘要，连同 capabilities、chainId、context 和 version 一起回给应用。context 里装的是钱包内部数据，比如按账户抽象标准组装好的用户操作结构。应用对该摘要签名后，把签名和刚才那组参数原样转交 wallet_sendPreparedCalls，钱包核验后执行。整个流程把原来一次弹窗的事拆成了两次网络往返加一次应用侧签名。
签名角色换位的含义
原文对动机的表述很直白：让应用而不是钱包对调用包签名。这带来一个结构性变化——资产动用链路里“谁最后按确认键”不再是钱包界面，而是应用持有的会话密钥。规范为此在请求里放了一个 key 字段，允许三种密钥类型：secp256k1、p256 和 webauthn-p256，并带一个 prehash 开关提示摘要是否由密钥侧预先哈希。p256 与 webauthn-p256 指向的是通行密钥、安全芯片这类认证器场景：应用在你设备上生成的不可导出密钥签这次调用，钱包确认密钥确实被账户授权后放行。对普通用户，直觉判断是：这种模式下设备弹窗可能从“逐条核对操作内容”退化为“确认一次授权关系”，安全重心从弹窗审查移到了密钥授权管理。
钱包端必须做的核验
草案的安全章节把责任几乎全压在钱包一侧。第一条是硬要求：钱包必须验证请求里给出的公钥确实被该账户授权，且请求的能力范围落在这把密钥的权限、额度和有效期内。第二条是哈希一致性：签名方和验证方对 prehash 的理解不一致会导致验证失败，钱包应按密钥类型固定哈希方式，不让应用随意切换。第三条是准备与执行的衔接：钱包应当能重算出同一个摘要，并可以记录一个准备标识或有效期，防止一份旧签名被长期重放。第四条是资源防护：wallet_prepareCalls 可以被限流、限制包大小、尽早拒绝畸形输入，避免恶意请求消耗昂贵的上下文生成。把这些要求翻成用户语言：这套接口安不安全，取决于你用的钱包实现得是否严格，而不是接口本身。
现状边界
这份标准只要求两步方法的名字和参数形状，没有规定哪类账户必须支持，也没有规定钱包必须向用户展示什么。可以合理预期的是，先跟进的会是账户抽象和智能账户生态较深的钱包，传统外部账户钱包未必有动力实现。你在钱包设置或版本说明里看不到这两个方法名，不代表它不安全，只代表它还没接入。同类方向上还有 三种签名请求一个入口：ERC-7871 的 wallet_sign 如何统一签名弹窗，以及把连接和登录合并的接口探索，几条线索共同指向一件事：钱包的角色正从“每笔都过手的会计”变成“按授权书办事的执行方”。
给用户的核对纪律
如果哪天你的钱包开始支持这种模式，有三条纪律值得保留。第一，凡是第一次为某个应用签发“可以代替我执行调用”的密钥授权，把它当作开了一张支票，核对额度、有效期和目标合约范围，和你平时处理代币授权用同一套谨慎。第二，同一授权下如果后续操作不再逐笔弹窗，记住便利的另一面是审计点减少，定期在钱包里查这套会话的授权清单并主动到期。第三，任何声称“只需登录、无需签名”却能把资产转走的实现都不符合这类标准的分工——调用内容必须先在某个环节以某种形式呈现给你。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。