ERC6492如何验证未部署钱包签名？ 图 1
ERC6492如何验证未部署钱包签名？ · 图 1

解释预部署合约钱包签名包装、factoryCalldata与magic bytes，给出先检测包装、再部署或模拟、最后按ERC-1271验证的顺序。

反事实签名的关键不是“先部署再说”，而是让验证器在受控环境重现未来钱包地址与验证逻辑。

易错点：反事实签名的关键不是“先部署再说”，而是让验证器在受控环境重现未来钱包地址与验证逻辑。

包装格式

包装数据把factory地址、factoryCalldata与原始签名编码在一起，并用固定magic bytes标识。验证器要先识别这一层；若先按EOA恢复，很容易把未部署地址误判为无效。

一份可复现检查单

核验对象本主题动作失败处理
包装格式从Ethereum Improvement Proposals确认ERC-6492反事实签名怎么验证的正式定义，并保存网络、地址与读取时间定义或版本对不上时，不继续套用本文步骤
验证顺序在原始返回、签名消息或交易指令中定位对应字段，不用界面缩写代替找不到原始值时，把结果标为未验证
部署模拟用ERC-1271复核实现行为，特别记录可选扩展与权限主体实现与规范语义不一致时，按具体部署重新评审
恶意factory边界构造一个失败样例，确认客户端会明确拒绝而不是静默修正失败仍被显示为成功时，停止上线并补充状态校验

记录ERC-6492反事实签名时，把“输入快照”和“判断结果”分开。该主题的快照包含原始bytes、字段单位、对象地址、区块高度与Ethereum Improvement Proposals版本；结果注明通过的规则和仍未知的恶意factory边界。这样即使ERC-6492反事实签名怎么验证随后变化，也能复现当时的结论。

ERC-6492反事实签名的测试至少覆盖正常路径、缺少验证顺序、提交前状态改变及客户端不支持当前版本。前几类验证部署模拟边界，最后一类确认产品不会删除字段或改走未经用户确认的回退路径。

验证顺序

factory调用可能部署合约、修改状态或故意消耗Gas。服务端验证宜使用隔离模拟或可回滚调用，设置Gas和递归上限，并确认部署结果确实位于待验证地址。

可验证事实

  1. ERC-6492包装签名包含factory地址、factoryCalldata和原始签名，并以固定magic bytes结尾供验证器识别。
  2. 验证顺序必须先检测ERC-6492包装，再处理已部署合约的ERC-1271，最后才尝试EOA签名恢复。
  3. 反事实验证可能需要部署钱包或在可回滚环境模拟部署，factory调用本身必须视为不可信外部执行。

部署模拟

钱包已经部署时，验证器也不能盲目重放factoryCalldata。应先处理6492包装，再根据代码存在状态选择ERC-1271路径，最后才是普通ECDSA恢复。

恶意factory边界

登录系统还要把消息域、nonce和过期时间纳入会话。ERC-6492只让“部署前合约钱包签名”可验证，不会自动解决钓鱼消息和跨站重放。

证据从哪里来

  1. Ethereum Improvement Proposals：正式接口、字段与规范语义，https://eips.ethereum.org/EIPS/eip-6492
  2. ERC-1271：实现路径、兼容性或安全边界，https://eips.ethereum.org/EIPS/eip-1271

ERC-6492反事实签名的资料访问口径为2026-07-17；遇到Draft状态、可升级部署或可变网络参数，应在后续复核日重新读取Ethereum Improvement Proposals。

实现差异

规范不保证任意链上验证器都支持反事实签名，钱包与应用必须明确协商验证能力。 相邻知识可继续对照合约钱包验签、智能账户执行路径。