三种签名请求一个入口：ERC-7871 的 wallet_sign 如何统一签名弹窗

签名弹窗为什么不止一种

你在钱包里见过至少两种签名弹窗：一种是网站让你签一句话用来登录，另一种是表格样式的结构化数据，字段整齐排列。接口层面它们本来就是不同方法：前者常经 personal_sign，后者是 eth_signTypedData 一族，更早还有一条历史悠久的原始字节通道。方法分散带来的问题是每家的参数顺序、错误码、弹窗样式各管一段。ERC-7871 提出的 wallet_sign 想把它们并成一个入口，让请求方用统一的 JSON-RPC 结构提出签名要求。这份 ERC 状态为草案（Draft），是否被你的钱包采用取决于具体实现，不要假设它一定存在。

用版本字节区分三种请求

wallet_sign 的关键设计是借用 EIP-191 里已有的一套版本标记。EIP-191 给不同签名场景定义了带前缀的封装格式，ERC-7871 用它的版本字节做请求分支：类型 0x45 对应普通可读消息，也就是登录签名常用的那类 UTF-8 文本；类型 0x01 对应结构化数据，内容会按 EIP-712 的域和类型结构组织；类型 0x00 对应带预期验证者的数据，签出来的东西只有指定验证合约能用，这一分支与之前讨论过的验证者绑定签名思路同源，细节可回看 签名前先写明给谁验：EIP-7749 与预期验证者绑定的签名方法。同一个方法进门，走哪条走廊由这个字节决定——所以入口统一并不抹平差异，三类签名在密码学封装上依然是三种东西。

这里值得重复一次被反复验证过的安全常识：普通消息签名不会自动带上任何交易语义，一句纯文本签出来，本身不能直接动用资产，但它可能被用作登录凭证或某些协议的授权凭据；结构化数据则常见于链下订单、许可授权这类有真实约束力的场景。弹窗长什么样、你该看哪些字段，判断规则与用哪个 RPC 方法无关。

地址参数与能力协商

参数结构里有一个可选的 address 字段，原文的措辞相当严格：一旦请求带上这个地址，钱包必须只用该地址回应签名。这条约束针对的是多账户场景下的错签风险——你有好几个账户时，签名应当出自你连接的那个地址，而不是钱包内部的默认账户。返回值除签名外同样可携带 capabilities 字段，与 ERC-5792 的能力发现机制衔接：网站先问钱包会什么，再按能力提出请求，这类协商清单的核对思路与能力协商专题一致，可参考 应用先问钱包会哪些本事：ERC-7902 能力协商清单怎么核对。

对用户来说，这类统一接口带来的可见变化很小：弹窗还是那些弹窗，区别在开发侧少写一套适配。真正需要留意的反而是边缘情况——如果某个统一入口实现的版本参数与你钱包不匹配，报错形态可能与旧方法不同，遇到时优先核对钱包与浏览器组件版本，而不是直接重复批准请求。

它解决什么、不解决什么

这份标准解决的是碎片化：三套历史方法在参数命名、版本演进上各自为政，新钱包要实现全套、新网站要试探支持情况，都费劲。它不解决的是签名本身的风险分层——签一句话和签一份链下许可的利害差别，不会因为方法合并而消失。旧方法短期内不会被拆掉，personal_sign 与 eth_signTypedData 仍会是主流通道的概率远高于一步到位替换；两套并行期间，同一件事可能换过入口来找你，认网站域名和消息内容比认方法名可靠得多。

还有一个容易忽略的点：wallet_sign 的规范只覆盖 EIP-191 定义的封装体系，未来若出现新的封装版本，原文态度是留给后续 ERC 定义，而不是在这个方法里无限膨胀。接口标准普遍如此，边界写清楚比功能求全更重要。

风险提示

本文只讨论接口标准的机制与现状，不构成投资建议，也不评价任何具体钱包的优劣。签名请求的核对责任永远在使用者：域名、地址、消息正文逐项看清，内容超出预期就拒绝；任何索要助记词、私钥的所谓签名流程都是诈骗话术。