ERC-7871 wallet_sign：应用请求 EIP-191 签名的一门新普通话

钱包给用户弹过的签名请求大致三类：eth_sign（古老的裸哈希签名，几乎被废弃）、personal_sign（带 EIP-191 前缀的纯文本消息，登录常用）、eth_signTypedData（EIP-712 结构化数据，permit 与下单常用）。三类各有 JSON-RPC 方法，参数位置和历史包袱各不相同，EIP-191 规范里除个人消息外的其他签名数据版本更是长期没有标准请求通道。ERC-7871 提议新增一个方法 wallet_sign，把”按 EIP-191 各种版本签一段数据”统一成一个入口，并通过能力声明让应用事前探明钱包支持哪些版本。按照以太坊 ercs 仓库的记录，这份提案状态为 Draft（草稿），创建于 2024 年 1 月 29 日。

一个方法管住 EIP-191 全家

EIP-191 定义的签名数据（signed_data）以版本字节分家：0x45 是 personal_sign 的人读消息，0x01 是 EIP-712 结构化数据，规范还预留了其他版本。ERC-7871 的 wallet_sign 允许应用请求任意版本的签名，未来 EIP-191 若扩充新版本，方法本身无须再造轮子。与能力发现配套的是 EIP-5792 的 capabilities 字段：标准明确该方法的请求可携带 EIP-5792 风格的 capabilities，钱包是否支持某个签名版本，可通过 EIP-5792 定义的 wallet_getCapabilities 事先查询。这套组合把过去”先调一把试试、失败了换个方法再试”的探测式对接，变成”先问菜单、再点菜”的显式协商，也为多签钱包、智能账户与硬件签名器在同一套语义下各自声明能力留了位置。

与三个老方法怎么共存

提案并不废除 personal_sign 与 eth_signTypedData，而是给 EIP-191 系签名补一个语义更完整的正门。对应用开发者，迁移顺序大致是：能用结构化签名就用 712 系（字段可读、可验证，签名弹窗能逐项展示），纯文本登录继续 personal_sign，遇到这两个通道覆盖不到的 EIP-191 版本需求再走 wallet_sign。eth_sign 则是另一码事——它对裸哈希签名，签名内容不可读、可被构造成交易授权的形态，安全上应当直接回避，无论新标准是否出现。

签名弹窗里该盯住什么

标准层面新增一个方法，不会自动让每次签名更安全，用户侧的判断清单不变：第一，弹窗宣称签的是哪种数据——人读消息、结构化字段，还是一团十六进制；后者（尤其被标注为 eth_sign 或无版本说明的原始哈希）应默认拒绝。第二，结构化签名要看域名与版本号字段，确认这份授权绑定的合约和自己以为的是同一个。第三，“登录”类签名的本质是证明地址控制权而非授权某笔操作，钱包支持的方法越多、入口越统一，攻击面反而更集中，钓鱼站点也最热衷在登录场景偷换签名内容——名字带 sign 的弹窗不一定无害，与会划转资产的授权签名同等对待才稳妥。

为什么需要”方法”层面的标准化

签名请求的碎片化有真实成本：同一应用在不同钱包里要靠试错猜支持范围，钱包之间对废弃方法 eth_sign 的处置也各行其是——有的直接封死，有的保留兼容。ERC-7871 与近两年一批接口提案共享同一个思路：把”能力发现”做成链下 JSON-RPC 的显式问答，让钱包从一个被动签名盒子变成能报菜单的服务端。这类提案的共同哲学，是把过去靠约定俗成维系的应用与钱包关系改写成可协商的协议关系——谁支持什么先问清楚，再决定签不签。

现状

按 ercs 仓库口径，ERC-7871 停留在 Draft，主流钱包尚未普遍实现 wallet_sign，当前生态对接仍以 personal_sign 与 eth_signTypedData 为主。它值得关注的价值在方向上：把 EIP-191 与 EIP-5792 拼成一张显式的能力菜单，为多签钱包、智能账户与硬件签名器提供同一套请求语义，让”你能替我签什么”从模糊默契变成可读清单。对普通用户，短期内它改变的是钱包设置页里可能多出一行签名类型授权管理，不变的仍然是那条老规矩——签什么，比用什么方法签更重要。本文为机制说明，不构成任何投资建议。