著者: @Web3Mario (https://x.com/web3_mario)
要約: TONに関する前回の記事に続きます 技術紹介記事, 私はこの期間中に TON の公式開発ドキュメントを徹底的に勉強してきましたが、学習にはまだいくつかの障壁があると感じています。現在のドキュメントの内容は内部開発ドキュメントに近いようで、あまり充実していません。したがって、私自身の学習軌跡に基づいて TON Chain プロジェクト開発に関する一連の記事を整理して、皆様が TON DApp をすぐに使い始めるのに役立つことを願っています。 開発。文章に間違いがある場合は、修正して一緒に学んでいただければ幸いです。
FT または NFT これは通常、DApp開発者にとって最も基本的なニーズです。したがって、私はこれを学習の入り口としても使用します。まず、EVMテクノロジースタックでのNFTの開発とTON Chainでの開発の次の違いを理解しましょう。EVMに基づくNFTは、通常、ERC-721の標準を継承することを選択します。いわゆるNFTは、分割できないタイプの暗号資産を指し、各資産はユニークです、つまり、特定の排他的な特性を持っています。そして、ERC-721 は、このタイプのアセットの一般的な開発パラダイムです。一般的なERC721コントラクトで実装する必要がある機能と、どのような情報が記録されるかを見てみましょう。下の写真はERC721インターフェースです。 FTとは異なり、送金インターフェイスに入力する必要があるのは、金額ではなく送金するtokenIdであることがわかります。この tokenId は、NFT の一意性の最も基本的な具体化でもあります。 もちろん、より多くの属性を保持するために、通常は tokenId ごとに メタデータ が記録されます。 メタデータは、PFP画像へのリンク、特定の属性名など、NFTの他のスケーラブルなデータを保存する外部リンクです。
Solidityに精通している開発者、またはオブジェクト指向に精通している開発者にとって、コントラクトで必要なデータ型が次のように定義されている限り、このようなスマートコントラクトを実装するのは簡単です。いくつかのキーマッピングの関係マッピングを作成し、必要な機能に従ってこれらのデータに対応する変更ロジックを開発すると、NFTを実装できます。
しかし、TON Chainでは、違いの主な理由が 2 つあります。 と EVM でのスマート コントラクト開発の間に大きな違いをもたらします。最初の議論では、NFT関連データを保存するには、NFTコントラクトがいくつかのマッピング関係、つまりマッピングを定義する必要があることが分かりました。最も重要なものは所有者です。このマッピングは、NFTに対応する特定のtokenIDのマッピング関係を保存し、NFTの所有権と譲渡を決定します。 それはその所有権の変更です。これは理論上無制限になり得るデータ構造であるため、可能な限り回避する必要があります。したがって、無制限のデータ構造の存在をシャーディングの標準として使用することが公式に推奨されています。つまり、同様のデータ ストレージ要件がある場合、代わりに マスター/スレーブ コントラクト パラダイム が使用され、各 key に対応するデータはサブコントラクトを作成することによって管理されます。また、メイン コントラクトを通じてグローバル パラメーターを管理したり、サブコントラクト間の内部情報のやり取りの処理を支援したりできます。 これは、TONのNFTも同様のアーキテクチャで設計する必要があることを意味し、各NFTは、所有者のアドレスなどを保存します。 メタデータやその他の独占的なデータ、NFT名、シンボル、総供給量などのグローバルデータを管理するためにメインコントラクトが使用されます。 アーキテクチャを明確にしたら、次のステップはコア機能要件を解決することです。このマスター/スレーブ契約方式の採用により、どの機能がメインコントラクトによって担われるのかを明確にする必要があります。機能はサブコントラクトによって実行され、両者間でどのような内部情報が通信されるか、実行エラーが発生した場合に以前のデータをどのようにロールバックするかなどです。通常、複雑で大規模なプロジェクトを開発する前に、クラス図を渡して相互間の情報の流れを明確にし、内部呼び出し失敗後のロールバックロジックを慎重に検討する必要があります。もちろん、上記のNFT。開発は簡単ですが同様の検証も可能です。 TONクラスCを選択して、静的型言語、Funcという名前を付けますスマートコントラクト開発言語を理解したら、ソース コードから TON スマート コントラクトを開発する方法を学びましょう。 TON の公式ドキュメントにある NFT のサンプルを選択して紹介します。興味のある方はぜひご覧ください。あなた自身。簡単なTON NFTの例がこのケースに実装されています。コントラクト構造を見てみましょう。コントラクト構造は 2 つの機能コントラクトと 3 つの必要なライブラリに分かれています。 nft-collection: のコードを見てみましょう。 これは、TONスマートコントラクトにデータを永続的に保存する方法という最初の知識ポイントを紹介します。Solidityのデータの永続的保存は、パラメータのタイプに従って実行されることがわかっています。通常、スマート コントラクトの状態変数は、実行後に最新の値に基づいて自動的に永続化され、保存されます。開発者はこのプロセスを考慮する必要はありません。しかし、これは Func には当てはまりません。開発者は対応する処理ロジックを自分で実装する必要があります。この状況は、GC を考慮する必要がある C や C++ のプロセスに似ています。 ただし、他の新しい開発言語は通常、ロジックのこの部分を自動化します。コードを見てみましょう。まず、必要なライブラリをいくつか紹介します。次に、最初の関数 load_data が、永続的に保存されたデータを読み取るために使用されることがわかります。そのロジックは、最初に を通じて永続データを返すことです。 get_data コントラクトストレージcell。通常の状況では、一部の関数はシステム関数として使用できることに注意してください。 この関数の戻り値の型はcellで、これはTVMのcellの型です。前回の紹介で、TON ブロックチェーン内のすべての永続データが cell ツリーに保存されることはすでにわかっています。各セルには、最大1023ビットの任意のデータと、他のセルへの参照が最大4つあります。 cellは、スタックベースのTVMのメモリとして使用されます。cellは、厳密にエンコードされたデータを保存します。特定の平文データを取得するには、cellをsliceという型に変換する必要があります。 cellは、begin_parse関数によってslice型に変換でき、その後、sliceデータからデータビットと他のcellへの参照をロードすることで取得できます。 。コードの 15 行のこの呼び出しメソッドは、func の糖衣構文であり、最初の関数の戻り値を使用して 2 番目の関数を直接呼び出すことができることに注意してください。そして最後に、データの永続化順序に従って、対応するデータを順番にロードします。このプロセスはsolidityとは異なり、hashmapに基づいて呼び出されないため、呼び出しの順序を間違えることはできないことに注意してください。 save_data関数でも、ロジックは似ていますが、これが逆のプロセスである点が異なり、次の知識ポイントである新しいタイプビルダー、これはセルのタイプを導入します。 ビルダー。データビットと他のcellへの参照はビルダーに保存でき、その後、新しいcellに完成させることができます。まず、標準関数 begin_cell を使用して builder を作成し、次に store 関連関数を使用して関連関数を保存します。上記の呼び出し順序は、ここでの保存順序と一致している必要があることに注意してください。最後に、end_cellを通して、新しいcellが構築されます。このとき、cellは、最後に、最も外側のset_dataを通して管理されます。 cellの永続ストレージ。 次に、ビジネス関連の機能を見てみましょう。まず、次の知識ポイントである、今紹介したマスター/スレーブ アーキテクチャで頻繁に使用される、コントラクトを通じて新しいコントラクトを作成する方法を紹介する必要があります。 TON では、スマート コントラクト間の呼び出しは内部メッセージを送信することによって実装されることがわかっています。これは、send_raw_messageというファイルによって実現されます。最初のパラメータはmessageエンコードされたcellであり、2番目のパラメータはトランザクションを示すために使用される識別ビットであることに注意してください。実行メソッド、内部メッセージ送信のさまざまな実行メソッドは TON で設定されており、 には現在 3 種類のメッセージモード と 3種類のメッセージフラグ があります。単一の Mode を複数の (おそらく何もない) フラグと組み合わせて、目的の mode を取得できます。組み合わせとは、それぞれの値の合計を記入することを意味します。 Modes と Flags の説明テーブル を以下に示します。 deploy_nft_item を見てみましょう。名前が示すように、これは関数です。新しいNFTインスタンスを作成またはキャストする関数。msgをエンコードするいくつかの操作の後、send_raw_messageを介して送信され、flag 1が送信されます。 が選択されている場合、エンコードで指定された fee のみが、この実行の gas 料金 として使用されます。上記の導入後、このコーディング ルールは新しいスマート コントラクトを作成する方法に対応する必要があることが容易に理解できます。 それでは、それがどのように実装されるかを見てみましょう。 51行を直接見てみましょう。上記の2つの関数は、メッセージに必要な情報を生成するために使用される補助関数です。これは、後で使用する内部メッセージです。スマート コントラクトを作成する エンコード プロセスでは、中央のいくつかの数字は実際には内部メッセージのニーズを説明するために使用される識別ビットです。ここで TON と呼ばれるタイプを選択します。 -B バイナリ言語は、メッセージの実行方法と、さまざまなフラグ ビットの設定に基づいて特定の機能を実装する内部メッセージを記述するために使用されます。最も簡単に考えられる 2 つの使用シナリオは、新しいコントラクトの作成とデプロイされたコントラクト関数の呼び出しです。 51行のメソッドは前者に相当し、主に55、56、57を通して行われる新しいnft itemコントラクトの作成です。指定された。まず、55行の大きな一連の数値は一連の識別ビットです。store_uintの最初の入力パラメータは数値であり、2番目はビット長であることに注意してください。これは、内部メッセージがコントラクトによって作成されたかどうかを決定します。これは最後の 3 つのマーク ビットであり、対応するバイナリ値のビットは 111 (10 進数では 4+2+1) です。 2 つは、メッセージに StateInit データが伴うことを示します。このデータは、新しいコントラクトのソース コードであり、初期化に必要なデータです。後者のフラグ ビットは、内部メッセージの添付ファイルを示します。つまり、関連するロジックと必要なパラメーターが実行されることが予想されます。したがって、デプロイされたコントラクトへの関数呼び出しを示す 66 行には 3 桁のデータが設定されていないことがわかります。詳細なコーディング規則はここで参照できます。 その後、StateInitのエンコード規則は、calculate_nft_item_state_initによって計算されたコードの49行に対応し、stateinitdataのエンコードも従うことに注意してください。設立されました TL- Bエンコーディングルールは、一部のフラグビットを除き、主に新しいコントラクトcodeと初期化dataの2つの部分に関係します。 dataのエンコード順序は、新しいコントラクトで指定された永続的なcellのストレージ順序と一致している必要があります。36行目に見られるように、初期化データにはERC721のtokenIdに似たitem_indexと標準関数が含まれています。 私の _ address 返される現在の契約アドレスは collection_address です。このデータの順序は nft-item のステートメントと一致しています。 次の知識ポイントは、TON では、すべての未生成のスマート コントラクトが生成されたアドレスを事前に計算できるということです。これは、Solidity の create2 関数と似ています。 TONのアドレスは、workchain識別ビットとstateinitのハッシュ値の2つの部分で構成されており、前者は対応するTONのものであることがすでにわかっています。無限シャーディング アーキテクチャに指定されている値は、現在統一された値です。標準関数workchainから取得します。後者は標準関数cell_hashによって取得されます。この例に戻りますが、calculate_nft_item_address は、新しい契約アドレスを事前に計算する関数です。そして、53行で生成された値を、内部メッセージの受信アドレスとしてmessageにエンコードします。そしてnft_contentは作成したコントラクトへの初期化呼び出しに相当します。具体的な実装は次の記事で紹介します。 send_royalty_params については、読み取り専用リクエストの内部メッセージへの応答である必要があることを、前の紹介で特に強調しましたが、TON の内部メッセージはそれだけではありません。データ操作と読み取り専用操作もこの方法で実装する必要があるため、このコントラクトはそのような操作であることに注意してください。最初に注意すべきことは、67 行が後のリクエスターのコールバック関数のマークを示していることです。それが返されたデータであり、要求された アイテム インデックス と対応する ロイヤルティ データです。 次の知識ポイントを紹介しましょう。TONには、recv_internalとrecv_externalという名前の2つの統合された入り口しかありません。前者はすべての内部メッセージを統合しています。コール エントリ。後者は、すべての外部メッセージに対する統合コール エントリです。開発者は、messageで指定されたさまざまなフラグ ビットに基づいて、関数内で switch と同様のメソッドを使用する必要があります。ここでマークビットは上記行67のコールバック関数マークです。この例に戻ると、まず message で空きチェックを実行し、次に message 内の情報をそれぞれ解析します。 まず、83 行を解析して sender_address を取得します。 。ここでの ~ 演算子は、後続の権限チェックに使用されます。ここでは詳しく説明しません。次に、op オペレーション フラグ ビットが解析され、対応するリクエストがさまざまなフラグ ビットに従って処理されます。このうち、上記の関数はそれぞれ一定のロジックに従って呼び出されます。たとえば、royaltyパラメータのリクエストに応答したり、新しいnftを作成してグローバルindexをインクリメントします。 次のナレッジポイントは108の行に相当します。これは、Solidityのrequire関数と同様に、この関数の処理ロジックを知ることができると思います。 Func 例外は標準関数 throw_unless を通じてスローされます。最初の入力パラメーターはエラー コードであり、2 番目の入力パラメーターはビットが false の場合は例外です。というエラーコードがスローされます。この行では、equal_slicesを用いて、上で解析したsender_addressがコントラクトの永続ストレージのowner_addressと等しいかどうかを判定し、許可判定を行っています。
TONエコロジーDAppの開発は本当に面白いもので、EVMの開発パラダイムとは大きく異なるので、TON Chainでの開発方法をシリーズで紹介していきますの記事DAppで開発されました。皆さんと一緒に学び、このチャンスの波を掴みましょう。また、twitter で私と交流して、新しくて興味深い dapp のアイデアに出会い、一緒に開発することも歓迎します。
TON
ソースコードから学習して開発TONスマートコントラクト
以上がTONプロジェクト開発チュートリアル(1)：ソースコードの観点からTON Chain上にNFTを作成する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
