Solidity合约中签名验证的一点实践

背景

在目前NFT概念国内外火爆的背景下，涌现了很多项目，特别是公链以太坊上，社区与新团队更是层出不穷，让人眼花缭乱。

而一个新项目上线的成功与否，往往与其社区支持力度息息相关。现在很多新项目方为了拥有更多的热度，人为的设置了白名单这个玩法和门槛，于是我们可以看到Discord频道里的人们为了肝白，可以绞尽脑汁、废寝忘食。毕竟，拿到了白名单的人，是会被承诺可以提前pre mint，对于热门项目来说，这几乎是个稳赚不赔的投资。

而对于ERC721标准协议的内容来说，并没有白名单这个说法，那么从技术的角度来说，是怎么实现这个功能的呢。实际上，这里还是个逐渐演进的过程。

白名单

最早，在有项目方开始逐渐使用白名单机制的时候，由于白名单一般只给出几百个，所以实现方式还是比较原始的。而因为当时普遍的项目架构都是前端网页调用智能合约就完事了，并没有引入后端进来，所以做法往往是把白名单地址列表由项目方直接写入到合约中，然后用户在发起pre mint请求时，方法里会判断用户地址是否在该地址列表中。

这种方式从原理上当然没有问题，而且也体现了区块链不可篡改、公开透明的特性。不过由于以太坊上高昂的gas费，以及目前白名单人数一般都是数以千计，所以为了自身成本考虑，几乎所有项目都逐渐放弃了这种方式，而是改用另外两种机制：

1. 链下（即后端服务）对单个白名单地址签名，合约只需存储签名地址。
2. 对白名单地址列表整体构建Merkle树，合约只需存储Merkle的root hash。

本文对第一种链下签名