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