リスクから保護へ：TONスマートコントラクトのセキュリティリスクと最適化提案
ブロックチェーン技術の急速な進化の中で、TON（The Open Network）は効率的で柔軟なブロックチェーンプラットフォームとして開発者の間でますます注目されています。TONのユニークなアーキテクチャと機能は、分散型アプリケーションの開発に強力なツールと豊富な可能性を提供しています。
しかし、機能と複雑さの増加に伴い、スマートコントラクトのセキュリティはますます重要になっています。TON上のスマートコントラクトプログラミング言語であるFunCは、その柔軟性と効率性で知られていますが、多くの潜在的なリスクと課題も抱えています。安全で信頼性の高いスマートコントラクトを作成するには、開発者がFunCの特性と関連する潜在的なリスクについて深い理解を持っていることが求められます。
この記事では、TONブロックチェーン上のスマートコントラクト関連機能について詳細な分析を提供し、しばしば見落とされがちなTONスマートコントラクトの脆弱性についても説明します。
TONの非同期機能とアカウントメカニズムの分析
スマートコントラクトでの非同期呼び出し
ネットワーク・シャーディングと非同期通信
TONブロックチェーンは、マスターチェーン、ワーキングチェーン、およびシャードチェーンの3種類のチェーンで設計されています。
マスターチェーンはネットワーク全体のコアであり、ネットワーク全体のメタデータとコンセンサスメカニズムを保存する役割を担っています。すべてのワーキングチェーンとシャードチェーンの状態を記録し、ネットワークの一貫性とセキュリティを確保します。ワーキングチェーンは独立したブロックチェーンで、最大2^32チェーンで、特定の種類のトランザクションとスマートコントラクトの処理を担当します。各ワーキングチェーンは、さまざまなアプリケーションのニーズを満たすために、独自のルールと機能を持つことができます。シャードチェーンはワーキングチェーンのサブチェーンであり、ワーキングチェーンのワークロードをさらに分割し、処理能力とスケーラビリティを強化するために使用されます。各ワーキングチェーンは最大2^60個のシャードチェーンに分割でき、シャードチェーンは一部のトランザクションを個別に処理して効率的な並列処理を実現します。
理論上、各アカウントは個別にShardchainを占有し、各アカウントは独立してCOIN/TOKEN残高を維持します。アカウント間の取引は完全に並列化されることができます。アカウントは非同期メッセージを介して通信し、Shardchain間を移動するメッセージの経路はlog_16(N) - 1であり、ここでNはShardchainの数です。
画像ソース：https://frontierlabzh.medium.com/TON-Weixin-e1d3ae3b3574Web3の世界では、Tonでは、やり取りはメッセージの送受信によって行われます。これらのメッセージは内部的なもの（通常は互いに相互作用するスマートコントラクトによって送信される）または外部的なもの（外部のソースから送信される）である場合があります。メッセージパッシングプロセスは、ターゲットコントラクトからの即時の応答を必要としないため、送信者は残りのロジックの実行を続けることができます。この非同期メッセージングメカニズムは、Ethereumの同期呼び出しに比べて、柔軟性とスケーラビリティを提供し、応答を待つためのパフォーマンスボトルネックを減らす一方、同時性と競合状態の処理に関する課題をもたらします。
メッセージの形式と構造
TONでは、メッセージには通常、送信者、受信者、金額、およびメッセージ本文などの情報が含まれています。メッセージ本文には、関数呼び出し、データ転送、またはその他のカスタムコンテンツが含まれることがあります。TONのメッセージ形式は柔軟かつ拡張可能に設計されており、異なる契約間でさまざまなタイプの情報を効率的に伝達することができます。
メッセージキューとステータス処理
各契約は、まだ処理されていないメッセージを格納するメッセージキューを保持します。実行中、契約はキューから一つずつメッセージを処理します。メッセージの処理は非同期で行われるため、メッセージを受信しても契約の状態はすぐに更新されません。
非同期メッセージングの利点
•効率的なシャーディングメカニズム：TONの非同期メカニズムは、シャーディング設計と非常に互換性があります。各シャードは契約メッセージと状態の変更を独立して処理し、クロスシャード同期による遅延を回避します。この設計により、全体のネットワークスループットとスケーラビリティが向上します。
•リソース消費の削減：非同期メッセージは即座の応答を必要とせず、TON契約が複数のブロックをまたいで実行され、単一のブロック内での過剰なリソース消費を回避します。これにより、TONはより複雑でリソース集約型のスマートコントラクトをサポートできます。
•フォールトトレランスと信頼性：非同期メッセージパッシングメカニズムにより、システムのフォールトトレランスが向上します。たとえば、リソースの制約や他の理由により契約がタイムリーにメッセージに応答できない場合、送信者は他のロジックの処理を続けることができ、単一の契約による遅延によるシステムの停止を防ぐことができます。
非同期契約設計の課題
•状態の整合性問題：メッセージの送受信が非同期であるため、契約は異なる時刻に異なるメッセージを受信する可能性があります。これにより、開発者は状態の整合性に特別な注意を払う必要があります。契約を設計する際には、異なるメッセージの順序が状態の変化にどのように影響するかを考慮し、システムがすべての条件下で整合性を維持することを確認することが重要です。
•レース条件と保護：非同期メッセージ処理によって、複数のメッセージが同時に契約状態を変更しようとする潜在的な競合状態の問題が発生する可能性があります。開発者は適切なロックメカニズムを実装するか、トランザクション操作を使用して状態の競合を防止する必要があります。
•セキュリティに関する考慮事項：非同期の契約は、クロス契約通信の処理時に中間者攻撃やリプレイ攻撃などのリスクにさらされる可能性があります。したがって、非同期の契約を設計する際には、これらの潜在的なセキュリティリスクに対処し、タイムスタンプ、ランダムな数字、またはマルチサインアプローチなどの予防策を取ることが重要です。
レジャーモデル
TON(The Open Network)は、ブロックチェーンインフラストラクチャの設計において、独自のアカウント抽象化および台帳モデルを採用しています。このモデルの柔軟性は、アカウントの状態、メッセージの受け渡し、コントラクトの実行を管理する方法に反映されています。
アカウント抽象化
TONのアカウントモデルは、契約ベースの抽象化を使用しており、各アカウントは契約と見なすことができます。これは、Ethereumのアカウント抽象化モデルにやや似ていますが、より柔軟で一般的です。TONでは、アカウントは単なる資産のコンテナに過ぎません。また、契約コードと状態データも含まれます。各アカウントには、コード、データ、メッセージ処理ロジックが含まれています。
アカウント構造：すべてのTONアカウントには固有のアドレスがあり、このアドレスはアカウントコードのハッシュ値、展開時の初期データ、その他のパラメータの組み合わせから生成されます。つまり、異なる環境（たとえば、異なるブロックチェーンやシャード）で展開された同じコードと初期データは異なるアドレスを生成する可能性があります。
柔軟性：各アカウントが独自のコントラクトコードを実行できるため、TONアカウントは非常に複雑なロジックを実装できます。アカウントは単なる残高保持者ではなく、複雑な状態遷移、アカウント間のメッセージ通信、特定の条件に基づく自動化さえも処理できます。これにより、TONのアカウントモデルは従来のブロックチェーンのアカウントモデルに比べてスケーラブルで柔軟性が高くなります。
レジャー構造
TONの台帳構造は、大規模な並行トランザクションを効率的に処理し、非同期メッセージパッシングとマルチシャード操作をサポートするように設計されています。各アカウントの状態は、メルクルツリー構造に格納されており、効率的な状態検証機能を提供しています。
状態ストレージ
アカウントの状態情報は永続的なストレージに保存され、Merkleツリーを介して整合性とセキュリティが確保されています。この設計では、特にクロスシャードトランザクションにおける状態の効率的なクエリと検証をサポートしています。
アカウントまたはスマートコントラクトの状態には通常、次のものが含まれます。
- 基本通貨の残高 2. 他の通貨の残高 3. スマートコントラクトコード（またはそのハッシュ） 4. スマートコントラクトの永続データ（またはそのMerkleハッシュ） 5. 永続ストレージユニット数と生のバイト使用量に関する統計 6. スマートコントラクトの永続ストレージへの最近の支払いのタイムスタンプ（基本的にはメインチェーンのブロック番号） 7. このアカウントから通貨を送金し、メッセージを送信するために必要な公開鍵（任意; デフォルトでは、これはaccount_id自体と同じです）。場合によっては、ビットコイン取引のアウトプットのように、より複雑な署名チェックコードがここに見つかる場合があります。そのような場合、account_idはこのコードのハッシュになります。
すべてのアカウントにはすべての情報が必要ではありません。たとえば、スマートコントラクトのコードはスマートコントラクトにのみ関連しており、「簡単な」アカウントには関連していません。さらに、すべてのアカウントにはベース通貨（例えば、基本の作業チェーンとシャードチェーン用のグラム）のノンゼロの残高が必要ですが、他の通貨の残高はゼロでも構いません。未使用のデータを保持しないために、作業チェーンの作成時には、さまざまな「コンストラクタ関数」を識別するために、異なるマーキングバイトを使用してサムプロダクトタイプが定義されます。最終的に、アカウントの状態は、TVMの永続ストレージ内のユニットのコレクションとして保存されます。
メッセージパッシングと処理
TONのレジャーストラクチャには、非同期メッセージパッシングの組み込みサポートが含まれています。各アカウントは受信したメッセージを独立して処理し、状態を更新することができます。この非同期メッセージングメカニズムにより、他のアカウントの通常の動作に影響を与えることなく、アカウント間で複雑な相互作用が可能となります。
ガスモデル
TON（The Open Network）は、独自のガス料金モデルを通じてスマートコントラクトの実行効率を大幅に最適化しています。このガス料金モデルは、スマートコントラクトの実行中に消費されるリソースを測定および制限するために使用されます。従来のEthereumなどのブロックチェーンと比較して、TONのモデルはより複雑で効率的であり、契約の実行中のリソース消費をより正確に管理できます。
TONのガスモデルは、スマートコントラクトの実行中に消費される計算リソース、ストレージ操作、およびメッセージパッシングのコストを正確に測定できます。計算、ストレージ、メッセージングなどのリソースに対する詳細な測定値を提供することで、TONのガスモデルは、複雑さが過度に高い操作が多くのリソースを消費するのを防ぎます。ガス消費を制限することで、TONは各ネットワークノードが計算リソースを公平に割り当てることを確実にし、単一の契約または操作によるネットワークリソースの過度な使用を回避します。
TONはスマートコントラクトの並列処理をサポートしており、複数のコントラクトが異なるシャード上で同時に実行され、お互いをブロックすることなく動作します。この設計では、ガスモデルは並列実行とシャーディングメカニズムと密接に統合されています。複数のシャードをまたいでコントラクトを並列処理することにより、TONはガスの計算と支払いを異なるノードやチェーンに分散させ、ネットワークの混雑を回避しながらリソースの利用を最大化することができます。
TONのガスモデルには、ネットワークのリアルタイム負荷に基づいてガス料金を調整する動的調整メカニズムが含まれています。つまり、ネットワーク負荷が低い時期には、ユーザーは低いガス料金で契約を実行できるため、オフピーク時に操作を促進し、ネットワークリソースの使用をバランスさせることができます。このメカニズムは、ユーザーエクスペリエンスを向上させるだけでなく、市場主導のアプローチを通じてピーク時のリソース使用を制御します。
大量のスマートコントラクトは、無視しやすい抜け穴です
In 私たちの以前のセキュリティ分析記事TONについて、TONエコシステム内の一般的なセキュリティ脆弱性について詳細に説明しています。詳細は以下の表を参照してください。
この記事では、私たちのチームによってまとめられた、しばしば見落とされがちなTON契約の脆弱性に焦点を当てます。
(1) コードの可読性の最適化
TONスマートコントラクトでは、メッセージ送信に関連するデータを格納するために数値がよく使用されます。たとえば、次のコードでは、対応する識別子とデータストレージの長さを表すために数値の複数のインスタンスが使用されているため、コードの可読性と保守性が大幅に低下します。他の開発者は、コードを読むときにこれらの数値の意味と目的を理解するのが難しいと感じるかもしれません。可読性と保守性を向上させるために、キーの数値を名前付き定数として定義することをお勧めします。たとえば、0x18asNON_BOUNCEABLE.
check_std_addr(address);was msg = begin_cell() store_uint(0x18, 6) ;; nobounce store_slice(address) store_coins(amount) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(msg, 1);
さらに、契約判定条件のエラーメッセージについては、エラーコードを置き換えるために対応する変数を定義することもお勧めです。
(2) 使用するend_parse()データの整合性を確保するために
TONコントラクトでは、データ解析は固定された順序に従い、生データから指定されたタイプのデータを段階的にロードします。この解析方法では、次に示すように、データの一貫性と正確性が保証されます。
注意してください end_parse()は、データスライスが空かどうかを確認するために使用されます。スライスが空でない場合、関数は例外をスローします。これにより、データの形式と内容が期待どおりになります。もしend_parse()function detects remaining data in the slice, it may indicate that the data parsing did not proceed as intended or that there is an issue with the data format. Therefore, by calling end_parse()では、解析プロセス中に欠落や異常がないかどうかを確認できます。
(3) データストレージおよびタイプの不一致による例外
これは主にのマッチングに関係していますintそしてuintストレージタイプ。例えば、以下のコードでは、store_int()関数は保存するために使用されますint value of -42、しかしload_uint()この値を読み込むために使用され、例外が発生する可能性があります。
(4) 正しい使用方法inline_refそしてインライン修飾子
まず、以下の点を区別することが重要です。インラインそしてinline_ref修飾子：
インライン: 関数と共にインラインmodifierは、呼び出されるたびにそのコードが直接呼び出し元に挿入されます。これにより、関数の実際のコードが関数ジャンプを介して実行されるのではなく、呼び出し位置にコピーされるため、関数呼び出しのオーバーヘッドは減少しますが、コードの重複が発生する可能性があります。
inline_ref: 関数とともにinline_ref修飾子は、コードを別のセルに格納します。関数が呼び出されるたびに、TVM はCALLREFコマンドは、コードの重複を避け、より複雑な機能や複数回呼び出される機能の効率を向上させることができます。
要約すると、インライン簡単な機能を呼び出しオーバーヘッドを減らすために使用しますが、潜在的なコードの重複に注意してください。inline_ref効率を改善し、コードの繰り返しを避けるために、大きなまたは頻繁に呼び出される関数に使用されます。
(5) 正しいワークチェーンの決定
TONでは、最大2^32のワークチェーンが作成可能で、それぞれがさらに最大2^60のシャードに細分化できます。最初は2つのワークチェーン、マスターチェーン（-1）とベースチェーン（0）があります。契約でターゲットアドレスを計算する際には、正しいワークチェーンIDを指定することが重要で、生成されるウォレットアドレスが正しいワークチェーン上にあることを確認する必要があります。誤ったアドレスを生成することを避けるためには、force_chain()チェーンIDを明示的に指定する。
(6) エラーコードの競合を回避する
エラーコードの効果的な管理は、一貫性を確保し混乱を避けるために、契約の設計において重要です。TONスマートコントラクトの場合、各エラーコードが契約内で一意であることを確認し、競合や曖昧なエラーメッセージを防止してください。さらに、TONプラットフォームまたは基礎システムで定義された標準エラーコードとの競合を避けてください。例えば、エラーコード333はチェーンIDの不一致を示します。このような競合を防ぐために、エラーコード400から1000の間を使用することをお勧めします。
(7) データの保存と呼び出しreturn()を操作完了後
TONのスマートコントラクトでは、メッセージの処理はオペコードに基づいて異なるロジックを選択することを含んでいます。対応するロジックを完了した後、2つの追加のステップが必要です: まず、データが変更された場合、呼び出します。save_data()変更が保存されるようにするために、それ以外の場合は変更が無効になります。2番目に、呼び出します。return()を操作が完了したことを示すために; それ以外の場合は、throw(0xffff)例外が発生します。
() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {
int flags = cs〜load_uint(4);
if (flags & 1) {
すべてのバウンドメッセージを無視する
return ();
}
sender_address = cs~load_msg_addr();
load_data();
int op = in_msg_body~load_op();
if ((op == op::op_1())) {
handle_op1();
save_data();
return ();
}
if ((op == op::op_2())) {
handle_op2();
save_data();
戻り値();
}
if ((op == op::op_3())) {
handle_op3();
save_data();
return ();
}
throw(0xffff);
}
まとめると、革新的なアーキテクチャと柔軟な開発環境を備えたTONブロックチェーンは、分散型アプリケーション開発者にとって理想的なプラットフォームになりつつあります。ただし、スマートコントラクトがTONエコシステムでますます重要な役割を果たす中、セキュリティの問題は見逃すことができません。開発者はTONエコシステムの特徴を深く理解し、厳格にベストプラクティスを遵守し、セキュリティ監査プロセスを強化して契約の堅牢性とセキュリティを確保する必要があります。これによってTONプラットフォームの利点を十分に活かし、より安全で信頼性の高い分散型アプリケーションを構築し、全体のエコシステムの健全な発展を守ることができます。
TONエコシステムは現在急速な成長を遂げており、多額の資金と活発なユーザーを惹きつけています。しかし、付随するセキュリティの問題は無視できません。TONエコシステムのセキュリティと信頼性を確保するために、BeosinはTONスマートコントラクトの呼び出しと操作の特性に合わせた包括的で専門的なセキュリティ監査を提供し、エコシステムの開発をサポートしています。
BeosinはTONエコシステム内で多数の成功事例を持っています。以前、Beosinは主要な分散型ステーブルコインプロジェクトAqua ProtocolとDeFiインフラONTON Financeの徹底的なセキュリティ監査を実施しました。監査は、スマートコントラクトコードのセキュリティ、ビジネスロジック実装の正確性、コントラクトコードのガス最適化、潜在的な脆弱性の検出と対処など、複数の側面をカバーしました。
声明：
この記事は[から転載されましたBeosin], オリジナルのタイトル「Beosinハードコアリサーチ | リスクから保護へ：TONスマートコントラクトのセキュリティリスクと最適化提案」という原著作権は原作者に帰属します [Beosin転載に異議がある場合は、Gate Learn チーム、チームは関連する手順に従ってできるだけ早く処理します。
免責事項:この記事で表明された見解や意見は、著者の個人的な見解を表しているにすぎず、投資アドバイスを構成するものではありません。
その他の言語版の記事はGate Learnチームによって翻訳され、そのことは言及されていませんGate、翻訳された記事の複製、配布、または盗用はできません。
関連記事
ETHを賭ける方法は?
ステーブルコインとは何ですか？
リスクから保護へ：TONスマートコントラクトのセキュリティリスクと最適化提案
ブロックチェーン技術の急速な進化の中で、TON（The Open Network）は効率的で柔軟なブロックチェーンプラットフォームとして開発者の間でますます注目されています。TONのユニークなアーキテクチャと機能は、分散型アプリケーションの開発に強力なツールと豊富な可能性を提供しています。
しかし、機能と複雑さの増加に伴い、スマートコントラクトのセキュリティはますます重要になっています。TON上のスマートコントラクトプログラミング言語であるFunCは、その柔軟性と効率性で知られていますが、多くの潜在的なリスクと課題も抱えています。安全で信頼性の高いスマートコントラクトを作成するには、開発者がFunCの特性と関連する潜在的なリスクについて深い理解を持っていることが求められます。
この記事では、TONブロックチェーン上のスマートコントラクト関連機能について詳細な分析を提供し、しばしば見落とされがちなTONスマートコントラクトの脆弱性についても説明します。
TONの非同期機能とアカウントメカニズムの分析
スマートコントラクトでの非同期呼び出し
ネットワーク・シャーディングと非同期通信
TONブロックチェーンは、マスターチェーン、ワーキングチェーン、およびシャードチェーンの3種類のチェーンで設計されています。
マスターチェーンはネットワーク全体のコアであり、ネットワーク全体のメタデータとコンセンサスメカニズムを保存する役割を担っています。すべてのワーキングチェーンとシャードチェーンの状態を記録し、ネットワークの一貫性とセキュリティを確保します。ワーキングチェーンは独立したブロックチェーンで、最大2^32チェーンで、特定の種類のトランザクションとスマートコントラクトの処理を担当します。各ワーキングチェーンは、さまざまなアプリケーションのニーズを満たすために、独自のルールと機能を持つことができます。シャードチェーンはワーキングチェーンのサブチェーンであり、ワーキングチェーンのワークロードをさらに分割し、処理能力とスケーラビリティを強化するために使用されます。各ワーキングチェーンは最大2^60個のシャードチェーンに分割でき、シャードチェーンは一部のトランザクションを個別に処理して効率的な並列処理を実現します。
理論上、各アカウントは個別にShardchainを占有し、各アカウントは独立してCOIN/TOKEN残高を維持します。アカウント間の取引は完全に並列化されることができます。アカウントは非同期メッセージを介して通信し、Shardchain間を移動するメッセージの経路はlog_16(N) - 1であり、ここでNはShardchainの数です。
画像ソース：https://frontierlabzh.medium.com/TON-Weixin-e1d3ae3b3574Web3の世界では、Tonでは、やり取りはメッセージの送受信によって行われます。これらのメッセージは内部的なもの（通常は互いに相互作用するスマートコントラクトによって送信される）または外部的なもの（外部のソースから送信される）である場合があります。メッセージパッシングプロセスは、ターゲットコントラクトからの即時の応答を必要としないため、送信者は残りのロジックの実行を続けることができます。この非同期メッセージングメカニズムは、Ethereumの同期呼び出しに比べて、柔軟性とスケーラビリティを提供し、応答を待つためのパフォーマンスボトルネックを減らす一方、同時性と競合状態の処理に関する課題をもたらします。
メッセージの形式と構造
TONでは、メッセージには通常、送信者、受信者、金額、およびメッセージ本文などの情報が含まれています。メッセージ本文には、関数呼び出し、データ転送、またはその他のカスタムコンテンツが含まれることがあります。TONのメッセージ形式は柔軟かつ拡張可能に設計されており、異なる契約間でさまざまなタイプの情報を効率的に伝達することができます。
メッセージキューとステータス処理
各契約は、まだ処理されていないメッセージを格納するメッセージキューを保持します。実行中、契約はキューから一つずつメッセージを処理します。メッセージの処理は非同期で行われるため、メッセージを受信しても契約の状態はすぐに更新されません。
非同期メッセージングの利点
•効率的なシャーディングメカニズム：TONの非同期メカニズムは、シャーディング設計と非常に互換性があります。各シャードは契約メッセージと状態の変更を独立して処理し、クロスシャード同期による遅延を回避します。この設計により、全体のネットワークスループットとスケーラビリティが向上します。
•リソース消費の削減：非同期メッセージは即座の応答を必要とせず、TON契約が複数のブロックをまたいで実行され、単一のブロック内での過剰なリソース消費を回避します。これにより、TONはより複雑でリソース集約型のスマートコントラクトをサポートできます。
•フォールトトレランスと信頼性：非同期メッセージパッシングメカニズムにより、システムのフォールトトレランスが向上します。たとえば、リソースの制約や他の理由により契約がタイムリーにメッセージに応答できない場合、送信者は他のロジックの処理を続けることができ、単一の契約による遅延によるシステムの停止を防ぐことができます。
非同期契約設計の課題
•状態の整合性問題：メッセージの送受信が非同期であるため、契約は異なる時刻に異なるメッセージを受信する可能性があります。これにより、開発者は状態の整合性に特別な注意を払う必要があります。契約を設計する際には、異なるメッセージの順序が状態の変化にどのように影響するかを考慮し、システムがすべての条件下で整合性を維持することを確認することが重要です。
•レース条件と保護：非同期メッセージ処理によって、複数のメッセージが同時に契約状態を変更しようとする潜在的な競合状態の問題が発生する可能性があります。開発者は適切なロックメカニズムを実装するか、トランザクション操作を使用して状態の競合を防止する必要があります。
•セキュリティに関する考慮事項：非同期の契約は、クロス契約通信の処理時に中間者攻撃やリプレイ攻撃などのリスクにさらされる可能性があります。したがって、非同期の契約を設計する際には、これらの潜在的なセキュリティリスクに対処し、タイムスタンプ、ランダムな数字、またはマルチサインアプローチなどの予防策を取ることが重要です。
レジャーモデル
TON(The Open Network)は、ブロックチェーンインフラストラクチャの設計において、独自のアカウント抽象化および台帳モデルを採用しています。このモデルの柔軟性は、アカウントの状態、メッセージの受け渡し、コントラクトの実行を管理する方法に反映されています。
アカウント抽象化
TONのアカウントモデルは、契約ベースの抽象化を使用しており、各アカウントは契約と見なすことができます。これは、Ethereumのアカウント抽象化モデルにやや似ていますが、より柔軟で一般的です。TONでは、アカウントは単なる資産のコンテナに過ぎません。また、契約コードと状態データも含まれます。各アカウントには、コード、データ、メッセージ処理ロジックが含まれています。
アカウント構造：すべてのTONアカウントには固有のアドレスがあり、このアドレスはアカウントコードのハッシュ値、展開時の初期データ、その他のパラメータの組み合わせから生成されます。つまり、異なる環境（たとえば、異なるブロックチェーンやシャード）で展開された同じコードと初期データは異なるアドレスを生成する可能性があります。
柔軟性：各アカウントが独自のコントラクトコードを実行できるため、TONアカウントは非常に複雑なロジックを実装できます。アカウントは単なる残高保持者ではなく、複雑な状態遷移、アカウント間のメッセージ通信、特定の条件に基づく自動化さえも処理できます。これにより、TONのアカウントモデルは従来のブロックチェーンのアカウントモデルに比べてスケーラブルで柔軟性が高くなります。
レジャー構造
TONの台帳構造は、大規模な並行トランザクションを効率的に処理し、非同期メッセージパッシングとマルチシャード操作をサポートするように設計されています。各アカウントの状態は、メルクルツリー構造に格納されており、効率的な状態検証機能を提供しています。
状態ストレージ
アカウントの状態情報は永続的なストレージに保存され、Merkleツリーを介して整合性とセキュリティが確保されています。この設計では、特にクロスシャードトランザクションにおける状態の効率的なクエリと検証をサポートしています。
アカウントまたはスマートコントラクトの状態には通常、次のものが含まれます。
- 基本通貨の残高 2. 他の通貨の残高 3. スマートコントラクトコード（またはそのハッシュ） 4. スマートコントラクトの永続データ（またはそのMerkleハッシュ） 5. 永続ストレージユニット数と生のバイト使用量に関する統計 6. スマートコントラクトの永続ストレージへの最近の支払いのタイムスタンプ（基本的にはメインチェーンのブロック番号） 7. このアカウントから通貨を送金し、メッセージを送信するために必要な公開鍵（任意; デフォルトでは、これはaccount_id自体と同じです）。場合によっては、ビットコイン取引のアウトプットのように、より複雑な署名チェックコードがここに見つかる場合があります。そのような場合、account_idはこのコードのハッシュになります。
すべてのアカウントにはすべての情報が必要ではありません。たとえば、スマートコントラクトのコードはスマートコントラクトにのみ関連しており、「簡単な」アカウントには関連していません。さらに、すべてのアカウントにはベース通貨（例えば、基本の作業チェーンとシャードチェーン用のグラム）のノンゼロの残高が必要ですが、他の通貨の残高はゼロでも構いません。未使用のデータを保持しないために、作業チェーンの作成時には、さまざまな「コンストラクタ関数」を識別するために、異なるマーキングバイトを使用してサムプロダクトタイプが定義されます。最終的に、アカウントの状態は、TVMの永続ストレージ内のユニットのコレクションとして保存されます。
メッセージパッシングと処理
TONのレジャーストラクチャには、非同期メッセージパッシングの組み込みサポートが含まれています。各アカウントは受信したメッセージを独立して処理し、状態を更新することができます。この非同期メッセージングメカニズムにより、他のアカウントの通常の動作に影響を与えることなく、アカウント間で複雑な相互作用が可能となります。
ガスモデル
TON（The Open Network）は、独自のガス料金モデルを通じてスマートコントラクトの実行効率を大幅に最適化しています。このガス料金モデルは、スマートコントラクトの実行中に消費されるリソースを測定および制限するために使用されます。従来のEthereumなどのブロックチェーンと比較して、TONのモデルはより複雑で効率的であり、契約の実行中のリソース消費をより正確に管理できます。
TONのガスモデルは、スマートコントラクトの実行中に消費される計算リソース、ストレージ操作、およびメッセージパッシングのコストを正確に測定できます。計算、ストレージ、メッセージングなどのリソースに対する詳細な測定値を提供することで、TONのガスモデルは、複雑さが過度に高い操作が多くのリソースを消費するのを防ぎます。ガス消費を制限することで、TONは各ネットワークノードが計算リソースを公平に割り当てることを確実にし、単一の契約または操作によるネットワークリソースの過度な使用を回避します。
TONはスマートコントラクトの並列処理をサポートしており、複数のコントラクトが異なるシャード上で同時に実行され、お互いをブロックすることなく動作します。この設計では、ガスモデルは並列実行とシャーディングメカニズムと密接に統合されています。複数のシャードをまたいでコントラクトを並列処理することにより、TONはガスの計算と支払いを異なるノードやチェーンに分散させ、ネットワークの混雑を回避しながらリソースの利用を最大化することができます。
TONのガスモデルには、ネットワークのリアルタイム負荷に基づいてガス料金を調整する動的調整メカニズムが含まれています。つまり、ネットワーク負荷が低い時期には、ユーザーは低いガス料金で契約を実行できるため、オフピーク時に操作を促進し、ネットワークリソースの使用をバランスさせることができます。このメカニズムは、ユーザーエクスペリエンスを向上させるだけでなく、市場主導のアプローチを通じてピーク時のリソース使用を制御します。
大量のスマートコントラクトは、無視しやすい抜け穴です
In 私たちの以前のセキュリティ分析記事TONについて、TONエコシステム内の一般的なセキュリティ脆弱性について詳細に説明しています。詳細は以下の表を参照してください。
この記事では、私たちのチームによってまとめられた、しばしば見落とされがちなTON契約の脆弱性に焦点を当てます。
(1) コードの可読性の最適化
TONスマートコントラクトでは、メッセージ送信に関連するデータを格納するために数値がよく使用されます。たとえば、次のコードでは、対応する識別子とデータストレージの長さを表すために数値の複数のインスタンスが使用されているため、コードの可読性と保守性が大幅に低下します。他の開発者は、コードを読むときにこれらの数値の意味と目的を理解するのが難しいと感じるかもしれません。可読性と保守性を向上させるために、キーの数値を名前付き定数として定義することをお勧めします。たとえば、0x18asNON_BOUNCEABLE.
check_std_addr(address);was msg = begin_cell() store_uint(0x18, 6) ;; nobounce store_slice(address) store_coins(amount) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(msg, 1);
さらに、契約判定条件のエラーメッセージについては、エラーコードを置き換えるために対応する変数を定義することもお勧めです。
(2) 使用するend_parse()データの整合性を確保するために
TONコントラクトでは、データ解析は固定された順序に従い、生データから指定されたタイプのデータを段階的にロードします。この解析方法では、次に示すように、データの一貫性と正確性が保証されます。
注意してください end_parse()は、データスライスが空かどうかを確認するために使用されます。スライスが空でない場合、関数は例外をスローします。これにより、データの形式と内容が期待どおりになります。もしend_parse()function detects remaining data in the slice, it may indicate that the data parsing did not proceed as intended or that there is an issue with the data format. Therefore, by calling end_parse()では、解析プロセス中に欠落や異常がないかどうかを確認できます。
(3) データストレージおよびタイプの不一致による例外
これは主にのマッチングに関係していますintそしてuintストレージタイプ。例えば、以下のコードでは、store_int()関数は保存するために使用されますint value of -42、しかしload_uint()この値を読み込むために使用され、例外が発生する可能性があります。
(4) 正しい使用方法inline_refそしてインライン修飾子
まず、以下の点を区別することが重要です。インラインそしてinline_ref修飾子：
インライン: 関数と共にインラインmodifierは、呼び出されるたびにそのコードが直接呼び出し元に挿入されます。これにより、関数の実際のコードが関数ジャンプを介して実行されるのではなく、呼び出し位置にコピーされるため、関数呼び出しのオーバーヘッドは減少しますが、コードの重複が発生する可能性があります。
inline_ref: 関数とともにinline_ref修飾子は、コードを別のセルに格納します。関数が呼び出されるたびに、TVM はCALLREFコマンドは、コードの重複を避け、より複雑な機能や複数回呼び出される機能の効率を向上させることができます。
要約すると、インライン簡単な機能を呼び出しオーバーヘッドを減らすために使用しますが、潜在的なコードの重複に注意してください。inline_ref効率を改善し、コードの繰り返しを避けるために、大きなまたは頻繁に呼び出される関数に使用されます。
(5) 正しいワークチェーンの決定
TONでは、最大2^32のワークチェーンが作成可能で、それぞれがさらに最大2^60のシャードに細分化できます。最初は2つのワークチェーン、マスターチェーン（-1）とベースチェーン（0）があります。契約でターゲットアドレスを計算する際には、正しいワークチェーンIDを指定することが重要で、生成されるウォレットアドレスが正しいワークチェーン上にあることを確認する必要があります。誤ったアドレスを生成することを避けるためには、force_chain()チェーンIDを明示的に指定する。
(6) エラーコードの競合を回避する
エラーコードの効果的な管理は、一貫性を確保し混乱を避けるために、契約の設計において重要です。TONスマートコントラクトの場合、各エラーコードが契約内で一意であることを確認し、競合や曖昧なエラーメッセージを防止してください。さらに、TONプラットフォームまたは基礎システムで定義された標準エラーコードとの競合を避けてください。例えば、エラーコード333はチェーンIDの不一致を示します。このような競合を防ぐために、エラーコード400から1000の間を使用することをお勧めします。
(7) データの保存と呼び出しreturn()を操作完了後
TONのスマートコントラクトでは、メッセージの処理はオペコードに基づいて異なるロジックを選択することを含んでいます。対応するロジックを完了した後、2つの追加のステップが必要です: まず、データが変更された場合、呼び出します。save_data()変更が保存されるようにするために、それ以外の場合は変更が無効になります。2番目に、呼び出します。return()を操作が完了したことを示すために; それ以外の場合は、throw(0xffff)例外が発生します。
() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {
int flags = cs〜load_uint(4);
if (flags & 1) {
すべてのバウンドメッセージを無視する
return ();
}
sender_address = cs~load_msg_addr();
load_data();
int op = in_msg_body~load_op();
if ((op == op::op_1())) {
handle_op1();
save_data();
return ();
}
if ((op == op::op_2())) {
handle_op2();
save_data();
戻り値();
}
if ((op == op::op_3())) {
handle_op3();
save_data();
return ();
}
throw(0xffff);
}
まとめると、革新的なアーキテクチャと柔軟な開発環境を備えたTONブロックチェーンは、分散型アプリケーション開発者にとって理想的なプラットフォームになりつつあります。ただし、スマートコントラクトがTONエコシステムでますます重要な役割を果たす中、セキュリティの問題は見逃すことができません。開発者はTONエコシステムの特徴を深く理解し、厳格にベストプラクティスを遵守し、セキュリティ監査プロセスを強化して契約の堅牢性とセキュリティを確保する必要があります。これによってTONプラットフォームの利点を十分に活かし、より安全で信頼性の高い分散型アプリケーションを構築し、全体のエコシステムの健全な発展を守ることができます。
TONエコシステムは現在急速な成長を遂げており、多額の資金と活発なユーザーを惹きつけています。しかし、付随するセキュリティの問題は無視できません。TONエコシステムのセキュリティと信頼性を確保するために、BeosinはTONスマートコントラクトの呼び出しと操作の特性に合わせた包括的で専門的なセキュリティ監査を提供し、エコシステムの開発をサポートしています。
BeosinはTONエコシステム内で多数の成功事例を持っています。以前、Beosinは主要な分散型ステーブルコインプロジェクトAqua ProtocolとDeFiインフラONTON Financeの徹底的なセキュリティ監査を実施しました。監査は、スマートコントラクトコードのセキュリティ、ビジネスロジック実装の正確性、コントラクトコードのガス最適化、潜在的な脆弱性の検出と対処など、複数の側面をカバーしました。
声明：
この記事は[から転載されましたBeosin], オリジナルのタイトル「Beosinハードコアリサーチ | リスクから保護へ：TONスマートコントラクトのセキュリティリスクと最適化提案」という原著作権は原作者に帰属します [Beosin転載に異議がある場合は、Gate Learn チーム、チームは関連する手順に従ってできるだけ早く処理します。
免責事項:この記事で表明された見解や意見は、著者の個人的な見解を表しているにすぎず、投資アドバイスを構成するものではありません。
その他の言語版の記事はGate Learnチームによって翻訳され、そのことは言及されていませんGate、翻訳された記事の複製、配布、または盗用はできません。
関連記事
ETHを賭ける方法は?
ステーブルコインとは何ですか？