如何实施EIP-712进行安全签名验证？

EIP-712 概述和核心目的

1. EIP-712 定义了以太坊应用程序中类型化结构化数据哈希和签名的标准。

2. 它使钱包能够在签名请求期间显示人类可读的域和消息字段，而不是原始的十六进制字符串。

3. 该规范通过域分隔符哈希引入域分离，防止跨不同 dApp 或链的签名重放。

4. 每个签名的有效负载都包含一个类型定义，必须在序列化和散列之前显式声明该类型定义。

5. 此结构确保确定性编码，消除可选字段或动态数组排序的歧义。

域分隔符构建

1. 使用keccak256(encodeType(domainType) ||encodeData(domainValue))计算域分隔符。

2. 必填的域字段包括name 、 version 、 chainId 、 verifyingContract和可选的salt 。

3.名称字段必须与 dApp 的注册品牌名称匹配，通常根据 ENS 或合约元数据进行验证。

4. chainId强制链特定的有效性——以太坊主网上生成的签名在 Polygon 或 Arbitrum 上无效，无需重新计算。

5. 即使所有其他输入都正确，不匹配的域分隔符也会导致签名验证失败。

类型化数据编码过程

1. 每个类型声明指定字段名称、类型和嵌套依赖项，例如， Person(address wallet, string name) 。

2. 数组被编码为单个元素的长度前缀串联哈希，而不是指针或引用。

3. 字符串在哈希之前经过UTF-8字节转换；不会自动应用截断或标准化。

4. 地址字段被零填充为 32 字节，并在散列之前在内部被视为bytes20 。

5. 最终摘要将域分隔符、主要类型哈希和编码消息数据组合成用于 ECDSA 签名的单个keccak256输出。

前端集成模式

1. MetaMask 等现代钱包公开了eth_signTypedData_v4 RPC 方法，该方法接受符合 EIP-712 的 JSON-RPC 有效负载。

2. 开发人员必须在调用签名请求之前预先声明 JavaScript 对象中的所有类型 - 运行时动态类型生成会破坏兼容性。

3. @ethersproject/hash等库提供了计算域分隔符和客户端类型化哈希的实用程序。

4. UI 层应完全按照类型架构中的定义呈现每个字段标签和值，任何偏差都会使用户感到困惑并破坏信任。

5. 签名后不得修改签名有效负载；即使空格的变化也会使密码证明失效。

链上验证机制

1. 智能合约使用ecrecover以及从输入参数和域值导出的重构摘要来验证签名。

2. 像 OpenZeppelin 的ECDSA.recover这样的 Solidity 库简化了恢复逻辑，但需要与前端行为匹配的精确摘要重建。

3. 传递给合约的域参数必须与签名期间使用的域参数相同——不匹配会产生不正确的可恢复地址。

4. 消息数据必须在合约内部使用相同的类型定义进行反序列化；偏差会导致哈希不匹配。

5. 经过验证的签名可以控制关​​键操作，包括基于许可的代币转移、治理建议和链下订单结算。

常见问题解答

问：EIP-712 签名可以在具有相同名称和版本的不同域之间重复使用吗？答：不会。即使chainId或verifyingContract中的微小差异也会产生不同的域分隔符，从而导致跨域重用不可能。

问：在域结构中省略盐字段是否安全？答：是的，允许省略，但这样做会降低跨分叉或测试网部署相同合约时的唯一性保证。

问：EIP-712 支持递归类型定义吗？答：不可以。循环或自引用类型违反了确定性编码要求，并且在哈希计算期间会失败。

问：如何处理 EIP-712 类型定义中的可变长度数组？ A：使用类似Person[] people 的语法；编码器自动计算数组长度并在连接之前单独对每个元素进行哈希处理。