一文でTONの技術的特徴とスマートコントラクト開発のパラダイムを理解する

原文来源：Web3 Mario X 账号

作者：@Web3 Mario

引言：バイナンスがTONエコシステムの最大のゲームNotcoinを立ち上げ、全流通トークン経済モデルによって引き起こされた巨額の富の効果により、TONは短期間で大きな注目を集めました。友人と話したところ、TONの技術的なハードルは比較的高く、DApp開発のパラダイムは主流のパブリックチェーンプロトコルとは大きく異なることがわかりました。そのため、関連するテーマを深く研究するために時間をかけ、いくつかの気づきを皆さんと共有したいと思います。簡単に言えば、TONの核心的な設計理念は、「ボトムアップ」の方法で従来のブロックチェーンプロトコルを再構築し、相互運用性を放棄することで、高い同時実行性と高いスケーラビリティを追求することです。

TONの核心設計思想------高い同時実行性と高いスケーラビリティ

こう言えるでしょう。TONのすべての複雑な技術選択の目的は、高い同時実行性と高いスケーラビリティの追求から来ており、その誕生の背景からも理解できます。TON、すなわちThe Open Networkは、分散型の計算ネットワークであり、L1ブロックチェーンと複数のコンポーネントを含んでいます。TONは元々、Telegramの創設者ニコライ・デュロフとそのチームによって共同開発され、現在は世界中の独立した貢献者のコミュニティによって支えられ、維持されています。その誕生は2017年に遡り、Telegramチームは自らのブロックチェーンソリューションを探求し始めました。当時、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の実測最高TPSは65000に過ぎず、これは明らかに100万TPSの要求を支えるには不十分です。同時に、Telegramの大規模な利用に伴い、その生成するデータ量はすでに天文学的な数字を超えており、ブロックチェーンは極度に冗長な分散システムであるため、ネットワーク内の各ノードが完全なデータのコピーを保持することを要求するのは現実的ではありません。

したがって、上記の2つの問題を解決するために、TONは主流のブロックチェーンプロトコルに対して2つの側面で最適化を行いました：

• 「無限シャーディングパラダイム」（Infinite Sharding Paradigm）を採用してシステムを設計し、データの冗長性の問題を解決し、大規模なデータを処理できるようにし、パフォーマンスのボトルネックの問題を緩和します。

• アクターモデルに基づく完全な並行実行環境を導入し、ネットワークのTPSを大幅に向上させます。

ブロックチェーンのチェーン------無限シャーディング能力を通じて各アカウントに専用のアカウントチェーンを持たせる

現在、シャーディング（sharding）はほとんどのブロックチェーンプロトコルがパフォーマンスを向上させ、コストを削減するための主流の手法となっていますが、TONはこれを極限まで追求し、無限シャーディングパラダイムを提唱しました。無限シャーディングパラダイムとは、ブロックチェーンがネットワークの負荷に応じて動的にシャードの数を増減できることを指します。このパラダイムにより、TONは高いパフォーマンスを維持しながら、大規模な取引やスマートコントラクトの操作を処理できるようになります。理論的には、TONは各アカウントに専用のアカウントチェーンを構築し、一定のルールに従ってこれらのチェーン間の整合性を保証することができます。

抽象的に理解すると、TONには合計4層のチェーン構造が存在します：

• アカウントチェーン（AccountChain）：この層のチェーンは、特定のアカウントに関連する一連の取引から構成されるチェーンを表します。取引がチェーン状に構成される理由は、状態機械にとって、ルールが一貫していれば、状態機械が同じ順序の指示を受け取った場合に得られる結果が一貫しているためです。したがって、すべてのブロックチェーン分散システムでは取引をチェーン状に順序付ける必要があり、TONも例外ではありません。アカウントチェーンはTONネットワークの最も基本的な構成要素であり、通常、アカウントチェーンは仮想的な概念であり、実際に独立したアカウントチェーンが存在することはほとんどありません。

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

• ワークチェーン（WorkChain）：カスタムルールを持つシャードチェーンのグループとも呼ばれます。例えば、EVMに基づくワークチェーンを作成し、その上でSolidityスマートコントラクトを実行します。理論的には、コミュニティの誰もが自分のワークチェーンを作成できます。実際には、それを構築するのはかなり複雑な作業であり、その前に作成するための（高額な）費用を支払い、検証者の2/3の票を得てワークチェーンの作成を承認してもらう必要があります。

• マスターチェーン（MasterChain）：最後に、TONには特別なチェーンがあり、これをマスターチェーンと呼びます。このチェーンはすべてのシャードチェーンに最終性をもたらす役割を担っています。シャードチェーンのブロックのハッシュ値がマスターチェーンのブロックに統合されると、そのシャードチェーンのブロックおよびそのすべての親ブロックは最終性を持つと見なされ、固定され不変の内容として、すべてのシャードチェーンの後続のブロックから参照されます。

このようなパラダイムを採用することで、TONネットワークは以下の3つの特徴を持つようになります：

• 動的シャーディング：TONは負荷の変化に応じてシャードチェーンを自動的に分割および統合できます。これにより、新しいブロックは常に迅速に生成され、取引は長時間の待機を生じません。

• 高度なスケーラビリティ：無限シャーディングパラダイムにより、TONはほぼ無限の数のシャードをサポートでき、理論的には2の60乗のワークチェーンに達することができます。

• 自適応性：ネットワーク内の特定の部分の負荷が増加すると、その部分はより多くのシャードに細分化され、増加した取引量を処理します。逆に、負荷が減少すると、シャードは統合されて効率を向上させます。

このようなマルチチェーンシステムでは、まず直面する必要があるのはクロスチェーン通信の問題です。特に無限シャーディングの能力を持つため、ネットワーク内のシャードの数が一定の規模に達すると、チェーン間の情報ルーティングが困難になります。ネットワークに4つのノードがあり、それぞれのノードが1つの独立したワークチェーンを維持していると仮定してみてください。この場合、リンク関係は、各ノードが自身のワークチェーンの取引順序付けの作業を担当するだけでなく、ターゲットチェーンの状態変化を監視し処理する必要があることを示します。TONでは、具体的には出力キューのメッセージを監視することで実現されます。

仮にワークチェーン1のアカウントAがワークチェーン3のアカウントCにメッセージを送信したい場合、メッセージルーティングの問題が関与します。この例では、2つのルーティングパスがあります。ワークチェーン1 -> ワークチェーン2 -> ワークチェーン3、ワークチェーン1 -> ワークチェーン4 -> ワークチェーン3です。

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

ハイパーキューブルーティングプロトコルでは、メッセージはソースワークチェーンからターゲットワークチェーンへのルーティングプロセスを、ソースワークチェーンとターゲットワークチェーンのアドレスのバイナリ表現を比較することで行います。ルーティングアルゴリズムは、これら2つのアドレス間の最小距離（すなわち、バイナリ表現で異なるビットの数）を見つけ、隣接するワークチェーンを通じて情報を段階的に転送し、ターゲットワークチェーンに到達します。この方法により、データパケットは最短経路に沿って送信され、ネットワークの通信効率が向上します。

もちろん、このプロセスを簡素化するために、TONは楽観的な技術ソリューションも提案しました。ユーザーが特定のルーティングパスに対する有効な証明を提供できる場合、通常は特定のマークルトライルートで、ノードはそのユーザーが提出したメッセージの信頼性を直接認めることができます。これを即時ハイパーキューブルーティングと呼びます。

したがって、TONのアドレスは他のブロックチェーンプロトコルと明らかに異なることがわかります。他の主流のブロックチェーンプロトコルは、通常、楕円暗号アルゴリズムによって生成された公開鍵に対応するハッシュをアドレスとして使用します。なぜなら、アドレスは唯一性の区別だけを目的としており、ルーティングアドレスの機能を担う必要がないからです。一方、TONのアドレスは2つの部分で構成されています（workchainid、accountid）。ここで、workchain_idはハイパーキューブルーティングアルゴリズムのアドレスに基づいてエンコードされていますが、詳細には触れません。

もう一つ疑問が生じる点は、マスターチェーンと各ワークチェーンがリンク関係にあるため、すべてのクロスチェーン情報はマスターチェーンを介して中継すればよいのではないかということです。まるでcosmosのように。TONの設計理念では、マスターチェーンは最も重要なタスク、すなわち多数のワークチェーンの最終性を維持するためだけに使用されます。メッセージをマスターチェーンを介してルーティングすることも可能ですが、その場合に発生する手数料は非常に高額になります。

最後に、TONのコンセンサスアルゴリズムについて簡単に触れます。TONはBFT+PoSの方式を採用しており、任意のステイカーがブロックのパッケージングに参加する機会があります。TONの選挙ガバナンス契約は、一定の時間ごとにすべてのステイカーからランダムにパッケージングの検証者集団を選択します。選ばれた検証者ノードはBFTアルゴリズムを通じてブロックをパッケージングします。もしパッケージングに誤った情報を含めたり、悪意を持った行動を取った場合、そのステークのトークンは没収され、逆に正しくブロックを生成した場合は報酬を得ることができます。これは基本的に比較的一般的な選択肢であるため、ここでは詳しく説明しません。

アクターモデルに基づくスマートコントラクトと完全並行実行環境

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

主流のブロックチェーンプロトコルは、ほとんどがシングルスレッドの直列実行環境を採用しています。Ethereumを例にとると、その実行環境EVMは取引を入力とする状態機械であり、ブロック生成ノードがブロックをパッケージングして取引の順序を完了すると、その順序でEVMを通じて取引が実行されます。このプロセスは完全に直列でシングルスレッドであり、特定の時点で一度に1つの取引しか実行されません。このようにすることで、取引の順序が確認されれば、実行結果は広範な分散型クラスター内で一貫性を持ちます。同時に、同時に1つの取引しか直列実行されないため、実行中に他の取引がアクセス待ちの状態データを変更することは不可能であり、これによりスマートコントラクト間の相互運用性が実現されます。例えば、Uniswapを通じてUSDTでETHを購入する場合、その取引が実行されると、取引ペアのLPの分布状況は確定した値となり、特定の数学モデルを通じて対応する結果を導き出すことができます。しかし、もし状況が異なり、他のLPが新たな流動性を追加した場合、計算結果は時代遅れのものとなり、これは明らかに受け入れられません。

しかし、このアーキテクチャには明らかな限界があります。それはTPSのボトルネックであり、このボトルネックは現在のマルチコアプロセッサの下で非常に古く見えます。最新のPCで古いコンピュータゲームをプレイするようなものです。例えば、レッドアラートのようなゲームで、戦闘ユニットが一定の数に達すると、依然としてカクつくことがあります。これはソフトウェアアーキテクチャの問題です。

いくつかのプロトコルがこの問題に注目し、自らの並行処理の提案を行っていることを耳にするかもしれません。現在、TPSが最も高いとされるSolanaも並行実行の能力を持っています。ただし、その設計思想はTONとは異なります。Solanaでは、すべての取引を実行依存関係に基づいていくつかのグループに分け、異なるグループ間では状態データを共有しません。つまり、同じ依存関係は存在せず、異なるグループ内の取引は並行して実行され、衝突の心配はありません。同じグループ内の取引は、従来の直列方式で実行されます。

一方、TONでは、直列実行のアーキテクチャを完全に放棄し、並行処理のために生まれた開発パラダイム、アクターモデルを用いて実行環境を再構築しました。アクターモデルは、1973年にカール・ヒューイットによって初めて提案され、メッセージの送受信を通じて従来の並行プログラムにおける共有状態の複雑性の問題を解決することを目的としています。各アクターは独自のプライベートな状態と動作を持ち、他のアクターとの間で状態情報を共有しません。アクターモデルは並行計算の計算モデルであり、メッセージの送受信を通じて並行計算を実現します。このモデルでは、「アクター」が基本的な作業単位であり、受信したメッセージを処理し、新しいアクターを作成し、さらにメッセージを送信し、次のメッセージにどのように応答するかを決定できます。アクターモデルには以下の特性が必要です：

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

• メッセージの送受信：アクター間の相互作用は、メッセージの送受信を通じてのみ行われ、メッセージの送受信は非同期です。

• 動的構造：アクターは実行時にさらに多くのアクターを作成でき、この動的性質によりアクターモデルは必要に応じてシステムを拡張できます。

TONはこのアーキテクチャを採用してスマートコントラクトモデルを設計しています。これは、TONにおいて各スマートコントラクトがアクターモデルであり、完全に独立したストレージスペースを持つことを意味します。外部データに依存しないためです。さらに、同じスマートコントラクトへの呼び出しは、受信キュー内のメッセージの順序に従って実行されるため、TONの取引は効率的に並行実行され、衝突の問題を心配する必要がありません。

しかし、このような設計方案は新たな影響をもたらします。DApp開発者にとって、慣れ親しんだ開発パラダイムが破壊されることになります。具体的には以下の通りです：

1. スマートコントラクト間の非同期呼び出し：TONのスマートコントラクト内部では、外部コントラクトを原子的に呼び出したり、外部コントラクトのデータにアクセスすることはできません。Solidityでは、コントラクトAのfunction1がコントラクトBのfunction2を呼び出したり、コントラクトCの読み取り専用function3を通じて状態データにアクセスする場合、全体のプロセスは原子的であり、一つの取引内で実行されるのが非常に簡単です。しかし、TONではこれは実現不可能です。外部スマートコントラクトとの相互作用はすべて、新しい取引をパッケージングして非同期に実行されます。このようにスマートコントラクトから発起された取引は内部メッセージと呼ばれ、実行中に結果を得るためにブロックすることはできません。

例えば、DEXを開発する場合、EVMで一般的なパラダイムを採用すると、通常は取引ルーティングを管理するための統一されたルーターコントラクトがあり、各プールは特定の取引ペアに関連するLPデータを個別に管理します。現在、USDT-DAIとDAI-ETHの2つのプールがあると仮定します。ユーザーがUSDTを使って直接ETHを購入したい場合、ルーターコントラクトを介して一つの取引内でこの2つのプールを順番に要求し、原子的な取引を完了することができます。しかし、TONではこれを簡単に実現することはできません。新しい開発パラダイムを考慮する必要があります。もしこのパラダイムを再利用する場合、情報フローは次のようになるかもしれません。この要求は、ユーザーが発起した外部メッセージと3つの内部メッセージを伴って完了します（これは差異を示すためのものであり、実際の開発ではERC20のパラダイムさえも再設計する必要があります）。

2. クロスコントラクト呼び出し時に発生する実行エラーの処理フローを慎重に考慮し、各コントラクト間の呼び出しに対応するバウンス関数を設計する必要があります。主流のEVMでは、取引実行中に問題が発生した場合、全体の取引がロールバックされ、実行開始時の状態にリセットされます。これは直列シングルスレッドモデルでは理解しやすいことです。しかし、TONでは、コントラクト間の呼び出しが非同期で実行されるため、後続の段階でエラーが発生しても、前の成功した取引はすでに実行され確認されているため、問題が生じる可能性があります。したがって、TONでは特別なメッセージタイプが設定されており、これをバウンスメッセージと呼びます。内部メッセージが引き起こす後続の実行プロセスでエラーが発生した場合、トリガーされたコントラクトはトリガーされたコントラクトが予約したバウンス関数を通じて、トリガーされたコントラクト内の特定の状態をリセットできます。

3. 複雑な状況では、先に受信された取引が必ずしも先に実行されるわけではないため、そのような時系列関係を前提にすることはできません。このような非同期および並行スマートコントラクト呼び出しのシステムでは、処理操作の順序を定義することが非常に難しい場合があります。これが、TONの各メッセージに論理時間Lamport time（以下ltと略称）がある理由です。これは、どのイベントが別のイベントを引き起こしたかを理解し、検証者が最初に処理する必要があるものを確認するために使用されます。単純なモデルでは、先に受信された取引が必ず先に実行されます。

このモデルでは、AとBはそれぞれ2つのスマートコントラクトを表し、msg1lt < msg2ltであれば、tx1lt < tx2ltの時系列関係が成立します。

しかし、より複雑な状況では、このルールが破られることがあります。公式文書にはこのような例があります。A、B、Cの3つのコントラクトがあると仮定します。一つの取引で、Aが内部メッセージmsg1とmsg2を送信します：一つはBに、もう一つはCに。これらは正確な順序で作成されています（msg1の後にmsg2）が、msg1がmsg2の前に処理されることを確定することはできません。これは、AからBおよびAからCへのルーティングが長さや検証者の集中度において異なる可能性があるためです。これらのコントラクトが異なるシャードチェーンに存在する場合、一つのメッセージがターゲットコントラクトに到達するまでに数ブロックかかる可能性があります。つまり、2つの可能な取引パスがあります。

4. TONでは、スマートコントラクトの永続的なストレージは、セルを単位とした有向非循環グラフをデータ構造として採用しています。データはエンコードルールに従ってコンパクトに圧縮され、1つのセルにまとめられ、有向非循環グラフの形で下に延びます。これはEVMの状態データがハッシュマップに基づいて構成されるのとは異なります。データ要求アルゴリズムの違いにより、TONでは異なる深さのデータ処理に対して異なるガス価格が設定されています。深いセルのデータ処理にはより多くのガスが必要です。したがって、TONにはDOS攻撃のパラダイムが存在します。つまり、悪意のあるユーザーが大量のゴミメッセージを送信して特定のスマートコントラクト内のすべての浅いセルを占有することができます。これは、誠実なユーザーのストレージコストがますます高くなることを意味します。一方、EVMではハッシュマップのクエリの複雑度がO(1)であるため、同じガスがかかり、同様の問題は発生しません。したがって、TONのDApp開発者は、スマートコントラクト内に無限のデータ型が出現することを避けるべきです。無限のデータ型が出現した場合は、シャーディングの方法でそれを分散させる必要があります。

5. その他の特徴はそれほど特異ではありません。例えば、スマートコントラクトはストレージのために家賃を支払う必要があり、TONではスマートコントラクトは本質的にアップグレード可能であり、ネイティブの抽象アカウント機能があります。つまり、TONではすべてのウォレットアドレスがスマートコントラクトであり、単に初期化されていないだけです。これらは開発者が注意深く留意する必要があります。

以上が、私がこの期間にTON関連技術を学んだいくつかの気づきです。皆さんと共有します。間違っている点があればご指摘いただければ幸いです。同時に、Telegramの膨大なトラフィックリソースを活用して、TONエコシステムはWeb3に新しいアプリケーションをもたらすと考えています。TON DApp開発に興味のある方は、ぜひ私に連絡して、一緒に議論しましょう。