はじめに:BinanceがTONエコシステムで最大のゲームであるNotcoinを発売し、その完全に循環するトークンエコノミーが巨大な富の効果を生み出した後、TONはすぐに多くの注目を集めました。友人と話していると、TONには高い技術的障壁があり、そのDApps開発モデルは主流のブロックチェーンプロトコルとは大きく異なることがわかりました。それで、私はこのトピックを深く調査するのに時間を費やし、あなたと共有するいくつかの洞察を持っています。ショートでは、TONのコア設計哲学は、相互運用性を犠牲にすることを意味するとしても、高い同時実行性とスケーラビリティを実現することに焦点を当てて、従来のブロックチェーンプロトコルをゼロから再構築することです。

TONの基本設計原則 - 高い同時実行性とスケーラビリティ

TONにおけるすべての複雑な技術選択の目的は、高い同時実行性と高いスケーラビリティの追求から来ていると言えます。もちろん、その誕生の背景から理解することは難しくありません。TON(オープンネットワーク)は、L1ブロックチェーンと複数のコンポーネントを含む分散型コンピューティングネットワークです。TONはもともとTelegramの創設者であるニコライ・ドゥーロフと彼のチームによって開発され、現在は独立した寄稿者のグローバルコミュニティによってサポートおよび維持されています。その誕生は2017年にさかのぼり、Telegramチームはブロックチェーンソリューションを模索し始めました。当時、既存のL1ブロックチェーンはTelegramの9桁のユーザーベースをサポートできなかったため、彼らは独自のブロックチェーンを設計することを決定し、当時はTelegram Open Networkと呼ばれていました。時は2018年。TONの実装に必要なリソースを入手するための注文として、Telegramは2018年の第1四半期にグラムトークン(後にToncoinに改名)の販売を開始しました。2020年、Telegramチームは規制上の問題によりTONプロジェクトから撤退しました。その後、オープンソース開発者とTelegramコンペティションの受賞者の小グループがTONのコードベースを引き継ぎ、プロジェクトの名前をオープンネットワークに変更し、元のTONホワイトペーパーで概説されている原則に従って、今日までブロックチェーンを積極的に開発し続けています。

TONはTelegramの分散型実行環境として設計されているため、同時リクエスト数が多いことと大量のデータという2つの主要な課題に対処する必要がありました。最速を謳うソラナの最高テストTPS(1秒あたりのトランザクション数)でさえ、わずか65,000件に過ぎず、Telegramに必要な100万レベルのTPSには遠くショート及ばない。さらに、Telegramによって生成される膨大な量のデータは、すべてのノードがデータの完全なコピーを保存するブロックチェーンでは管理できません。

これらの課題に取り組むために、TONは2つの方法で主流のブロックチェーンプロトコルを最適化しました。

l 「無限シャーディングパラダイム」を使用してデータの冗長性を減らし、大量のデータを処理し、パフォーマンスのボトルネックを軽減できるようにします。

l アクターモデルに基づく完全並列実行環境を導入することにより、ネットワークTPSが大幅に改善されます。

チェーンのブロックチェーンの構築 - 無限のシャーディングを通じて各アカウントに独自の専用チェーンを提供する

現在、シャーディングはパフォーマンスを向上させ、コストを削減するためのほとんどのブロックチェーンプロトコルの主流のソリューションになっていることがわかっており、TONこれを極端に進めて、無限シャーディングパラダイム、いわゆる無限シャーディングパラダイムを提案しました。 ブロックチェーンがネットワークの負荷に基づいてシャードの数を動的に増減できるようにすることを指します。このパラダイムにより、TONは高いパフォーマンスを維持しながら、大規模なトランザクションとスマートコントラクトの操作を処理できます。理論的には、TONはアカウントごとに排他的なアカウントチェーンを確立し、特定のルールを通じてこれらのチェーン間の相互運用性を確保できます。一貫性

本質的に、TONのチェーン構造は4つの層で構成されています

AccountChain: このレイヤーは、特定のアカウントにリンクされた一連のトランザクションを表します。トランザクションがチェーンを形成するのは、ステートマシンでは、一貫性のある実行ルールにより、同じ注文の命令を処理するときにステートマシンが同じ結果を生成することが保証されるためです。したがって、すべてのブロックチェーンシステムでは、トランザクションをチェーンでリンクする必要があり、TONも例外ではありません。アカウントチェーンは、TON ネットワークの最も基本的な単位です。通常、AccountChain は仮想概念であり、独立した AccountChain が存在する可能性は低いです。

シャードチェーン: ほとんどのコンテキストでは、シャードチェーンは TON 内の実際の単位です。ShardChain は、基本的に AccountChain のコレクションです。

WorkChain: Solidity スマートコントラクトを実行するために EVM に基づいて WorkChain を作成するなど、カスタムルールを持つシャードチェーンのセットとも呼ばれます。理論的には、コミュニティの誰もが独自のWorkChainを作成できます。ただし、構築は非常に複雑であり、(高い)作成料金を支払い、バリデータの2/3から承認を得る必要があります。

マスターチェーン:TONには、マスターチェーンと呼ばれる独自のチェーンがあり、すべてのシャードチェーンにファイナリティを提供します。シャードチェーン ブロックのハッシュ値が MasterChain ブロックに含まれる場合、そのシャードチェーン ブロックとそのすべての親ブロックは最終的なものと見なされ、固定で不変であり、後続のすべてのシャードチェーン ブロックによって参照されます。

このパラダイムは、TONネットワークに3つの主要な機能を提供します。

動的シャーディング:TONは、シャードチェーンを自動的に分割およびマージして負荷の変化に適応し、新しいブロックが迅速に生成され、トランザクションでロング遅延が発生しないようにします。

高いスケーラビリティ:無限のシャーディングパラダイムにより、TONはほぼ無制限の数のシャードをサポートでき、理論的には最大2^60のWorkChainsです。

適応性:ネットワークの一部で負荷が増加した場合、より高いトランザクション出来高を処理するために、より多くのシャードに細分化できます。逆に、負荷が減少すると、シャードがマージされて効率が向上します。

このようなマルチチェーンシステムでは、主な課題はクロスチェーン通信です。無限シャーディングの機能により、ネットワーク内のシャードの数が大幅に増加すると、チェーン間の情報のルーティングが複雑になります。たとえば、4 つのノードがあり、それぞれが独立したワークチェーンを維持しているネットワークを想像してみてください。各ノードは、独自のトランザクションソートを管理するだけでなく、他のチェーンの状態変化も監視して処理する必要があります。TON では、これは出力キュー内のメッセージをモニターすることによって行われます。

WorkChain 1 のアカウント A が WorkChain 3 のアカウント C にメッセージを送信したいとします。これには、メッセージ ルーティング ソリューションを設計する必要があります。この例では、WorkChain 1 -> WorkChain 2 -> WorkChain 3 と WorkChain 1 -> WorkChain 4 -> WorkChain 3 の 2 つのルーティングパスがあります。

より複雑なシナリオでは、高速なメッセージ通信のために効率的で低コストのルーティング アルゴリズムが必要です。TON は、クロスチェーン メッセージ ルーティング検出に "ハイパーキューブ ルーティング アルゴリズム" を使用します。ハイパーキューブ構造は、n 次元のハイパーキューブに 2^n 個の頂点があり、それぞれが n ビットの 2 進数で一意に識別される特殊なネットワーク トポロジです。この構造では、バイナリ表現が 1 ビットだけ異なる場合、任意の 2 つの頂点が隣接しています。たとえば、3 次元超立方体では、頂点 000 と頂点 001 は最後のビットのみが異なるため、隣接しています。上記の例は 2 次元の超立方体です。

ハイパーキューブ ルーティング プロトコルでは、ソース WorkChain からターゲット WorkChain へのメッセージのルーティングは、バイナリ アドレスを比較することによって行われます。アルゴリズムは、これらのアドレス間の最小距離(つまり、異なるビット数)を見つけ、宛先に到達するまで隣接するWorkChainを介してメッセージを転送します。これにより、データパケットが最短経路をたどるようになり、ネットワーク通信の効率が向上します。このプロセスを簡素化するために、TONは楽観的なソリューションも提供します。ユーザーがルーティングパス(通常はマークルトライルート)の有効な証明を提供できる場合、ノードはメッセージの真正性をすぐに検証できます。これは、インスタント ハイパーキューブ ルーティングと呼ばれます。その結果、TONアドレスは他のブロックチェーンプロトコルのアドレスとは大きく異なります。ほとんどのブロックチェーンプロトコルは、楕円暗号化アルゴリズムによって生成された公開鍵のハッシュをアドレスとして使用し、ルーティング機能を必要とせずに一意性に焦点を当てています。TON では、アドレスは (workchain_id, アカウント_id) の 2 つの部分で構成され、workchain_idはハイパーキューブ ルーティング アルゴリズムに従ってエンコードされます。Cosmosと同様に、すべてのクロスチェーン情報をMasterChainを介して中継しないのはなぜか疑問に思うかもしれません。TONの設計では、マスターチェーンはワークチェーンのファイナリティを維持するという最も重要なタスクのみを処理します。MasterChainを介してメッセージをルーティングすることは可能ですが、関連する料金は法外に高くなります。

最後に、そのコンセンサスアルゴリズムについて簡単に説明しましょう。TONは、BFT(ビザンチン障害耐性)とPoS(プルーフオブステーク)の組み合わせを採用しています。これは、すべてのステーカーがブロック作成に参加できることを意味します。TON選挙ガバナンス契約は、すべてのステーカーからバリデータのグループをランダムに定期的に選択します。これらの選択されたバリデータは、BFTアルゴリズムを使用してブロックを作成します。バリデーターが無効なブロックを作成したり、悪意を持って行動したりした場合、ステーキングされたトークンは没収されます。逆に、有効なブロックの作成に成功すると報酬を受け取ります。この方法は非常に一般的であるため、ここではこれ以上詳しく説明しません。

完全並列実行環境内でアクターモデルを利用するスマートコントラクト

主流のブロックチェーンプロトコルと比較したTONのもう一つの重要な違いは、スマートコントラクトの実行環境です。主流のブロックチェーンプロトコルが直面するTPSの制限を克服するために、TONはボトムアップ設計アプローチを使用し、アクターモデルを採用してスマートコントラクトとその実行を再構築し、完全な並列実行機能を可能にします。

ほとんどの主流のブロックチェーンプロトコルは、シングルスレッドのシリアル実行環境を使用しています。たとえば、イーサリアムの実行環境であるEVMは、トランザクションを順番に処理するステートマシンとして動作します。ブロックが形成され、トランザクションが順序付けられると、EVMを介してトランザクションが1つずつ実行されます。この完全にシリアルなシングルスレッド プロセスは、常に 1 つのトランザクションのみが処理されることを意味します。利点は、トランザクション注文が確立されると、分散ネットワーク全体で実行結果の一貫性が保たれることです。さらに、一度に実行されるトランザクションは1つだけであるため、他のトランザクションはアクセスされている状態データを変更できず、スマートコントラクト間の相互運用性が確保されます。たとえば、Uniswapを使用してUSDTでETHを購入する場合、流動性プールの分配は実行中の固定値です。これにより、数学モデルが正確な結果を決定できます。逆に、他の流動性プロバイダーがボンディングカーブの計算中に流動性を追加した場合、結果は古くなることになり、これは明らかに受け入れられません。

ただし、このアーキテクチャには明確な制限もあり、特にTPSのボトルネックは、最新のマルチコアプロセッサでは時代遅れに感じられます。これは、Red Alertのような古いコンピューターゲームを新しいPCでプレイするのと似ています。戦闘ユニットの数が一定のレベルに達すると、かなりのラグが発生します。これは、ソフトウェアアーキテクチャの問題によるものです。

一部のプロトコルはこの問題に対処しており、独自の並列ソリューションを提案しています。たとえば、TPSが最も高いと主張するソラナは、並列実行もサポートしています。ただし、ソラナのデザインはTONのデザインとは異なります。ソラナの核となるアイデアは、実行の依存関係に基づいてすべてのトランザクションをグループ化し、異なるグループが状態データを共有しないようにすることです。つまり、共有の依存関係がないため、異なるグループのトランザクションを競合することなく並列に実行できます。同じグループ内のトランザクションは、引き続き順次実行されます。

対照的に、TONは直列実行アーキテクチャを完全に放棄し、並列処理用に特別に設計された開発パラダイムを採用し、アクターモデルを使用して実行環境を再構築します。1973 年に Carl Hewitt によって最初に提案された Actor モデルは、メッセージの受け渡しを通じて、従来の並列プログラムにおける共有状態の複雑さを解決することを目的としています。各アクタには独自のプライベートな状態と動作があり、他のアクタと状態情報を共有しません。アクターモデルは、メッセージパッシングによって並列処理を実現する並行計算モデルです。このモデルでは、「アクタ」は、受信したメッセージの処理、新しいアクタの作成、追加のメッセージの送信、および後続のメッセージへの応答方法の決定を行うことができる基本単位です。アクター モデルには、次の特性が必要です。

カプセル化と独立性: 各アクターは、メッセージの処理時に完全に独立して動作し、干渉のない並列メッセージ処理を可能にします。

メッセージパッシング: アクターは、メッセージの送受信のみを介して対話し、メッセージの受け渡しは非同期です。

Dynamic Structure: アクタはランタイムに追加のアクタを作成できるため、アクタ モデルは必要に応じてシステムを動的に拡張できます。

TONはスマートコントラクトモデルにこのアーキテクチャを採用しており、TONの各スマートコントラクトはアクターモデルに基づいており、外部データに依存しないため完全に独立したストレージを備えています。さらに、同じスマートコントラクトへの呼び出しは、受信キュー内のメッセージの注文で実行されます。これにより、TON のトランザクションは、競合を心配することなく効率的に並列に実行できます。ただし、この設計にはいくつかの新しい課題もあります。DApps開発者にとって、慣れ親しんだ開発パラダイムは次のように破壊されます。

1. 非同期スマートコントラクト呼び出し:TONでは、外部コントラクトをアトミックに呼び出したり、スマートコントラクト内の外部コントラクトデータにアクセスしたりすることはできません。たとえば、Solidity では、コントラクト A の function1 がコントラクト B の function2 を呼び出したり、コントラクト C の読み取り専用関数3 を介して特定の状態データにアクセスしたりすることは、すべて 1 つのトランザクションで簡単に行うことができます。ただし、TONではこれを実現できません。外部スマートコントラクトとの相互作用は、スマートコントラクトによって開始される内部メッセージと呼ばれる新しいトランザクションを作成することによって非同期的に実行されます。結果を待つために実行プロセスをブロックすることはできません。

たとえば、DEXを開発していて、共通のEVMパラダイムに従っている場合、通常、トランザクションルーティングを管理するための統一されたルーターコントラクトがあり、各プールは特定の取引ペアのLPデータを個別に管理します。USDT-DAIとDAI-ETHの2つのプールがあるとします。ユーザーが USDT で直接ETHを購入する場合は、ルーター コントラクトを使用して、1 つのアトミック トランザクションでこれら 2 つのプールと順番に対話できます。ただし、TON では、このプロセスはそれほど単純ではなく、別の開発アプローチが必要です。この EVM パラダイムを再利用しようとすると、情報フローには、ユーザーによって開始された外部メッセージと、トランザクションを完了するための 3 つの内部メッセージが含まれます (この例は違いを強調するためのものであり、実際の開発では、ERC20 パラダイムでさえ再設計する必要があります)。

1. コントラクト間の呼び出しでのエラー処理については、慎重に検討し、コントラクト間の相互作用ごとに適切なバウンス関数を設計する必要があります。メインストリームの EVM システムでは、トランザクションの実行中にエラーが発生した場合、トランザクション全体が初期状態にロールバックされます。これは、シリアル シングル スレッド モデルでは簡単です。ただし、TONでは、コントラクト間の呼び出しが非同期に実行されるため、後の段階でエラーが発生した場合、先に正常に実行されたトランザクションがすでに確認されており、問題が発生する可能性があります。そのため、TON ではバウンスメッセージと呼ばれる特殊なメッセージタイプが導入されています。内部メッセージの後続の実行でエラーが発生した場合、トリガされたコントラクトは、トリガコントラクトで予約されているバウンス関数を使用して、トリガコントラクトの特定の状態をリセットできます。

2. 複雑なシナリオでは、最初に受信されたトランザクションが最初に完了しない可能性があるため、特定の実行注文を想定することはできません。非同期および並列のスマートコントラクトシステムでは、処理注文の定義が困難な場合があります。これが、TON のすべてのメッセージに、ランポート時間 (lt) と呼ばれる論理時間がある理由です。これは、どのイベントが別のイベントをトリガーし、どのバリデータが最初に処理する必要があるかを判断するのに役立ちます。単純なモデルでは、最初に受信したトランザクションが最初に実行されます。

このモデルでは、A と B は 2 つのスマートコントラクトを表します。msg1_lt < msg2_lt場合は、シーケンスの観点からtx1_lt < tx2_ltします。

ただし、より複雑な状況では、このルールが破られる可能性があります。公式ドキュメントには、A、B、Cの3つの契約があるとします。1 つのトランザクションで、A は msg1 と msg2 の 2 つの内部メッセージを送信し、1 つは B に、もう 1 つは C に送信します。これらは特定の注文 (最初に msg1、次に msg2) で作成されますが、msg1 が msg2 の前に処理されるかどうかはわかりません。この不確実性は、A から B へのルートと A から C へのルートの長さとバリデーターセットが異なるために発生します。これらのコントラクトが異なるシャード チェーンにある場合、1 つのメッセージがターゲット コントラクトに到達するまでに複数のブロックが必要になることがあります。したがって、図に示すように、2 つの可能なトランザクション パスがあります。

1. TONでは、スマートコントラクト の永続ストレージは、セルを単位とする有向非循環グラフ(DAG)構造を使用します。データは、特定のエンコード規則に従ってセルにコンパクトに圧縮され、DAG 方式で下方向に拡張されます。これは、EVM で状態データに使用されるハッシュマップベースの構造とは対照的です。データアクセスアルゴリズムが異なるため、TONはさまざまな深さでデータを処理するためにさまざまなガス価格を割り当てます。より深いセルデータ処理には、より多くのガスが必要です。その結果、TONは一種のDOS攻撃に直面し、悪意のあるユーザーがスマートコントラクトに多数のジャンクメッセージを大量に殺到させ、すべての浅いセルを埋めます。これにより、誠実なユーザーのストレージコストが増加します。対照的に、EVMのハッシュマップのクエリの複雑さはO(1)であり、一貫したガスコストを保証し、同様の問題を回避します。したがって、TON Dapp開発者は、スマートコントラクトで無制限のデータ型を使用しないようにする必要があります。無制限のデータ型が必要な場合は、シャーディングを使用してパーティション分割する必要があります。

1. 一部の機能は、スマートコントラクトがストレージの家賃を支払うための要件など、それほどユニークではありません。TONでは、スマートコントラクトは本質的にアップグレード可能であり、ネイティブの抽象アカウント機能が付属しているため、TONのすべてのウォレットアドレスはスマートコントラクトであり、初期化されていないだけです。開発者は、これらの側面に細心の注意を払う必要があります。

免責事項:

1. この記事は [Theblockbeats] からの転載です。すべての著作権は原作者【Web3Mario】に帰属します。この転載に異議がある場合は、Gate Learnチームまでご連絡いただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。特に明記されていない限り、翻訳された記事のコピー、配布、盗用は禁止されています。