签名前先写明给谁验：EIP-7749 与预期验证者绑定的签名方法

钱包弹窗里的签名请求，有的标明给哪个合约用，有的只有裸的一段文字。区别不是界面风格，而是这串签名离开当前网站之后还能不能被别人拿去用。EIP-7749 提案想把绑定验证者这件事变成钱包的标准选项。

这个方法签的到底是什么字节

EIP-7749 定义一个新的钱包接口方法 wallet_signIntendedValidatorData，调用时给三个参数：签名者地址、预期验证者地址、待签数据。钱包实际交给私钥签名的字节，是 ERC-191 规范里版本零号信封的拼装结果：一个 0x19 标记字节，紧跟版本字节 0x00，再接上验证者地址和原始数据。验证方核对签名时按同样的骨架重建这段字节再恢复公钥，签名字节与这个骨架不符，验证即失败。前缀机制的字节布局另有一篇，见 ERC-191签名消息前缀怎么读？。该提案的状态是草案，还要求了 ERC-191 与 EIP-712 两项既有标准。

它想补的是哪块钓鱼面

ERC-191 家族现有三个版本信封，各补一块短板。零号信封把消息钉死在指定验证者身上；一号信封是结构化数据，靠域分隔符让签名跨链跨合约失效；被用得最多的 0x45 信封（personal_sign 那套）只在消息前加长度前缀，既不含用途也不含验证者——这使它成为钓鱼重灾区：攻击者在钓鱼站骗签一串看似无害的文本，拿到后拿到真正想干坏事的那个合约里提交，字节层面完全合法，因为签名从没说过自己给谁用。7749 的动机陈述直指这一点：给零号信封补上标准的调用通道，让应用不必冒险用原始签名方法，也让钱包能在弹窗里把验证者地址明文展示给用户核对。

用户视角的核对动作

如果哪天你的钱包弹窗里出现预期验证者这一行，把它当成这笔签名要交给哪个合约的明确声明来读：核对地址是否与你要交互的合约逐字符一致，就像读交易的目标地址一样认真。读不出地址含义时，去区块浏览器查那个地址的标签与代码状态，或在官方文档比对部署地址，签名工具的用法与边界见 怎么证明地址是你的？消息签名验证工具的使用与边界。没显示这一行的弹窗依然大量存在，说明当前主流通道仍是 0x45 与 712 两类，不能因为 7749 存在就假设你的钱包已经提供这个选项。

边界：绑定验证者不等于防重放

要把功劳和局限分干净。验证者地址进入签名，解决的是签名不能挪给别人用的问题；但这枚签名若不含期限、序号或用途字段，仍可能在同一验证者面前被反复提交——重放防护要 nonce、deadline 这类业务字段来完成，前缀本身不会自动补齐它们。同理，弹窗上显示验证者地址，安全性取决于钱包展示的是不是实际进入签名字节的那个地址，遇到拿不准的请求，拒绝签名的成本永远是零。

三条通道怎么挑：一张判断表

同一句签名的需求放在三条通道上，责任分布不同。0x45 通道最省事，也最模糊：链、合约、用途全都不在字节里，出了纠纷几乎无法自证。712 通道把链、合约、字段结构都编进摘要，弹窗能还原成结构化视图，是目前授权类操作的主力，代价是应用开发成本与钱包解析复杂度。零号通道介于两者之间：只钉住验证者一个锚点，其余字段保持原样，适合那些只需要防挪用的轻场景。作为用户，判断逻辑可以简化成一句话：弹窗上能读出的绑定信息越多，签名被复用出去的空间越小；一项都读不出来的弹窗，就该默认它流向你看不见的地方，再决定签不签。

风险提示：本文是签名机制科普，不构成投资建议。任何签名请求都不容忽视：签名虽不直接转移资产，但可能授权他人转移，请以本人核对为准。