TONの技術的特徴とスマート・コントラクト開発パラダイムの詳細説明

出典:MarioWatchWeb3

はじめに：TONエコシステムにおけるCoinOn最大のゲーム「Notcoin」のローンチと、完全流通トークン経済モデルによって引き起こされた巨大な富の効果により、TONは即座に、そして短期間で大きな注目を獲得した。TONは短期間で大きな注目を集めました。友人と話した結果、TONの技術的な敷居は比較的高く、DAppの開発パラダイムは主流のパブリックチェーンプロトコルとは大きく異なることが分かりました。 そこで、関連するトピックを深く研究するために時間を費やしましたので、私の洞察の一部を皆さんと共有したいと思います。要するに、TONの核となる設計コンセプトは、伝統的なブロックチェーン・プロトコルを「ボトムアップ」方式で再構築し、相互運用性を犠牲にして、高並行性と高スケーラビリティを究極的に追求することです。

TONの中核となる設計思想 - 高い並行性と拡張性

TONにおける複雑な技術的選択はすべて、高い並行性と拡張性を達成する目的で行われたと言えます。TON（The Open Network）は、L1ブロックチェーンと複数のコンポーネントで構成される分散型コンピューティング・ネットワークで、元々はTelegramの創設者であるニコライ・デュロフと彼のチームによって開発され、現在は世界中の独立した貢献者によって開発されている。TONはもともとTelegramの創設者であるニコライ・ドゥロフと彼のチームによって開発され、独立した貢献者のグローバル・コミュニティによってサポートされ、維持されるように発展してきた。その誕生は、Telegramチームが自分たちのためにブロックチェーン・ソリューションを模索し始めた2017年にさかのぼる。Telegramの9桁のユーザーベースをサポートできる既存のL1ブロックチェーンがなかったため、彼らは独自のブロックチェーンを設計することに決め、当時はTelegram Open Networkと呼ばれていた。2018年になり、TONの実装に必要なリソースを獲得するため、Telegramは2018年第1四半期にGramトークン（後にToncoinと改名）の販売を開始した。2020年、Telegramチームは規制上の問題を理由にTONプロジェクトから撤退した。その後、オープンソース開発者とTelegramコンテストの勝者からなる小さなグループがTONのコードベースを引き継ぎ、プロジェクトをThe Open Networkと改名し、オリジナルのTONホワイトペーパーに概説された原則に従い、今日までブロックチェーンの開発を積極的に続けている。

つまり、Telegramの分散実行環境として設計されたため、当然、高い同時実行性と大量のデータという2つの問題に対処しなければならなかったのです。技術が進化するにつれ、最高のTPSを持つと主張するSolanaの実測最大値は65,000に過ぎず、必要な数百万TPSをサポートするには明らかに不十分であることがわかっています。数百万TPSを必要とするTelegramのエコシステムをサポートするには明らかに不十分だ。同時に、Telegramの大規模なアプリケーションにより、Telegramによって生成されるデータ量はすでに空を越えており、ネットワーク内の各ノードにデータの完全なコピーを保持することを要求するならば、極めて冗長な分散システムとしてのブロックチェーンも非現実的である。

そこで、これら2つの問題を解決するために、TONは主流のブロックチェーン・プロトコルを2つの方法で最適化しました：

• 「無限のノード数」を採用することで、TONはブロックチェーン・プロトコルを2つの方法で最適化できるようになりました。">Infinite Sharding Paradigmを採用してシステムを設計することで、データの冗長性の問題を解決し、パフォーマンスのボトルネックを緩和しながらビッグデータを運ぶことができます。

• アクターモデルに基づく完全並列実行環境を導入することで、システムのパフォーマンスを大幅に向上させます。"text-align: left;">今日、私たちは、シャーディングがほとんどのブロックチェーンプロトコルのパフォーマンスを向上させ、コストを削減するための主流のソリューションになっていることを知っています。TONはこれを極端にし、ブロックチェーンがネットワーク負荷に基づいて動的にシャードの数を増減できるようにする無限シャーディングパラダイムを提案しています。このパラダイムにより、TONは高いパフォーマンスを維持しながら、大規模なトランザクションやスマートコントラクトのオペレーションを処理することができます。 理論的には、TONはアカウントごとに排他的なアカウントチェーンを確立し、特定のルールによってこれらのチェーンの一貫性を確保することができます。

  抽象的に言えば、TONには4層のチェーン構造があります。4層のチェーン構造：

  • AccountChain：チェーンのこの層は、アカウントに関連するトランザクションのチェーンを表します。ステートマシンの場合、実行ルールが一貫している限り、ステートマシンは同じ順序の命令を受け取った後に同じ結果を得る。したがって、すべてのブロックチェーン分散システムはトランザクションをチェーン化する必要があり、TONも例外ではない。チェーン・オブ・アカウントはTONネットワークの最も基本的な構成要素であり、チェーン・オブ・アカウントは仮想的な概念であることが多く、実際に別のチェーン・オブ・アカウントが存在する可能性は低い。

  • シャードチェーン（ShardChain）：ほとんどの文脈において、シャードチェーンはTONの実際の構成要素であり、アカウントチェーンの集合体です。

  • ワークチェーン：これは、Solidityスマートコントラクトを実行するEVMベースのワークチェーンを作成するなど、カスタムルールを持つシャードチェーンのセットと呼ぶこともできます。理論的には、コミュニティの誰もが自分のワークチェーンを作成できる。実際、ワークチェーンの作成はかなり複雑な作業であり、作成に必要な（高額な）手数料を支払い、バリデータから2/3の投票を得てワークチェーンの作成を承認する必要があります。

  • マスターチェーン：最後に、TONにはマスターチェーンと呼ばれる特別なチェーンがあります。シャーデッドチェーンのブロックのハッシュがマスターチェーンのブロックにマージされると、そのシャーデッドチェーンのブロックとそのすべての親は最終性を持つとみなされます。

  このようなパラダイムを採用することで、TONネットワークは以下の3つの機能を実現しています：

  • 動的シャーディング：TONは、負荷の変化に適応するために、自動的にシャーディング・チェーンを分割およびマージすることができます。これは、新しいブロックが常に迅速に生成され、トランザクションに長い待ち時間が発生しないことを意味します。

  • 高いスケーラビリティ：無限シャーディングパラダイムにより、TONは理論的には2の60乗まで、事実上無制限の数のシャーディングをサポートすることができます。

  • 適応性：ネットワークの一部の負荷が増加すると、その部分はより多くのスライスに細分化され、トランザクション量の増加に対応することができます。逆に負荷が減少すると、スライスを統合して効率を高めることができます。

  このようなマルチチェーンシステムで、最初に直面しなければならないのは、クロスチェーン通信の問題です。特に、スライスを無制限に持つことができるため、ネットワーク内のスライスの数がある桁に達すると、チェーン間の情報のルーティングが困難になります。ネットワーク内の4つのノードがあると想像すると、各ノードは、リンク関係は、ノードがトランザクションのシーケンス作業に加えて、独自のワークチェーンの責任であることを示す独立したワークチェーンを維持するための責任を負うだけでなく、達成するためにメッセージの出力キューをリッスンすることにより、TONで、ターゲットチェーンの状態変化をリッスンして処理する必要があります

  

  ジョブチェーン1のアカウントAが、ジョブチェーン3のアカウントCにメッセージを送りたいとします。メッセージはジョブチェーン3のアカウントCに送信されます。この例では、2つのルーティングパス、ジョブチェーン1 -> ジョブチェーン2-> ジョブチェーン3、およびジョブチェーン1 -> ジョブチェーン4 -> ジョブチェーン3があります。

  より複雑なシナリオに直面したとき、高効率で低コストのルーティングが必要になります。より複雑な状況に直面した場合、メッセージ通信を迅速に完了させるために、効率的で低コストのルーティングアルゴリズムが必要となります。TONは、クロスチェーンのメッセージ通信ルート発見を実現するために、いわゆる「ハイパーキューブ・ルーティング・アルゴリズム」を選択しました。ハイパーキューブ構造とは、2^n個の頂点から構成されるn次元のハイパーキューブで、各頂点はnビットの2進数で識別される。この構造では、2つの頂点が2進数表現で1ビットだけ異なれば隣接する。例えば、3次元の超立方体では、頂点000と頂点001は最後のビットだけが異なるので隣接している。上の例は2次元超立方体である。

  

  

  超立方体ルーティングプロトコルでは、メッセージが送信元ワーキングチェーンから宛先ワーキングチェーンにルーティングされるプロセスは、送信元ワーキングチェーンと宛先ワーキングチェーンのアドレスのバイナリ表現を比較することによって実行される。ルーティングアルゴリズムは、これら2つのアドレス間の最小距離（すなわち、バイナリ表現における異なるビットの数）を見つけ、宛先の作業チェーンに到達するまで、近隣の作業チェーンを通してメッセージを漸進的に転送する。このアプローチは、パケットが最短経路で転送されることを保証し、ネットワークの通信効率を向上させます。

  もちろん、このプロセスを簡略化するために、TONは楽観的な技術的解決策も提案しており、ユーザーが特定のルーティングパス（通常はインスタント・ハイパー・キューブ・ルーティングとしても知られる）に対する有効性の証明を提供できる場合、ノードはユーザーによって提出されたメッセージの信頼性を直接認めることができます。キューブルーティングとしても知られています。

  このように、TONのアドレスと他のブロックチェーンプロトコルには明確な違いがあることがわかります。 他の主流のブロックチェーンプロトコルのほとんどは、ハッシュに対応する公開鍵の公開鍵によって生成される楕円暗号化アルゴリズムをアドレスとして使用しています。TONのアドレスは2つの部分、（workchain_id、account_id）があり、workchain_idはハイパーキューブルーティングアルゴリズムのアドレスに従ってエンコードされますが、ここでは詳しく説明しません。

  また、簡単な疑問点があります。メインチェーンと各ワークチェーンはリンク関係を持っているため、メインチェーンを介してすべてのクロスチェーン情報がリレーを行うには、コスモスのように、それではないことがわかったかもしれません。TONの設計思想では、マスターチェーンは、多数のワークチェーンの最終性を維持するという最もクリティカルなタスクにのみ使用され、マスターチェーンを経由してメッセージをルーティングすることは不可能ではないが、そうするには非常にコストがかかる。

  最後に、コンセンサスアルゴリズムの簡単な言及は、TONはBFT + PoSを使用し、つまり、任意のステーカーは、ブロックパッキングに参加する機会を持って、TONの選挙ガバナンス契約は、ランダムにパッケージ化された検証クラスタを選択するすべてのステーカーから、一定の間隔でされ、検証ノードがBFT + PoSを通過すると呼ばれる選択されました。検証者として選ばれたノードは、BFTアルゴリズムによってブロックをパックします。もし間違った情報をパックしたり、悪事を働いたりした場合、そのステークトークンは没収され、逆にブロックをパックしたノードには報酬が支払われます。これは基本的に一般的な選択なので、ここでは触れません。

  アクターモデルベースのスマートコントラクトと完全並列実行環境

  TONと主流のブロックチェーンプロトコルのもう一つの違いは、スマートコントラクトの実行環境です。主流のブロックチェーンプロトコルのTPSの限界を突破するため、TONはボトムアップの設計アプローチを採用し、アクターモデルを使用してスマートコントラクトとその実行方法を再構築することで、完全な並列実行能力を持たせています。

  私たちは、主流のブロックチェーンプロトコルのほとんどがシングルスレッドのシリアル実行環境を使用していることを知っています。 イーサリアムを例にとると、その実行環境であるEVMは、トランザクションを入力とするステートマシンであり、ノードがブロックパッキングによってトランザクションの順序付けを完了すると、その順序でEVMを介してトランザクションを実行します。全プロセスは完全にシリアルかつシングルスレッド、つまりある瞬間に実行できるトランザクションは1つだけであり、トランザクションの順序が確認されている限り、幅広い分散クラスタ間で実行結果が一貫しているという利点があると同時に、同時に1つのトランザクションだけがシリアルに実行されるため、実行プロセス中に他のトランザクションがアクセスすべき特定の状態データに変更を加えることは不可能であり、これが可能になる。スマートコントラクト間の相互運用性。例えば、USDTを使用してUniswapを通じてETHを購入する場合、取引が実行されるとき、ペアのLPの分布はある数学的モデルから導き出される明確な値になります。古い結果となり、これは明らかに容認できません。

  しかし、このアーキテクチャにも明らかな限界があります。それは、現在のマルチコアプロセッサでは非常に古いTPSがボトルネックになっていることです。ちょうど、最新のPCを使ってレッドアラートのような古いコンピュータゲームをプレイするとき、ある程度の台数があると、それでもカードが動作しないことがあるように、ソフトウェアアーキテクチャの問題なのです。問題はソフトウェア・アーキテクチャにある。

  いくつかのプロトコルはすでにこの問題に注目しており、現在最高のTPSを主張しているSolanaのように、独自の並列実行ソリューションを考え出したと聞くかもしれません。Solanaでは、すべてのトランザクションを実行依存関係に従っていくつかのグループに分け、異なるグループは互いに状態データを共有しない。つまり、同一の依存関係は存在しないので、異なるグループのトランザクションは競合を心配することなく並列に実行することができるが、同じグループのトランザクションは依然として従来のシリアル方法で実行される。

  TONでは、シリアル実行アーキテクチャは完全に放棄され、並列実行のために設計された開発パラダイム、アクターモデルが実行環境を再構築するために採用されている。アクター・モデルは、1973年にカール・ヒューイット（Carl Hewitt）によって提案されたもので、従来の並行プログラムにおけるメッセージ・パッシングによる状態の共有の複雑さに対処するためのものである。アクターモデルは、メッセージパッシングによって並列計算を実現する並列計算のための計算モデルである。このモデルでは、アクターは、入ってくるメッセージを処理し、新しいアクターを作成し、さらにメッセージを送信し、次のメッセージにどのように応答するかを決定する作業の基本単位です。アクター・モデルは、次のような特徴を持つ必要があります：

  • カプセル化と独立性：各アクターはメッセージ処理において完全に独立しており、互いに干渉することなく並行してメッセージを処理することができます。

  • メッセージング：アクターは、非同期であるメッセージの送受信によってのみ相互作用します。

  • 動的アーキテクチャ：アクターは実行時にさらにアクターを作成することができ、このダイナミズムによってアクターモデルは必要に応じてシステムを拡張することができます。

  TONは、スマートコントラクトモデルを設計するためにこのアーキテクチャを使用しています。つまり、TONでは、各スマートコントラクトは完全に独立したストレージを持つActorモデルです。つまり、TONでは、各スマート・コントラクトは、外部データに依存しないため、完全に独立したストレージ空間を持つアクター・モデルである。さらに、同じスマート・コントラクトの呼び出しは、受信キューのメッセージの順番に実行されるので、TONのトランザクションは競合を心配することなく効率的に並列実行できる。

  しかし、この設計アプローチには、DApp開発者にとって、以下のような、これまでのパラダイムを壊すような新しい意味合いもあります：

  1.スマートコントラクト間の非同期呼び出し：TONのスマートコントラクト内でスマートコントラクトを呼び出す方法はありません。TONのスマートコントラクトは、外部のコントラクトをアトミックに呼び出したり、外部のコントラクトデータにアクセスしたりできません。Solidityでは、コントラクトAの関数1がコントラクトBの関数2を呼び出したり、コントラクトCの読み取り専用関数3を通じて特定の状態データにアクセスしたりすることが知られています。全プロセスはアトミックであり、1つのトランザクションで実行される。 しかし、TONではこれが不可能になる。外部のスマートコントラクトとの対話は、内部メッセージとも呼ばれる新しいトランザクションをパックすることで非同期に実行され、コントラクトのブロックを防ぐために実行中にブロックすることはできない。また、実行結果を得るために実行をブロックすることもできません。

  例えば、取引のルーティングを管理する単一のルーターコントラクトがあり、各プールが特定のペアに関連するLPデータを管理するという、EVMで一般的なパラダイムを使用してDEXを開発している場合、USDT-DAIとDAI-ETHの2つのプールがあるとします。ユーザーがUSDT経由でETHを直接購入したい場合、ルーター契約を通じて1つのトランザクションで両方のプールに順次リクエストし、アトミックトランザクションを完了させることができます。しかし、TONでこれを実現するのはそう簡単ではなく、新しい開発パラダイムを考える必要がある。 このパラダイムがまだ再利用される場合、情報の流れは次のようになるかもしれない：リクエストは、ユーザーによって開始される外部メッセージと3つの内部メッセージを伴う（これは違いを説明するために使用されていることに注意してください。）(これは違いを説明するためのもので、実際の開発ではERC20のパラダイムでさえ再設計しなければならないことに注意してください）。

  

  2.left;">2.契約をまたいで呼び出す際の実行エラー状況をどのように処理するかを慎重に検討し、契約間の呼び出しごとに対応するバウンス関数を設計する必要があります。主流のEVMでは、トランザクションが実行中に問題に遭遇すると、トランザクション全体がロールバックされる、すなわち実行の初期状態にリセットされることがわかっている。これはシリアル・シングルスレッドモデルでは理解しやすい。しかしTONでは、コントラクト間コールが非同期で実行されるため、後続ステップの1つでエラーが発生しても、すでに正常に実行されたトランザクションが実行確認されているため、問題が発生する可能性がある。そこで、TONではバウンスメッセージという特殊なメッセージタイプを設定し、内部メッセージをトリガーとした後続の実行処理でエラーが発生した場合、トリガーとなるコントラクトが予約しているバウンス関数を使用することで、トリガーとなるコントラクトの一部の状態をリセットできるようにしています。

  

  3.left;">3.複雑なケースでは、先に受信したトランザクションが必ずしも先に実行されるとは限らないため、このタイミング関係を事前に決定することはできない。このような非同期かつ並列のスマートコントラクト呼び出しのシステムでは、処理操作の順序を定義することが困難な場合がある。このため、TONの各メッセージには論理時間Lamport time（後にltと呼ばれる）が設定されている。これは、どのイベントが別のイベントをトリガーし、検証者が何を最初に処理する必要があるかを理解するために使用される。単純なモデルでは、最初に受信したトランザクションが最初に実行されなければならない。

  

  このモデルでは、AとBはそれぞれ2つのスマート・コントラクトを表し、msg1_lt < msg2_ltの場合、tx1_lt < tx2_ltの時間的関係があります。

  しかし、より複雑なケースでは、このルールは崩れます。公式ドキュメントでは、A、B、C の 3 つのコントラクトがあるとします。1 つのトランザク ションで、A は 2 つの内部メッセージ msg1 と msg2 を送信します。なぜなら、AからBへのルートと、AからCへのルートは、長さもベリファイアのセッ トも異なる可能性があるからです。これらのコントラクトが異なるピースワイズ・チェーンに配置されている場合、メッ セージの1つがターゲットとなるコントラクトに到達するのに数ブロックかかる可能性 がある。つまり、図に示すように、2つの取引経路が考えられる。

  

  

  5.また、スマートコントラクトがストレージに賃料を支払う必要があること、スマートコントラクトがTONでは当然スケーラブルであること、TONのすべてのウォレットアドレスが初期化されていないだけのスマートコントラクトであるネイティブの抽象アカウント機能など、あまり特殊ではない機能もあります。これらは開発者が注意して見ておく必要があることです。

  上記は、私がTON関連技術の経験のいくつかを学んだ期間であり、あなたと共有するために、私はあなたが修正することを願って間違った場所に書かれている、同時に、私はTelegramの膨大な量のトラフィックリソースで、TONエコシステムは、Web3のためのいくつかの新しいアプリケーションをもたらすだろうと思う、TON DAppの開発パートナーにも興味があります。もしTON DAppの開発にご興味があれば、ぜひ私にご連絡ください。