思维导图我把以太坊签名分为对消息签名与对交易签名，这两种签名都是基于ECDSA算法与流程，本章就让我们来搞清楚两种签名具体的内容。
我把以太坊签名分为对消息签名与对交易签名，这两种签名都是基于ECDSA算法与流程，本章就让我们来搞清楚两种签名具体的内容。
当我刚开始接触签名这个名词时，我也很困惑，此处的签名和现实世界中合同的签名有什么不同？当我签署一份租房合同，当我们租期到时，如果对屋内的物品所有损坏，房东可凭借这份合同上的内容对我进行索赔（扣押金），如果我进行抵赖，说我没签署过这份合同，那么房东可去司法机构进行签名笔迹认证。以太坊中的签名也是如此，在租房合同中签名是笔迹，在以太坊中的签名就是一段数据，这段数据的作用和我签署租房合同的签名笔迹没有任何不同，节点们（矿工们、验证者们）可以凭借这段数据进行身份认证，即证明这些消息就是我签署的（因为只有我拥有私钥），同时，我想抵赖也是不可能的，因为这段数据具备不可否认性，第三方也不可能对消息进行篡改，因为这段数据具备完整性。如果对上面阐述的内容暂时不理解也没关系，继续往下看，多看一些资料很快就会理解的。此时我们只需记住，以太坊或者计算机中这个"签名"与现实世界中的向"合同上签名"是一个意义。下面先概括一下以太坊的签名与验证过程：
在以太坊、比特币中这个算法是经过二开的ECDSA（原始的ECDSA只有r、s组成，以太坊、比特币的ECDSA由r、s、v组成）。
RLP：一种序列化的方式，其与网络传输中json的序列化/反序列化有一些不同，RLP不仅兼顾网络传输，其编码特性更确保了编码后的一致性，因为每笔交易过程中要进行Keccak256，如果不能保证编码后的一致性，会导致其Hash值不同，那么验证者就无法验证交易是否由同一个人发出。
Keccak256 ：以太坊的Hash算法，生成32个字节Hash值。
构建原始交易对象
签署交易
签署交易可使用MetaMask和ethers库。
前端：使用MetaMask进行签名为前端技术栈，目前比较流行为nextjs+ethers，我对前端不太了解，这里不做展开。
后端：使用ethers库可以进行交易的签名，详情见如下代码：
对(nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0)进行RLP编码；
对上面的RLP编码值进行Keccak256 ；
对上面的Keccak256值进行ECDSA私钥签名（即正向算法）；
对上面的ECDSA私钥签名(v、r、s)结果与交易消息再次进行RPL编码，即RLP(nonce, gasPrice, gasLimit, to, value, data, v, r, s)，可得到如下编码；
细心的同学可能会问，为什么步骤1中包含chainId字段，而步骤4中再次编码时没有chainId字段？原始消息内容都不一样，怎么可能会验证通过？先别急，这是因为chainId 是被编码到签名的 v参数中的，因此我们不会将chainId本身包含在最终的签名交易数据中（下面一小节也有阐述）。当然，我们也不会提供任何发送方地址，因为地址可以通过签名恢复。这就是以太坊网络内部用来验证交易的方式。
对上面最终的RPL解码，可得到(nonce, gasPrice, gasLimit, to, value, data, v, r, s)；
对(nonce, gasPrice, gasLimit, to, value, data)和(v,r,s)ECDSA验证（即反向算法），得到签名者的address，细心的同学可以看到第一个括号少了chainId，这是因为chainId在ECDSA私钥签名（即正向算法） 时被编码到了v，所以由v可以直接解码出chainId(所以在对上面的RLP编码值进行Keccak256；这一步，肯定是把chainId复制了一下，给对上面的Keccak256值进行ECDSA私钥签名（即正向算法）；这一步用)；
对上面得到的签名者的address与签名者公钥推导的address进行比对，相等即完成身份认证、不可否认性、完整性。
我们注意到原始交易对象里由Nonce和ChainID两个字段，这是为了防范双花攻击\重放攻击（双花与重放是相对的，本质都是重复使用一个签名，用自己的签名做对自己有利的重复叫双花，用别人的签名做对自己有利的重复叫重放）：
这里和签名的关系不大，便不再详述，大体可以看看下面这个帖子：
大家看完上面的签名交易后，再看本章的签名消息，可能会有有些懵的感觉，会将其混为一谈，误以为这两个东西是平行的，各自发给节点的。这是对以太坊交易流程不清晰导致的，只需记住一点，发给节点的只能是交易签名+相应参数，其大概可分为三种情况：
综上，无论是部署合约交易还是调用合约函数交易都是改变data的值。 我们本章所讲的消息签名就是调用合约函数交易，调用对应合约函数（一般为验证verfiy函数），消息签名作为参数。
我们不用把他们想的太复杂，简单点来说通用签名方法就是添加了"\x19Ethereum Signed Message:\n"这个字符串的签名，如metamask的personal_sign方法和ECDSA库的toEthSignedMessageHash方法，添加这个字符串只是单纯的为了表明这是以太坊的签名，让我们看看通用签名方法的例子--NFT白名单。
让我们来写一个NFT白名单合约，想想如何实现白名单这个功能？
error SignatureNFT__VerifyFailed();
contract SignatureNFT is ERC721 {// signer addressaddress public immutable i_signer;
通用签名方法实现逻辑为：
这里我再加一个：
在学习EIP-712时，不妨让我们先看一下其具体实现。以代码下是UniswapV2ERC20合约的实现，在20行bytes32 digest由三部分组成：
而EIP-712就是由以上三部分组成。
$encode(domainSeparator,message)=x19x01 ∣∣ domainSeparator ∣∣ hashStruct(message)$
对比我们上述"通用消息签名方法"中只是对要签名的参数进行序列化、keccak256、添加"\x19Ethereum Signed Message:\n32"后再次序列化与keccak256、签名相比，EIP-712是有着结构化上的要求的，我这里针对其结构式进行一个思维导图上的解析，大家如果想看文字上的描述，可以研读如下资料：
domainSeparator由两部分组成，第一部分为对结构体的keccak256（encodeType），第二部分为结构体的具体实现（encodeData）；
domainSeparator结构体如下所示，一般来说salt（随机数）会省略；
再让我们对照UniswapV2ERC20来记几个结论：
一般来讲，hashStruct(message)与domainSeparator格式相同，也是由由两部分组成，第一部分为对自定义结构体的keccak256（encodeType），第二部分为自定义结构体的具体实现（encodeData）；
由注释可知，PERMIT_TYPEHASH就是Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)的hash，注意自定义对象名要首字母大写；
encodeData与encodeType顺序要相同；
用uniswapV2结构体进行举例，注意我们要先确定verifyingContract，即pair的地址。