Mecanismo para Whitelist de Smart Contract

Esse artigo é uma tradução de Albert Lin feita por Amanda Krishna. Você pode encontrar o artigo original aqui.

Introdução
A Whitelist é uma ótima maneira de promover um projeto de NFTs e recompensar a entrada antecipada/participantes entusiasmados. Existem várias maneiras de implementar o mecanismo de whitelist e cada método vem com suas próprias vantagens e desvantagens. No momento, existem principalmente 3 maneiras de implementar o mecanismo de whitelist e agora vou apresentá-los e falar sobre seus prós e contras.
 
Maneira mais primitiva — Armazenar em memória
Para desenvolvedores que estão familiarizados com outras linguagens e sistemas de computação modernos, armazenar dados em heap ou memória parece ser uma maneira bastante razoável e fácil de lidar com uma série de dados.
 
Portanto, para armazenar a whitelist na memória, você pode simplesmente declarar um mapeamento para registrar todos os endereços válidos qualificados para o whitelist mint. No entanto, usar essa maneira causará MUITO GAS e é um método realmente ineficiente. No entanto, será mais fácil para qualquer pessoa testar se está na whitelist por meio do etherscan ou de algumas linhas de código.
 

Prós: Fácil de Validar, Fácil de Codificar, Fácil de adicionar um endereço ou remover um endereço
 
Contras: Realmente ineficiente, Muito caro para o editor
  

A maneira inteligente I — Airdrop da Árvore de Merkle
A outra maneira de realizar uma whitelist será usando a árvore de merkle. A árvore de merkle é um item importante na blockchain. A árvore de merkle aproveita a propriedade de hashing de que uma pequena mudança na entrada resultará em saídas completamente diferentes, e o fato de que a probabilidade de duas entradas resultarem na mesma saída é quase impossível.
 
A estrutura da árvore de merkle é mostrada abaixo. O hash do nó atual é igual ao hashing de seu subnó esquerdo, subnó direito e seus dados. Assim, a partir da propriedade do hashing, qualquer alteração resultará em uma saída completamente diferente; podemos usar essa propriedade para implementar a whitelist.
 

Então, vamos imaginar que você quer saber se L1 é igual a um endereço, você pode extrair o Hash 0–1, o Hash 1 e o endereço que está disponível a ser testado. Em seguida, você segue a regra de hashing e compara a saída do hashing com o Top Hash. Se o resultado for o mesmo, você pode garantir que L1 é igual ao endereço de entrada.
 
No entanto, para fazer isso, você precisará gerar uma árvore de merkle e levar metade do processo de cunhagem off-chain para economizar gas. Usaremos javascript para gerar a árvore de merkle. Se você estiver mais familiarizado com ether.js, você também pode usar ethers.utils.solidityKeccak256 para fazer o hash do par também. Além disso, lembre-se de armazenar o arquivo JSON conforme abaixo:  {“<address>”: <amount>, “<address>”: <amount>}. Você também pode alterar o par para outro tipo para ajustar à sua necessidade.

Você precisará armazenar a raiz no contrato por meio de uma função solidity. E então uma verificação on-chain com a biblioteca MerkleProof. Assim, sempre que alguém quiser cunhar, você tem que gerar uma prova para o usuário, seja no frontend ou no backend, com a função tree.getHexProof para gerar a prova bytes32[]. Você pode ver o comentário na função checkTree para uma implementação mais detalhada.
 

No entanto, isso significa que você precisa atualizar o freeClaimMerkleRoot sempre que desejar ajustar a whitelist.
 
Prós: Economicamente eficiente, fácil de validar
 
Contras: Ligeiramente mais gas para o usuário cunhar, Necessidade de redefinir a raiz toda vez que você desejar alterar a whitelist
  

A maneira inteligente II — Assinatura de backend
A última maneira também é mais barata que a primeira. No entanto, a última maneira é um pouco mais centralizada do que a anterior. Portanto, esse método aproveita o mecanismo de assinatura de uma mensagem. Você precisa configurar um endereço no backend e mantê-lo credenciado. E então, sempre que um usuário na whitelist desejar cunhar, você precisa primeiro verificá-lo e o backend. Depois de verificá-lo, você pode assinar a mensagem e devolvê-la ao usuário. E então, o usuário pode usar a mensagem assinada e a cunhar.
 
Mas você pode perguntar, como garantir que ninguém possa falsificar a mensagem de assinatura? O motivo é que, se você assinar uma mensagem com sua chave privada, você receberá uma mensagem com hash. Então, você pode gerar uma chave pública com a mensagem hash e a mensagem antes do hash. Assim, se você armazenar a chave pública no contrato e assinar a mensagem com a chave privada no backend, você poderá garantir que ninguém pode falsificar a mensagem.
 
No entanto, para evitar ataques de repetição, você pode usar um nonce para garantir que a mensagem assinada não será usada de forma maliciosa. Assim, todo o processo de assinatura será como abaixo:
 

Assim, após gerar a mensagem de hashing, ou seja, hash e assinatura nos dados de retorno, você pode passá-la para o frontend para o usuário cunhar o NFT. Assim, você deve configurar a verificação on-chain.
 

Prós: Mais barato para os desenvolvedores, mais fácil de gerenciar a whitelist no backend
 
Contras: Mais gas necessário para cunhar, menos descentralizado
  
Conclusão
Existem muitas maneiras de implementar um mecanismo de whitelist. Cada maneira é acompanhada por seus prós e contras. Assim, os desenvolvedores devem pensar cuidadosamente sobre as necessidades e encontrar um equilíbrio entre cada maneira. Além disso, continuarei a acompanhar este artigo e escreverei uma inspeção profunda sobre o gas dos três métodos. Fique de olho no meu Twitter medium.
 
Por último, mas não menos importante, estou atualmente executando um projeto de NFT que deseja dar ao nosso titular uma renda passiva, NFT variável, a conexão entre o projeto e o leilão de NFT. Participe do nosso discord, siga nosso Twitter e dê uma olhada no nosso site!
 

Discord: https://discord.gg/uQz3gqtj 
Twitter: https://twitter.com/hugiRIS_nft 
HugiRIS: https://hugiris.com/