Reveal NFTやホワイトリスト、SBTなどの仕組みを押さえましょう
本日は、Reveal NFTやSBT, ホワイトリスト、SBTなどの仕組みを簡単に説明していきたいと思います。
こちらは、2023年1月25日（水）の21時からPalアカデミーさんで行う勉強会の資料となります。
ご興味のある方は、ぜひそちらもご確認ください。
0. はじめる前に
コントラクトの実装方法は様々なものが考えられますので、今回紹介するのは、その実装方法の例の一つになります。
また、大まかな理解をすることが目的なので、細かい説明は省いております。
1. Reveal NFTについて
まずは、Reveal NFT について、見てみましょう。
特定の時点までは、下のように、画像やNFTの名前が不明であり、
特定の時点から、下のように画像などの内容がわかるものを想定しています。
1)TokenURIについて
そもそも、NFTの画像や名前などはどこで知ることができるのでしょうか？
それが、「TokenURI」 です。
例えば、「Azuki」というプロジェクトの画像などのデータは、こちらに格納されています。
https://etherscan.io/address/0xed5af388653567af2f388e6224dc7c4b3241c544#code
そちらのURLに行くと、このようになっています。
さらに、imageのURLに行くと、このようになりました。
このように、あるトークンIDの画像などのデータは「TokenURI」に格納されていることがわかりました。
2)大まかな構成
では、大まかな構成を見てみましょう。
Reveal前と後のデータをそれぞれ、下のようなURLに格納したとしましょう。
ということは、Reveal前か後によって参照する場所を変えれば良いですね。
3)参考のコードを見てみましょう。
下のように、TokenURIという関数があり、Reveal前後によって、参照するURLを変えています。
https://github.com/HashLips/hashlips_nft_contract/blob/main/contract/SimpleNft.sol
4)Revealボタンはどうやっているの？
では、どうやって、Revealが実行されるのかも見てみましょう。
ここでは、簡単で、Revealボタン（イメージです）を押すだけになっています。
ちなみに、誰でもできたら困るので、コントラクトを作った人しかこのコマンドが実行できないようになっています。
5)まとめ
このように、コントラクトを作った人だけが、Reveal状態に変えることができます。
そして、Revealされれば、自動的に「TokenURI」がReveal後のURLを参照するようになっていました。
2. 進化 NFTについて
では、進化するNFTはどうでしょう？
全く同じではないでしょうか？
第1進化、第２進化などがある場合はどうでしょう？
これも進化ボタンを少し追加したり、URLを一つ増やしたりすることで、簡単に実現することができます。
3. ホワイトリストについて
次は、ホワイトリストについても見ていきましょう。
例えば、「ホワイトリストに登録されている人しかミントができない」 ようなケースを考えてみましょう。
こんなイメージですね。
1) 「〜な時だけ」というのは特別なケース？
今回は 「ホワイトリストに登録されている人だけ」 のような限定がつきましたが、そもそもこれは特別なことでしょうか？
例えば、１度にミントできる枚数を１〜３枚に限定したければ、「ミント数が１〜３枚の時だけ」 というような限定をつけると思います。
このように「〜な時だけ」のような限定は特別なことではなく、コード上では通常、 「Require」 で制限します。
https://github.com/HashLips/solidity_smart_contracts/blob/main/contracts/NFT/NFT_PRESALE.sol
2) ホワイトリストに登録する
では、ホワイトリストにアドレスをどうやって登録すれば良いでしょう？
理屈は「Reveal」ボタンと同じです。
コントラクトを作った人だけが、ホワイトアドレスのリストにアドレスを入れていけばいいですね。
3) ホワイトリストに登録されているアドレスか確認する
では、ホワイトリストができたので、あとはミントしようとしているアドレスがホワイトリストに登録されているかを確認するだけです。
このように、ホワイトリストに登録されているアドレスを全て調べ、合致するかどうかを調べれば良いですね。
4)まとめ
以上で、コントラクトを作った人が、ホワイトリストに登録 を行い、ミントしようとしているアドレスがそれに合致するか を調べることができました。
そして、合致していることを条件として（require）ミントできるようにすれば良いですね。
4. SBT（SoulBound Token）について
最後に、譲渡ができない、SBTについて見ていきましょう。
1) 送付（Transfer）とは
まずは、そもそものNFTの送付（Transfer）を考えてみましょう。
実は、次の３つがあります。
そのため、そもそも、このうち何をできないようにしたいのかを考える必要があります。
2) ミントとバーンはできるようにしたい
ミントができないと、そもそもNFTを作ることができません。
また、バーンについてはできるようにするかどうかは設計者の判断にもよると思います。
ここでは、Aアドレス⇨Bアドレスのような送付のみを防ぐことにしましょう。
3) コードを見てみよう
では、コードを見てみましょう。
Transferが行われる前に、その名の通り、「_beforeTokenTransfer」という処理が行われます。
ここに制限を加えていきます。
制限を加えるのは、「require」でしたね。
そのため「０アドレスから」（ミント）、「０アドレスへ」（バーン）の時だけは実行できるというようにすれば実装できます。
4) OpenSeaなどへのリスト化は可能？（参考です）
実は、OpenSeaなどへのリスト化自体は可能です。（実際に送付の際にエラーとなります。）
理由としては、リスト化に実行されるのは 「setApprovalForAll」 という別の仕組みだからです。
そのため、リスト化を含めてできないようにするには、追加の実装が必要です。（今回は扱いません。）
5) まとめ
送付には３つの種類がありますので、そのうち、何ができないようにしたいかを考えます。
想定ができましたら、「_beforeTokenTransfer」で制限を行えば良いですね。
5. 最後に
いかがだったでしょうか。
意外とシンプルな仕組みだったのではないでしょうか。
最後までありがとうございました。
Discussion