抽象的な
副題
この記事は標準の ERC721 プロトコルを中心に展開し、Mint、safeMint、transfer などがどのように資産管理を実装するかを説明し、コードを解釈することでそのセキュリティ設計とイーサリアム データ チェーンのコスト構成を理解します。
ディレクトリの概要
ディレクトリの概要
1.いわゆるNFT資産とは何ですか?
文章
文章
文章
5. イーサリアムのストレージの料金はどれくらいですか?
副題
オブジェクト指向
研究開発 - 障壁なく読める、絶妙な契約設計を理解する
研究開発以外 - リストされたコードは理解できないかもしれませんが、標準プロトコルの設計思想は理解できます
最初のレベルのタイトル
opensea では、各 NFT に一意の番号があることがわかります。
たとえば、azuki シリーズの No.4132 では、ページの [詳細] 列にコントラクト アドレス、ID 番号、デプロイ先のパブリック チェーンなどの情報が表示され、[プロパティ] 列にはさまざまな属性の設定が表示されます。および対応するレアリティ（アズキ自体には非がありますが、Opensea 統合によって計算されます）。
副題
そして、ソース コードを振り返ると (ここでは ERC721 標準ライブラリの openzepplin コードを使用します)、プログラムが 2 つのグローバル辞書型変数を記録し、アドレスをマッピングすることで _owners に各 ID に現在対応するすべての ID を記録していることがわかります。または、現在の所有者が保有する NFT の合計数も _balances で記録します。
また、ERC721 は革新的に変数 _owners にアドレスに対応する ID を付与するため、アドレスと残高を ERC20 の _balances のみで管理し、FT (均一性) と NFT (非均一性) の違いを区別します。
最初のレベルのタイトル
2.1 ミントの仕組みNetflixのNFTがWeb2のビジネスセキュリティを忘れたとき
ミントとは、以前のLove Death Machine NFTなど、各NFTの作成プロセスであるキャスティングを意味します
NetflixのNFTがWeb2のビジネスセキュリティを忘れたとき
MintはNFTの資産証明書を取得しました。
ソース コードからわかるように、Mint は主にセキュリティの判断を行います。
判断2：当取引所が運用するNFTIDが存在しないことを確認する
最終的なコードの動作は次のとおりです。
操作 1: 転送されたアドレスが保持する _balance の総数に 1 を加算します。
判断1：転入アドレスが0x00でないこと（ブラックホールアドレスは転出不可、転入すると資産が失われる）
操作 2: 対応する NFTID の所有者を転送されたアドレスに変更する
操作 3: トランザクションが完了すると、エミット イベントが送信され、オフチェーンがこのトランザクションのデータを監視できるようになります。
真ん中の_beforeTokenTransferと_afterTokenTransferは仮想関数で、標準プロトコルを変更することなくプロジェクト側で特定のロジックコードを追加するために使用されます。
2.2 なぜsafeMintがより安全なのか
safeMint は安全なキャストの意味で、実装コードを見ると Mint 自体も呼び出していることがわかりますが、さらに ERC165 規格に属する _checkOnERC721Received の判定が追加されており、転送操作後の相手判定に相当します。アドレスがブラックホールアドレス（つまり、トランザクションNFT操作を開始できないアドレス）であるかどうかは、転送オブジェクトがコントラクトアドレスであり、コントラクトに事前に設定された転送機能がない場合に、その結果、譲渡できない資産が増加し、永久的な損失が発生します。https://eips.ethereum.org/EIPS/eip-165
2.3 ERC165 は資産がブラックホールに転送されるのをどのように防止しますか?
設計の本来の意図は次のとおりです。
コントラクトインターフェースを標準化する提案です. プログラミング文法においてインターフェースとはインターフェースを意味します. ここで定義されている関数は実装できず関数名に関係するパラメータを置くだけです. プログラムが複雑な場合はコントラクトインターフェースに相当します.私が持っている機能を他の人に伝えるためのディレクトリ。
ただし、インターフェースの書き方には一長一短があり、名前によってパラメータの型が定義されたり、存在するかどうかすら異なります。
したがって、この提案は最終的にインターフェイスの識別規則を標準化する ERC165 標準を形成しました。
使用プロセスは次のとおりです。
ステップ 1 SupportsInterface 関数が存在し、それが 165 標準に準拠しているかどうかを確認します。
（追記：契約にNFT受信転送機能を持たせます。これはIERC721Receiver.sol拡張パッケージを導入することで実現できます）
文章
標準プロトコル設計には、transfer と transferFrom という 2 つの転送メソッドがあり、次の 2 つのシナリオで使用されます。
transfer Transfer: このメッセージを送信するウォレットが保持する NFTID を指定されたアドレスに転送するためにユーザーによって呼び出されます。
以下と比較してください:
transferFrom 転送元: 特定の組織によって呼び出され、ユーザーは転送する権利を得るために、最初に特定のアドレスを承認する必要があります。
以下と比較してください:
送金は現金取引です。自分のポケットからお金を支払います。
transferFrom は、コードをスキャンしてお金を差し引くことです。ストアは、ユーザーが少額の源泉徴収権限をオープンしたかどうかに応じて、差し引きを申請します。
次に、予期しない詳細が含まれる可能性があるコードを見てみましょう。
3.1 転送の仕組み
彼は、現在のトランザクションの送信者がこの NFTID の所有者であるかどうかを検出し、NFT が 0x00 アドレスに転送されるのを制限します。次に、転送元アドレスと転送先アドレスの残高を更新し、_balances グローバル変数を変更して、_owners をリセットして、この NFTID の所有者アドレスを to に変更します。
ここに保護の詳細があります。最初に _approve(address(0), tokenId); を実行して、履歴の承認をクリアします。そのようなステップがない場合、資産の移転は完了しますが、NFTID の移転承認はまだ残っています。考えてください。気をつけて：
3.2 transferFrom の仕組み
ここでのトランザクションの性質は _safeTransfer を呼び出すため、そのコア ロジックは require 部分です。
ここでの詳細は次のとおりです。 _msgSender() これは、openzepplin の標準ライブラリ Context.sol のメソッドです。
実際には、現在のトランザクションの送信者アドレスを取得するためですが、ここでは msg.sender を直接使用する代わりに、カプセル化されたバージョンが使用されます。
したがって、図書館と同様に、中間の一部の契約では、この特殊な状況を考慮する必要があります。
残りの判断は承認記録があるかどうかです。承認記録は理解しやすく、重複することはありません。
最初のレベルのタイトル
4. チェーンには他にどのようなデータを保存できますか?
トランザクションリンクを読んだ後、多くの新入生は実際に驚きましたが、私が購入したNFTには、帰属アドレスが私を指すIDが1つだけあり、一意性が達成されていることがわかりました。それにしてもレア情報はどこにあるのでしょうか？私のNFTイメージ自体はどこにありますか?
これは、ERC721 に関連するメタデータ拡張子 IERC721Metadata.sol です。
何でも好きなものを入れることができますが、多くの場合、プロジェクト パーティはチェーン上の最も基本的な ID+IPFS アドレスのみを保存します。
以前の Etherscan チュートリアルの方法でいくつかのプロジェクト データを確認できますか?
AZUKI の契約アドレスは 0xed5af388653567af2f388e6224dc7c4b3241c544 です。
最近登場したメタバース プロジェクトであるメタバース ランド サンドボックスと **Decentraland、そして昨年の激しい **Axie Infinity では、チェーンに保存される基本的なメタデータは ID+URL のみです。
ミラーのようなものは、低コストで大容量のストレージを実現するために特別に設計されており、通常、ブロックは 30M から始まり、これはイーサリアムの約 1000 倍です。
最初のレベルのタイトル
5. イーサリアムのストレージの料金はどれくらいですか?
ここがこの記事の少し難しいところです。オンチェーンストレージのコスト構成と金額換算をソースコードから分析してみよう
実行プロセスに応じて、コストの生成には 2 つの側面があります。
ユーザーがトランザクションを開始すると、チェーンに書き込まれるデータがパラメータとして渡され、そのサイズがコストとなります。
トランザクションは契約コードを実行し、EVM は変更と使用量に応じて消費されるガスコストを計算します。
5.1 トランザクション開始のコスト
トランザクションデータサイズによって消費されるガスの明確な定義があるイーサリアムイエローペーパーを確認できます
取引所に付加されたパラメータの価格を確認できます。
各トランザクションの支払い額は 21000 GAS です
トランザクションの非ゼロバイトデータまたはコードごとに 68 GAS を支払います
トランザクションのゼロバイト データまたはコードごとに 4 GAS を支払います
したがって、Mintに何らかのNFT属性情報を登録すると、トランザクションのデータ部分でabcなどの文字が2つの16進数表現に変換され、各文字は1バイトに等しい8ビットのバイナリになります。したがって、データの長さをバイト数として 2 で割った値とほぼ等しくなります。
また、1kb のデータは、情報量がゼロではないすべてのテキスト情報である場合、68*1000=6.8W のガス消費量が増加することに相当します。 20gwei のガス価格と米ドルに交換された 2000 eth の価格によると、チェーン上の 1 kb のデータごとに次のものが必要であると推定できます。
20*(21000+68000)*1e9/1e18 * 2000 = USD 3.5
func gasSStore(evm *EVM, contract *Contract, stack *Stack, mem *Memory, memorySize uint64)(uint64, error)
5.2 契約保管のコスト
トランザクション開始後にスマート コントラクトにロジックが保存されているため、イーサリアム go (EIP1283) のソース コードから具体的な消費量を分析してみましょう。コードは特に関数内にありますが、長すぎて貼り付けることができません。
歴史的に、ガス消費量の推定は数回反復されてきました。サンクトペテルブルクまたはコンスタンティノープルがアクティブ化されていない場合、次のロジックに従って計算は実行されません。
ガス消費量の計算は3種類のデータ管理（追加・削除・変更）によります
ゼロ値のアドレスからゼロ以外の値 (新しい値) まで、各ストレージ スロットは 2Wgas を消費します。
非ゼロ値アドレスからゼロ値アドレス (DELETE) まで、各ストレージ スロットは 5K ガスを消費する必要がありますが、1.5W のガスリターンが得られます。
非ゼロから非ゼロ (CHANGE) まで、各ストレージ スロットは 200 ガスを消費します
上記の各ストレージ スロットは 32 バイトとしてカウントされ、1kb のストレージは 32 のストレージ スロットであることに注意してください。 Mint のプロセスでは新しいストレージを追加するため、追加の 1 kb のデータがチェーンに保存される場合、コストは 64Wgas となり、変換量は次のようになります。
EIP-5058はNFTプロジェクト関係者がバケツを持って逃げるのを防ぐことができますか？
EIP-5058はNFTプロジェクト関係者がバケツを持って逃げるのを防ぐことができますか？
