第７回 solidity学習会 講義ノート（4/16 AM8:00~） ERC 721Aを学ぼう！
こんにちは、CryptoGamesの高橋です。
クリスペの会社です。
また、CryptoMaidsのアンバサダーも務めさせていただいております。
今回は、4/16 AM8:00から次の場所で勉強会を行いますので、その講義ノートの公開です。
場所 meet.google.com/cas-bnjw-rpg
予習や復習などに役立てていただければ幸いです。
では、やっていきましょう。
０ はじめに
本日は、Azukiで採用されたERC721Aについて見ていきたいと思います。
なお、今回は、Azukiで用いられたバージョンのERC721Aを見ていきたいと思います。
Azukiコントラクト
https://etherscan.io/address/0xed5af388653567af2f388e6224dc7c4b3241c544#code
では、早速見ていきましょう。
１ ownershipOf関数とは
１ー１ 概要
tokenIdを渡すとTokenOwnershipという情報が返ってきます。
所有者の情報が返ってくるのですね。
では、TokenOwnershipとはなんでしょう？
１ー２ TokenOwnershipとは（構造体）
こちらは構造体になります。
アドレスとタイムスタンプが入っているようです。
つまり、tokenIdを渡すと、①アドレス②タイムスタンプの情報が入った、「TokenOwnership」を返してくれます。
ちなみに、タイムスタンプは
①ミント
②トランスファー
③バーン
の時のタイムスタンプのようです。
１ー３ _ownershipsとは（mapping）
では、下の部分を見てみましょう。
上で扱った、TokenOwnershipの構造体に_ownerships[curr]を代入しているようです。
_ownershipsとはmappingのようです。
tokenIdを入れるとそれに応じたTokenOwnershipが返ってくるようです。
つまり、こんな感じですね。
そのため、ここでは、例えばtokenId:1の場合、新しく作った「ownership」にtokenid:1のアドレスとタイムスタンプを入れているのですね。
１ー４ lowestTokenToCheckとは
次は、下を見てみましょう。
maxBatchSizeとは最大のミント数です。
上のようにtokenId:96, maxBatchSizeを5とした時、lowestTokenToCheckは92になります。
これはなんでしょう？
下を見てみると、TokenId：96から92までのうち、0アドレスでない場合を探しています。
つまり、このような状況です。
ということは
① _ownerships[トークンID]にアドレスが入っていない場合がある
② 別の_ownerships[トークンID]のアドレスを返しうる
ということがわかりました。
ここで、「lowestTokenToCheck」である92は96までを一括ミントした可能性があるTokenIdです。
１ー５ ミント時に何が行われた？（現時点では推定）
これを踏まえると、次のことが推測できます。
92から96までを一括ミントした場合、_ownerships[92]にだけ情報を入れ、93から96までは何も入れないということです。
これにより、96が0アドレスであっても92まで確認する必要があり、92にアドレスが入っていればそれを返すということがわかります。
しかし、例えば、ミント後にTokenId:94をトランスファーしたらどうでしょう？
このようなケースも踏まえながら、先を見ていきましょう。
２ balanceOf関数とは
２ー１ 概要
では、次にbalanceOf関数を見ていきましょう。
オーナーのアドレスを渡すことで、NFTをいくつ持っているかを返してくれます。
最初の部分でオーナーが０アドレスでないことを確認しています。
では、次の_addressDataとはなんでしょう。
２ー２ AddressDataとは（構造体）
その前に、AddressDataという構造体を見てみましょう。
つまり、こんな感じですね、
２ー３ _addressDataとは（mapping）
では、_addressDataを見てみましょう。
アドレスを渡すことで、AddressDataを取得することができます。
構造は_ownershipsと同じですね。
２ー４ 結局、balanceOf関数とは？
では、balanceOf関数を見てみましょう。
_addressData[owner]のバランスをとっているようですね。
つまり、こんな挙動をしているようですね。
３ _numberMinted関数とは
こちらの関数はついでです。
ミントした数を取得するようですね。
構造はbalanceOf関数とほぼ同じです。
_addressData[owner]のミント数をとっているようですね。
４ _safeMintとは
では、ミントの部分を見てみましょう。
引数として、quantity（いくつミントするか）を渡しています。
４ー１ 処理前の動作
まずは簡単に処理前を見ていきましょう。
４ー１ー１ startTokenId
まずはどこからミントを行うのかであるstartTokenIdにcurrentIndexを入れます。
初期値は0ですね。
４ー１ー２ requireの処理について
ここでは簡単に。
最初にミント先が０アドレスでないことの確認を行っています。
次にstartTokenIdのトークンが存在していない（ミントされていない）ことを確認し、
最後にミントする量が上限以下かを確認しています。
maxBatchSizeが一度にミントができる最大の数です。
４ー２ _addressDataの更新
ミントによって、ミント先のアドレスの_addressDataの情報が変更します。
例えば、元々
①バランス:20
②ミント数:15
であり、今回新しく３個ミントするのであれば、次のように加える必要がありますね。
下の部分で実現しています。
４ー３ _ownershipsの登録
ここがポイントだと思います。
仮にtokenId:30~32の3個をミントした場合、_ownershipsを登録するのは先頭の30番だけです！
これが１ー５の箇所で触れた内容になります。
これを実現しているのが下の箇所です。
なんと一行なのですね。この一行がとても大事なポイントでした。
４ー４ currentIndexの更新
最後にcurrentIndexの更新です。
これを更新することで、次回どこからミントするのかを保持します。
今回は30~32をミントしたので、次回は33からですね。
イベントの発火やERC721Receivedについては今回は省略いたします。
４ー５ 結局 _safeMintは何をやっているの？
今までのことを踏まえると、_safeMintは主に下の３つをやっていることがわかりました。
ぜひ、整理してみてください。
５ approve系を見てみよう
５ー１ isApprovedForAllについて
では、isApprovedForAllについて見てみましょう。
どうやら、①owner、②operatorの２つのアドレスを渡して、bool型（○か×か）を受け取っているようです。
この_operatorApprovalsってなんでしょう。[]が２つもあってちょっと難しそうですね。
５ー２ _operatorApprovalsとは（mapping）
では、見ていきましょう。
下のように、mappingの中にmappingがあるようです。
なんでこんなに複雑なんでしょう？
理由は明確で要素が３つあるからです。
あとは、書き方さえ押さえれば、良さそうですね。
５ー３ 結局、isApprovedForAllって？
以上から、isApprovedForAllはAアドレスがBアドレスをapproveしているか否かをmappingを使って返していることがわかりました。
６ setApprovalForAllとは
こちらも一緒に見ていきましょう。
_operatorApprovals[][]にtrueかfalseを設定しているようですね。
図にするとこんな感じでしょうか。
７ mappingの初期状態は？
７ー１ 問題提起
ここは曖昧にしてしまうと、想定とは異なる挙動になりやすい部分なので見ていきたいと思います。
例えば、今回、0xXX..123アドレスは0xXX..012に対して、全く設定を行っていません。
その場合、_operatorApprovals[0xXX..123][0xXX..012]を取得しようとすると、次のどちらが起こるでしょうか？
① デフォルト値を取得する
② エラーが起こる（設定していないため）
７ー２ 実際に試してみよう
実際にどうなるかを試してみましょう。
AzukiのEtherscanから適当なアドレスを入れてみましょう。
https://etherscan.io/address/0xed5af388653567af2f388e6224dc7c4b3241c544#readContract
すると、上のように、エラーではなくfalseという結果が返ってきました。
以上から、設定を行っていない場合、エラーではなく、デフォルト値が返ってくることがわかりました。
○ ① デフォルト値を取得する
× ② エラーが起こる（設定していないため）
実際にsolidityのドキュメントも見てみましょう。
下のように、全ての可能なキーが存在し、デフォルト値が割り当てられるようです。
そして、デフォルト値はbool型ならfalse、uintやint型なら０が割り当てられます。
７ー３ どんな想定外が起こりうるの？
これによって、どんな想定外の自体が起こり得るでしょうか？
仮に、下のようなそれぞれの人の好きな色を格納するmappingがあったとします。
現在、0xXX..012は設定を行っていません。
しかし、エラーではなく、デフォルト値の0が入ってしまうので、0xXX..012の値を取り出すと0(red)となってしまいます。
このような挙動を知ることで、少しでも想定外やエラーの防止につながっていくと思います。
８ getApprovedとは
ここはサラッと見ていきましょう。
_tokenApprovals[tokenId]を返していますね。
こんな感じのmappingになっていますね。
では、先ほどの復習もかねてEtherscanでtokenId:1を見てみましょう。
https://etherscan.io/address/0xed5af388653567af2f388e6224dc7c4b3241c544#readContract
下のように、「1」でQueryすると0アドレスが返ってきます。
これは0アドレスを設定しているのではなく、何も設定を行っていないため、デフォルト値である0アドレスが返ってきていると考えるのが妥当です。
（ただ、_transfer時に0アドレスを設定された可能性も大いにあります。）
９ _transfer関数とは？
では、_transfer関数を見てみましょう。
９ー１ 処理前の動作
まずは処理に入る前の動作を見てみましょう。
isApprovedOrOwnerにboolを入れています。
実行するアドレスが、次のどれかである必要があります。
①現在の所有者
②getApprovedでtrue
③isApprovedForAllでtrue
その次の２つのrequireは次のことを確認しているようです。
①「from」が現在の所有者と一致している
②「to」は0アドレスではない
９ー２ _tokenApprovals[tokenId]の初期化
ここはとても大事な部分ですね。
現所有者が送付するtokenIdにBアドレスにapproveをしていたとします。
もしこれがそのままの状態でtransferされてしまったら、transfer後もそのtokenIdをBアドレスで操作できてしまいます。
それを防ぐために、_approve関数で0アドレスを設定しています。
_tokenApprovals[tokenId]は１対１のmappingなので、0アドレスを設定することで、上書くことができます。
９ー３ _accessDataの更新
_accessDataはそのアドレスが持っている①バランス②ミントした数の情報でした。
そのため、送付先はバランスの量を１増やし、送付元は１減らせば良いですね。
９ー４ _ownershipsの更新①（トランスファーしたtokenId）
_ownershipsはtokenIdにどの①アドレス、②タイムスタンプが紐づいているかのmappingでした。
トランスファーによってそのtokenIdの所有者が変わるので、更新を行います。
９ー５ _ownershipsの更新②（トランスファーした次のtokenId）
９ー５ー１ tokenIdの所有者情報の取得について（復習）
ownershipOf関数について、簡単に復習してみましょう（詳しくは第１章）
tokenId:96の所有者を探すとき、96番が0アドレスであれば、一つずつ遡り、最初に見つけた0アドレスでないアドレスを返していましたね。
では、ここで94番がトランスファーされたらどうでしょう？
96番は0xXXX..123が所有しているにもかかわらず、このままでは、0xXXX..465のものとして判定されてしまいます。
ということは、トランスファーした94番目の次が0アドレスであれば、0xXXX..123を入れれば良いですね。
あとはこれをコードで実現しているだけです。
①0アドレスか否か
②存在するか否か
を確認し、条件を満たす場合には、送付元の情報を入れています。
９ー６ 結局_transfer関数は何をやっているの？
結局、下のようなことをやっていましたね。
ややこしいと思いますので、整理しながら見てみてください。
１_tokenApprovals[tokenId]の初期化
⇨前の所有者が操作できないように
２_accessDataの更新
1)送付先 ⇨ バランスを１増やす
2)送付元 ⇨ バランスを１減らす
３_ownershipsの更新①
⇨送付したtokenIdにアドレス情報を追加する
４_ownershipsの更新②
⇨送付したtokenIdの次が下の条件を満たす時、
1)0アドレス
2)存在する
送付元のアドレス情報を追加する
１０ tokenByIndex関数について
その全体の中で特定のindexのtokenIdを取得します。
tokenIdと全体のindexは一致するため、indexを返すだけです。
１１ tokenOfOwnerByIndex関数について
１１ー１ 概要
では、tokenOfOwnerByIndex関数について見てみましょう。
特定のownerのindex番目のtokenIdを取得します。
次のような例で考えていきましょう。
例えば、Cが所有している1番目のtokenIdは6が返ります。
１１ー２ 具体的に見てみよう
tokenId:0から順にtokenを見ていきます。
大きな流れとしては独立して次の２つを行います。
① 0アドレスか否か
⇨0アドレスでなければ、currOwnershipAddrを変更する
②currOwnershipAddrがCアドレスか否か
⇨同じならtokenIdsIdxに+1,異れば次に行く
具体的に見てみましょう。
なお、CアドレスのIndex:1を探すものとします。
１） i = 0(tokenId:0)の時
2） i = 1(tokenId:1)の時
3） i = 4(tokenId:4)の時
4） i = 5(tokenId:5)の時
5） i = 6(tokenId:6)の時
コード自体は難しい構文などなさそうですので、上の動きになっているかを見てみてください。
１２ コンストラクタについて
コンストラクタについても見てみましょう。
引数として渡すのは次の４つです。
①name_
②symbol_
③maxBatchSize_（一度にミントできる量）
④collectionSize_（コレクションのMaxサイズ）
１３ ガス代の比較をしてみよう
では、コンストラクタとして渡すものもわかりましたので、ERC721とERC721Aでガス代を比較してみましょう。
１３ー１ ERC721Aを利用した場合
テストとして、次のコードを実行してみます。
注意
こちらのコードはガス代の比較のみを目的としている、公式を参考にしたコードです。他の動作などは保証していません。
https://etherscan.io/address/0xed5af388653567af2f388e6224dc7c4b3241c544#code
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
import "./ERC721A.sol";
contract AzukiTest is ERC721A { constructor() ERC721A("AzukiTest", "AZUKI TEST",100,100) {}
function mint(uint256 quantity) external payable {
// _safeMint's second argument now takes in a quantity, not a tokenId.
_safeMint(msg.sender, quantity);
}
}１３ー１ー１ デプロイ
デプロイしたところ、3,016,243gasでした。（後にRinkebyで試したところ、3,016,135gasでした。）
１３ー１ー２ 100個ミント
下のように、340,681gasでした。（後にRinkebyで試したところ、340,681gasでした。（同じ））
１３ー１ー３ 送付①（tokenId:50）
下のように、245,866gasでした。（後にRinkebyで試したところ、245,854gasでした）
１３ー１ー４ 送付②（tokenId:49）
次のtokenId:50が既にミント済みの場合の検証です。
この場合、tokenId:50の更新が不要のため、若干ガス代が下がります。
下のように、205,178gasでした。（後にRinkebyで試したところ、205,166gasでした）
１３ー２ ERC721Enumerableを利用した場合
テストとして、次のコードを実行してみます。
注意
こちらのコードはガス代の比較のみを目的としているコードです。他の動作などは保証していません。
比較を行うため、ownableなどの通常必要なものもつけていません。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;
import "@openzeppelin/contracts/token/ERC721/extensions/ERC721Enumerable.sol";
contract AzukiTest2 is ERC721Enumerable {
constructor() ERC721("AzukiTest", "AZUKI TEST") {}
function mint(uint256 quantity) external payable {
for(uint256 i = 0; i < quantity; i++) {
_safeMint(msg.sender, i);
}
}
}１３ー２ー１ デプロイ
デプロイしたところ、2,738,229gasでした。
１３ー２ー２ 100個ミント
100個のミントをしようとすると、下のようなエラーが出てしまいました。
そのため、これ以降は、Rinkebyで行います。
ただ、それにより、gas自体は変わらないことを確認するため、デプロイ時のgasを確認します。
下のように、11,523,464gasでした。
１３ー２ー３ 送付（tokenId:49）
下のように、88,824gasでした。
１３ー３ まとめてみよう
まとめてみると、下のようになりました。
小さい方を赤色太字にしています。
デプロイやトランスファーではERC721Enumerableの方が小さいものの、100個のミント時などに大きな差が出ることがわかりました。
本日は以上です。
いいなと思ったら応援しよう！
