为什么需要白名单
实际上白名单机制是对公售机制的一种补足，由于公售本身的定义，他对于所有用户是平等的，所有用户需要支付同样的费用，拥有平等的机会。之所以说白名单是对公售的一种补足，是因为白名单是在公售基础上，抽出了一部分存量，在公售之前提前发放给一部分人（在白名单中）。
项目方通过抽取出这一部分存量，可以预支一部分价值用于项目的运营和推广。因为大多数项目方可能缺少运营所需的成本，缺少给支持项目的用户反馈的方式。白名单即是为了满足这些需求而在平等上做出的妥协。因此，项目需要白名单机制来弥补运营上的缺失，同时需要白名单机制来完成用户的激励。
白名单方案
白名单机制包含两个核心问题：设置和验证。设置指添加列表元素的过程，简单来说就是将一个钱包地址添加到白名单中，这是项目方的主动操作。验证则是当一个钱包地址到来时，判断其是否存在于白名单中，是否有资格进行白名单mint。两个操作都可以放在链上或者链下完成。
根据设置和验证两个操作所在的位置，可以将白名单方案分为以下几类：
（注：此处的链上与链下指的是操作的完成是通过合约或中心化服务器）
链下设置+链下验证
这种方案只需要在中心化服务器上维护一套白名单列表即可，mint必须由中心化服务器发起，在mint方法中传递验证结果即可。核心难点在于如何链上进行验证结果的合法性校验。
优点：链上不需要存储，减少部署消耗。设置与验证都在中心化服务器上完成，无消耗。
缺点：非常中心化的方案，白名单数据完全脱离公链，用户信任度不足。同时，合法性校验的设计非常关键，容易被攻击。
链上设置+链下验证
这一方案与上述方案存在的问题基本相同，验证如果不是透明的，那么中心化服务器很容易伪造验证结果，用户信任度就会随之降低。同样，因为可伪造，项目也就存在了被攻击的风险。
链下设置+链上验证
这一方案将白名单的设置移动到链下，在智能合约中完成验证工作，将验证过程公开。这种方案实际上是试图寻找存储消耗和安全性之间的平衡。核心问题在于如何在链上存储足够少的数据即可完成验证任务。
为了实现这样的目标，基于Merkle Tree的白名单机制出现了。
要理解为什么Merkle Tree可以应用于白名单的设置和验证，需要先了解Merkle Tree的原理。
-
定义
Merkle tree又称Hash Tree，是一种树形数据结构。每个叶节点均以数据块的哈希作为标签，而除了叶节点以外的节点则以其子节点标签的加密哈希作为标签 。哈希树能够高效、安全地验证大型数据结构的内容，是哈希链的推广形式[1]。哈希树的概念由瑞夫·墨克于 1979 年申请专利，故亦称墨克树（Merkle tree）。(以上摘自维基百科对哈希树的定义)
简单来说，Merkle Tree的每一个根，都是根据他所有的孩子节点通过公式计算得到的，因此同样存在不可篡改性，一旦某个叶子节点更改，就无法通过公式计算出相同的结果。通过这种性质，可以实现两个目标：
- 将最高层的root值存储到链上之后，根据链上数据的公开性结合树本身的不可篡改性从而达到去中心化信任的目标。
- 由于root值是由每一个节点值递归计算得到的，再加上本身是一个n叉树的结构，因此可以实现从一个地址出发，在不知晓其他地址的情况下，计算得到root。通过这一步骤实现将链上验证操作。
使用Merkle Tree实现白名单机制的优点很明显，保证了去中心化信任的同时减少了链上的操作消耗，并且由于链上的验证操作是零知识的，不需要知道其他所有的白名单地址，因此一定程度上保证了项目方保密性的要求。
缺点：这一方案并没有完全脱离中心化服务器的依赖，白名单用户在mint时必须访问中心化服务器得到Merkle Proof才能进行链上验证。
链上设置+链上验证
这一方案最简单，最容易理解，当然也存在一定的代价，就是部署成本很高。
对比上一方案只需要在链上存储root节点值，这一方案需要在链上存储全套的白名单列表，需要智能合约提供方法供项目方设置白名单列表。而设置白名单列表的消耗往往是非常大的。
优点：保证了绝对的安全公开可信，脱离了中心化服务器，达到完全的自运行。
缺点：项目方链上操作数量多，gas消耗大。
总结
总的来看，目前NFT市场中的白名单技术大多使用纯链上/Merkle Tree方案，这两种方案都选择在链上完成验证操作，核心思想是将验证暴露给公众从而换取可信度。
