出典:Beosin
ブロックチェーン技術の急速な発展において、TON(The Open Network)は非常に効率的で柔軟なブロックチェーンプラットフォームとして、開発者からますます注目を集めています。
TONのユニークなアーキテクチャと機能は、分散型アプリケーション開発に強力なツールと豊富な可能性を提供します。
TONのユニークなアーキテクチャと機能は、分散型アプリケーション開発のための強力なツールと豊かな可能性を提供します。
しかし、機能と複雑さが増すにつれて、スマートコントラクトのセキュリティはますます重要になっています。 TONのスマートコントラクトプログラミング言語であるFunCは、その柔軟性と効率性で知られていますが、同時に多くの潜在的なリスクと課題ももたらします。安全で信頼できるスマートコントラクトを書くには、開発者がFunC言語の特徴と起こりうるリスクを深く理解する必要があります。
この記事では、TONブロックチェーン上のスマートコントラクトに関連する機能の一部と、見落としがちなTON上のスマートコントラクトの脆弱性について詳しく分析します。
TON の非同期機能とアカウントメカニズムの分析
スマートコントラクトの非同期呼び出し
Tonブロックチェーンは、マスターチェーン、ワーキングチェーン、シャードチェーンの3種類のチェーンに分けられるように設計されています。
マスターチェーンはネットワーク全体の中核であり、ネットワーク全体のメタデータとコンセンサスメカニズムを保存する役割を担っています。すべてのワーキングチェーンとシャードチェーンの状態を記録し、ネットワーク全体の一貫性とセキュリティを保証します。ワーキングチェーンは最大2^32のエントリーを持つ独立したブロックチェーンで、特定の種類の取引やスマートコントラクトの処理を担当する。各ワーキングチェーンは、異なるアプリケーション要件を満たすために独自のルールと機能を持つことができる。スプリットチェーンはワーキングチェーンのサブチェーンであり、処理能力とスケーラビリティを向上させるためにワーキングチェーンの負荷をさらに分割するために使用される。各ワーキングチェーンは最大2^60のシャードチェーンに分割され、シャードチェーンはいくつかのトランザクションを独立して処理し、効率的な並列処理を実現します。
理論的には、各アカウントはシャードチェーンを占有することができ、各アカウントはそれ自身のCOIN/TOKEN残高を独立して維持し、各アカウント間のトランザクションは完全に並列化することができます。アカウントは非同期メッセージで渡され、シャードチェーン間のメッセージのパスはlog_16(N) - 1です。
図の出典:https://frontierlabzh.medium.com/ton-web3world-weixin-e1d3ae3b3574
Tonでは、スマートコントラクトはメッセージを送受信することで相互作用します。これらのメッセージは、内部(一般的にスマートコントラクトが相互にやり取りすることで送信されるメッセージ)または外部(外部ソースから送信されるメッセージ)になります。メッセージ配信プロセスは、ターゲットコントラクトからの即時応答を待つ必要はなく、送信者は残りのロジックコードの実行を続けることができます。この非同期メッセージングメカニズムは、イーサネットの同期呼び出しと比較して、より大きな柔軟性とスケーラビリティを提供し、応答待ちによるパフォーマンスのボトルネックを軽減します。
メッセージのフォーマットと構造
Tonでは、メッセージは通常、送信者、受信者、量、メッセージ本体などの情報を含んでいます。
Tonで使用されるメッセージフォーマットは、柔軟に定義および拡張することができ、異なるコントラクト間でさまざまなタイプの情報を効率的に転送することができます。
Tonで使用されるメッセージフォーマットは、柔軟に定義・拡張することができます。メッセージキューとステートハンドリング
各コントラクトは、まだ処理されていないメッセージを格納するメッセージキューを維持します。コントラクトは、キュー内のメッセージに基づいて、実行中に1つずつ処理されます。メッセージ処理は非同期なので、メッセージが受信されるまでコントラクトの状態はすぐには更新されません。
非同期メッセージングの利点
効率的なスライシングメカニズム:Tonの非同期メカニズムは、スライシング設計と高い互換性があります。各スライスはコントラクトメッセージと状態変更を独立して処理し、スライス間の同期通信に関連するレイテンシの問題を回避します。この設計により、ネットワーク全体のスループットとスケーラビリティが向上します。
リソース消費の削減: 非同期メッセージは即時応答を必要としないため、Tonのコントラクト実行は複数のブロックにまたがることができ、単一ブロック内での過剰なリソース消費を避けることができます。これにより、Tonはより複雑でリソース集約的なスマートコントラクトをサポートすることができます。
-フォールトトレランスと信頼性:非同期メッセージングにより、システムのフォールトトレランスが向上します。例えば、あるコントラクトがリソースの制約やその他の理由でタイムリーにメッセージに応答できない場合でも、送信者は他のロジックで作業を続けることができ、個々のコントラクトの遅延によってシステムが停止することはありません。
非同期コントラクト設計における課題
状態の一貫性の問題: メッセージングが非同期であるため、コントラクトの状態は、異なる瞬間に異なるメッセージを受け取る可能性があります。コントラクトを設計するときは、異なるメッセージシーケンスによって引き起こされる可能性のある状態変化を考慮に入れて、システムがあらゆる状況下で一貫性を保つようにすることが重要です。
競合状態とガード: 非同期メッセージ処理では、複数のメッセージが同時にコントラクトの状態を変更しようとする競合状態の潜在的な問題が発生します。開発者は、状態の競合を防ぐために、適切なロック機構を導入するか、トランザクション操作を使用する必要があります。
-セキュリティの考慮:非同期コントラクトは、コントラクト間の通信を処理する際に、中間者攻撃(man-in-the-middle)やリプレイ攻撃(replay attack)の影響を受けやすくなります。そのため、非同期コントラクトを設計する際には、これらの潜在的なセキュリティリスクを考慮し、タイムスタンプ、乱数、複数の署名の使用など、これらの発生を防ぐ対策を講じることが重要です。
台帳モデル
Ton(オープンネットワーク)は、ブロックチェーンインフラストラクチャを設計する際に、独自のアカウント抽象化と台帳モデルを使用しています。このモデルの柔軟性は、アカウントの状態、メッセージング、契約の実行を処理する方法に反映されています。
アカウントの抽象化
Tonのアカウントモデルは、各アカウントをコントラクトとみなすことができるコントラクトベースの抽象化を採用しており、Etherのアカウント抽象化モデルと類似点がありますが、より柔軟で汎用的です。Tonでは、アカウントはアセットを保持する単なるコンテナではなく、コントラクトコードとステートデータも含んでいます。各アカウントはコード、データ、メッセージ処理ロジックで構成されています。
アカウント構造: 各Tonアカウントは一意のアドレスを持っており、これはアカウントのCodeのハッシュ、デプロイ時の初期データ、その他多くのパラメータの組み合わせです。これは、異なる環境(異なるブロックチェーンやシャードなど)でデプロイされた同じコードと初期データが、異なるアドレスを生成する可能性があることを意味します。
柔軟性:各アカウントは独自のコントラクトコードを実行できるため、Tonのアカウントは非常に複雑なロジックを実装できます。単純な残高保持者以上に、アカウントは複雑な状態転送、アカウント間のメッセージ通信、さらには特定の条件に基づく自動化された操作を扱うことができます。これにより、Tonのアカウントモデルは、従来のブロックチェーン上のアカウントよりもはるかにスケーラブルで柔軟なものとなっている。
台帳アーキテクチャ
Tonの台帳アーキテクチャは、大量の同時トランザクションを効率的に処理するように設計されており、非同期メッセージングやマルチスライス操作をサポートしています。各アカウントの状態はMerkleツリー構造に保存され、Tonの元帳に効率的な状態検証機能を与えています。
状態の保存
アカウントの状態情報は永続的なストレージに保存され、状態の整合性とセキュリティを確保するためにMerkleツリーで整理されます。この設計はまた、特にクロススプリットトランザクションのシナリオにおいて、状態の効率的なクエリと検証をサポートします。
アカウントまたはスマートコントラクトの状態には、一般的に以下が含まれます。
1.基本通貨の残高
2.他の通貨の残高
3.スマートコントラクトのコード(またはそのハッシュ)
4.スマートコントラクトの永続的なデータ(またはそのMerkleハッシュ)
5.永続的なストレージのユニット数に関する統計と、その数
6.スマートコントラクトの永続的なデータ(またはそのMerkleハッシュ)
7.使用された未加工バイト数に関する統計
6.スマートコントラクトによって永続化された支払いの最新時刻(実際にはメインチェーンのブロック番号)
7.通貨を送金し、このアカウントからメッセージを送信するために必要な公開鍵(オプション。)場合によっては、Bitcoin Transaction Outputが行うのと同様に、より複雑な署名チェックコードをここで見つけることができます。
この情報のすべてがすべてのアカウントに必要なわけではありません。例えば、スマートコントラクトコードはスマートコントラクトにのみ適用され、「単純な」アカウントには適用されません。さらに、どのアカウントも主要通貨(例えば、基本的な作業チェーンのメインチェーンとシャードチェーンのグラム)の残高がゼロでない必要がありますが、他の通貨は残高がゼロでもかまいません。未使用データの保持を避けるため、ワーキングチェーンの作成時に、異なる「十分な機能」を区別するために異なるタグ付きバイトを使用する、合計積型が定義されます。最終的に、アカウントの状態自体は、TVM永続ストアにユニットのコレクションとして保存されます。
メッセージングと処理
Tonの台帳構造には、非同期メッセージングのサポートが組み込まれています。この非同期メッセージングメカニズムにより、1つの操作の遅延が他のアカウントの通常操作に影響を与えることなく、アカウント間の複雑な相互作用が可能になります。
Gasモデル
Ton(オープンネットワーク)ブロックチェーンは、スマートコントラクトの実行によって消費されるリソースの量を測定し制限するためにブロックチェーンで使用される独自のGas手数料モデルを通じて、スマートコントラクトの実行効率を劇的に最適化します。Tonのモデルは、イーサなどの従来のブロックチェーンのGasモデルよりも洗練され効率的に設計されており、契約実行中のリソース消費をより正確に管理することができます。
洗練されたガス消費測定
TonのGasモデルは、実行中にスマートコントラクトが消費する計算リソース、ストレージ操作、メッセージングコストを正確に測定します。計算、ストレージ、メッセージングリソースのきめ細かい測定により、TonのGasモデルは、過度に複雑な特定のオペレーションが多くのリソースを消費するのを防ぎます。Gasの消費を制限することで、Tonはネットワーク内の各ノードがコンピューティングリソースを公平に共有することを保証し、単一のコントラクトや操作によるネットワークリソースの過剰消費を回避します。
並列処理とGasの最適化
Tonはスマートコントラクトの並列処理をサポートしており、複数のコントラクトを互いにブロックすることなく、異なるシャード上で同時に実行することができます。この設計では、Gasモデルは並列実行およびシャーディングメカニズムと緊密に結合しています。 複数のシャード上でコントラクトを並列処理することで、TonはGasの計算と支払いを異なるノードやチェーンに分散させ、リソースの利用を最大化しながらネットワークの混雑を避けることができます。
ダイナミックなGas調整メカニズム
TonのGasモデルには、リアルタイムのネットワーク負荷に基づいてGas料金を調整できるダイナミックな調整メカニズムが含まれています。つまり、ネットワークの負荷が低い場合、ユーザーはより低いガス料金で契約を実行できるため、負荷が低い時間帯の運用が促進され、ネットワークのリソース使用量のバランスが取れます。このメカニズムはユーザー体験を向上させるだけでなく、市場ベースのアプローチを通じてリソースのピーク使用量を制御します。
この記事では、私たちのチームによって要約された、TONのコントラクトで見落とされやすい脆弱性のポイントに焦点を当てます:
(1) コードの可読性の最適化
TONのスマートコントラクトでは、メッセージの保存に数字が使われます。例えば、以下のコードでは、対応するロゴとデータ保存の長さを示すために数字が何度も使われており、コードの可読性と保守性が大幅に低下しています。これはコードの可読性と保守性を低下させ、他の開発者がコードを読むときに、これらの数字の意味と使い方を理解するのは困難です。例えば、0x18 は NON_BOUNCEABLE として定義されています。nbsp; store_uint(0x18, 6) ;; nobounce store_slice(アドレス) store_coins(金額) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(msg, 1);
なお、エラーメッセージの契約判定条件においても、同様にエラーコードに代わる対応する変数を定義することを推奨します。
(2)end_parse()を使用してデータの整合性を確保する
TON契約では、データの解析は一定の順序に従い、生データから指定されたタイプのデータを徐々に読み込みます。この構文解析により、データの一貫性と正確性が保証されます。p>
ここでのend_parse()は、データスライス(slice)が空かどうかをチェックするために使用され、スライスが空でない場合、関数は例外を投げることに注意してください。これにより、データの形式と内容が期待通りであることが保証されます。end_parse() 関数がデータ・スライスにまだデータが残っていることを発見した場合、これはデータの解析が期待通りに進まなかったか、データの形式に問題があることを示している可能性があります。そのため、end_parse()を呼び出すことで、解析中のデータに抜けや異常がないかを確認することができます。
(3)データレコードと格納型の不一致による例外
ここで説明すべきは、int型とuint型のアクセス型の一致です。 以下のコードでは、int型の値を-42として格納するためにstore_int()を使ってデータを格納していますが、その値をロードするためにload_uint()を使っており、ここで例外が発生する可能性があります。例外が発生する可能性があります。
です。(4)inline_refとインライン修飾子の賢明な使用
まず第一に、inline_refとインライン修飾子の違いを明確にする必要があります。つまり、関数が呼び出されるたびに、通常の関数のように関数本体にジャンプして実行されるのではなく、関数の実際のコードが呼び出された場所にコピーされます。
linline_ref: inline_ref修飾子を使った関数は、そのコードが別のセルに格納されます。関数が呼び出されるたびに、TVMは呼び出し位置に関数コードを挿入するのではなく、CALLREFコマンドによってセルに格納されたコードを実行します。一方、inline_ref修飾子は、より複雑な関数や複数回呼び出される関数に適用され、関数コードを別のセルに格納することで効率を向上させ、コードの重複を回避します。
(5)正しい作業チェーンの決定
TONでは、最大2^32の作業チェーンを作成することができます。1)と基本チェーン(0)の2つしかない。コントラクトで宛先アドレスを計算する際、生成されるウォレットアドレスが正しいチェーン上にあることを保証するために、宛先アドレスが属するチェーンIDを明示的に指定する必要があります。誤ったアドレスの生成を避けるために、force_chain() force_chain() を使ってチェーンIDを指定することが推奨されます。
(6) エラーコードの競合を避ける
コントラクト設計におけるエラーコードの管理は、正常性を確保し混乱を避けるために非常に重要です。TONスマートコントラクトの場合、第一に、エラーコードに関する混乱や不明確な情報を防ぐため、各エラーコードがコントラクト内で一意であることを保証し、同じコントラクト内で重複したエラーコードを定義することを避けるべきです。第二に、TONプラットフォームまたは基礎となるシステムは、いくつかの標準エラーコードを定義しており、これらのシステムエラーコードとの衝突を避けるべきです。そのため、コントラクトのエラーコードは400から1000の間であることが望ましい。
(7)処理が完了したら、データを保存してreturn()を呼び出す
TONスマートコントラクトでは、メッセージ処理はオペコードに応じて異なるロジックを選択します。第一に、データの変更が含まれる場合、save_data()を呼び出してデータが保存されていることを確認する必要があります。
() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) impure {
int flags = cs~load_uint(4);
;; 全てのバウンスメッセージを無視する
return ();
}slice 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();
return ();
}
if ((op == op::op_3())) {
handle_op3();
save_data();
return ();
}
throw(0xffff);
}
要約すると、TONブロックチェーンは、その革新的なアーキテクチャと柔軟な開発環境のおかげで、分散型アプリケーション開発者にとって理想的なプラットフォームとなりつつあります。しかし、スマートコントラクトがTONエコシステムでますます重要な役割を果たすにつれて、コントラクトのセキュリティの問題を無視することはできません。開発者は、TONエコシステムの特性を理解し、厳格なベストプラクティスに従い、セキュリティ監査プロセスを強化して、コントラクトの堅牢性とセキュリティを確保する必要があります。このようにして初めて、TONプラットフォームの利点をフルに発揮し、より安全で信頼性の高い分散型アプリケーションを構築し、エコシステム全体の健全な発展を守ることができるのです。
TONのエコシステムは現在急速に発展しており、大量の資本とアクティブユーザーを引きつけています。しかし、それに伴うセキュリティ問題は無視できません。