Skip to main content

Summary

因为EIP191的签名消息太过于的简单，所以当签名数据比较复杂的时候，用户往往只能看到一串十六进制的字符串，而无法核实签名数据是否和预期的相符合，所以有了EIP712。

EIP191的问题:

  1. 没有明确的防重放的规定
  2. message如果是一个结构体则美玉欧相应的编码规范，开发者一般会自己按照自己的方式进行编码，这样就有可能造成一些外部组件导致无法解析编码

EIP712就解决了上面两个问题:

  1. 通过DOMAIN_SEPARATOR设定，来防止重放攻击
  2. 规范对结构体的编码方式

格式

在EIP712中的version specific data中，存放着DOMAIN_SEPARATOR的hash，这是一个结构体，格式如下:

struct EIP712Domain{
    string name, //用户可读的域名，如DAPP的名字
    string version, // 目前签名的域的版本号
    uint256 chainId, // EIP-155中定义的chain ID， 如以太坊主网为1
    address verifyingContract, // 用于验证签名的合约地址
    bytes32 salt // 随机数，这个往往被省略
}

有这个数据，即包括chainID，又包括合约地址，还包括app名字，版本号等数据，不可能被重放攻击了吧。

步骤

  1. 准备前缀
  2. 计算Domain_SEPARATOR的hash
DOMAIN_SEPARATOR_HASH = keccak256(
      abi.encode(
          // encodeType
          keccak256('EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)'),
          // encodeData
          keccak256(bytes(name)),
          keccak256(bytes('1')),
          chainId,
          address(this)
      )
 );
  1. 拼接
0x19 0x01 DOMAIN_SEPARATOR_HASH "abc"。
  1. 对于结构体
     // Mail 是待签名的结构体
    struct Mail {
        address from;
        address to;
        string contents;
    }
    
    //对结构体编码
    messageHash = keccak256(
            abi.encode(
                keccak256("Mail(address from,address to,string contents)"
                mail.from,
                mail.to,
                keccak256(bytes(mail.contents))
            )
        );

可以看到messageHash中，把结构体名称，属性名称都编码进去了，因此钱包等第三方能够知道编码的结构体数据结构。解决了结构体编码的规范

再集合前面DOMAIN_SEPARATOR的例子，最终的EIP712编码就为：

0x19 0x01 DOMAIN_SEPARATOR_HASH messageHash

Refer