執筆：@Web3Mario
はじめに：BinanceがTONエコシステム最大のゲームNotcoinを上場させ、全流通トークン経済モデルによる巨大な富の効果が発生したことで、短期間でTONは大きな注目を集めた。友人と話す中で、TONの技術的ハードルが高く、DApp開発のパラダイムも主流のブロックチェーンプロトコルと大きく異なることがわかったため、関連するトピックについて深く研究し、いくつかの知見を得たので、ここに共有したい。要するに、TONの核心的な設計思想とは、「下から上へ」というアプローチで従来のブロックチェーンプロトコルを再構築し、相互運用性を犠牲にしてでも高並列処理能力と高い拡張性を極限まで追求することにある。
TONの核心設計思想――高並列処理と高拡張性
こう言えるだろう。TONにおけるすべての複雑な技術選定は、高並列処理と高拡張性の追求に起因している。その誕生背景を見てもそれは明らかである。TON（The Open Network）は、L1ブロックチェーンと複数のコンポーネントからなる分散型コンピューティングネットワークである。TONは当初、Telegramの創設者Nikolai Durov氏とそのチームによって共同開発されたが、現在では世界中の独立した貢献者コミュニティによってサポート・維持されている。その起源は2017年にさかのぼり、Telegramチームが自らのためのブロックチェーンソリューションを探求し始めたのが始まりである。当時、Telegramの桁違いのユーザー数（9桁）を支えられる既存のL1ブロックチェーンは存在しなかったため、彼らは独自のブロックチェーンを設計することを決定した。それが当初「Telegram Open Network」と呼ばれていたものである。2018年になり、TON実現に必要なリソースを得るため、Telegramは2018年第1四半期にGramトークン（後にToncoinに改名）の販売を行った。しかし2020年、規制上の問題からTelegramチームはTONプロジェクトから撤退した。その後、少数のオープンソース開発者とTelegramコンテストの優勝者がTONのコードベースを受け継ぎ、プロジェクト名をThe Open Networkに変更して、オリジナルの白書に記載された原則に従って今日まで積極的に開発を続けている。
したがって、Telegramの分散型実行環境としての設計目標がある以上、当然ながら二つの課題に直面する。すなわち、高頻度の同時リクエストと膨大なデータ量である。技術の進展により、TPS（1秒あたりのトランザクション数）が最高とされるSolanaですら、実測での最高TPSはわずか65,000に過ぎない。これはTelegramエコシステムが求める百万レベルのTPSには到底不十分である。同時に、Telegramの大規模な利用に伴い、生成されるデータ量はすでに天文学的レベルに達しており、ブロックチェーンという極めて冗長な分散システムにおいて、ネットワーク内のすべてのノードが完全なデータのコピーを保持することは非現実的である。
そのため、上記二つの問題を解決するために、TONは主流のブロックチェーンプロトコルに対して以下の二点で最適化を行っている。
-
「無限シャーディングパラダイム」（Infinite Sharding Paradigm）を採用することで、データ冗長性の問題を解決し、大規模データの処理を可能とするとともに、パフォーマンスボトルネックの緩和を図る。
-
Actorモデルに基づく完全並列実行環境を導入することで、ネットワークの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にメッセージを送信したいとする。この場合、メッセージルーティングの問題が発生する。この例では二つのルーティングパスが存在する：ワーキングチェーン1 → ワーキングチェーン2 → ワーキングチェーン3、およびワーキングチェーン1 → ワーキングチェーン4 → ワーキングチェーン3。
より複雑な状況では、効率的かつ低コストのルーティングアルゴリズムが必要となり、TONは「ハイパーキューブルーティングアルゴリズム」を採用して、クロスチェーンメッセージのルーティング発見を実現している。ハイパーキューブ構造とは、特殊なネットワークトポロジーであり、n次元ハイパーキューブは2^n個の頂点からなり、各頂点はnビットのバイナリ数で一意に識別される。この構造では、二つの頂点がバイナリ表現で1ビットのみ異なる場合、それらは隣接していると見なされる。例えば、3次元ハイパーキューブでは、頂点000と頂点001は末尾の1ビットのみ異なるため隣接している。前述の例は2次元ハイパーキューブである。
ハイパーキューブルーティングプロトコルでは、メッセージの送信元ワーキングチェーンから目的のワーキングチェーンへのルーティングは、両者のアドレスのバイナリ表現を比較することで行われる。ルーティングアルゴリズムは、この二つのアドレス間の最小距離（つまり、バイナリ表現で異なるビット数）を見つけ出し、隣接するワーキングチェーンを介して段階的にメッセージを転送し、最終的に目的のチェーンに到達する。この方法により、データパケットが最短経路で転送され、ネットワークの通信効率が向上する。
もちろん、このプロセスを簡素化するため、TONは楽観的な技術ソリューションも提案している。ユーザーが特定のルーティングパスの有効な証明（通常はMerkle Trieのルート）を提供できる場合、ノードはそのユーザーが提出したメッセージの信頼性を即座に認めることができる。これは「インスタントハイパーキューブルーティング」と呼ばれる。
したがって、TONのアドレスは他のブロックチェーンプロトコルと明確に異なる点がわかる。他の主流プロトコルでは、楕円曲線暗号で生成された公開鍵のハッシュをアドレスとして使用する。なぜなら、アドレスは一意性の識別にしか使われず、ルーティング機能を担う必要がないからである。一方、TONのアドレスは二つの部分からなる：(workchain_id, account_id)。ここで、workchain_idはハイパーキューブルーティングアルゴリズムに従って符号化されており、ここでの詳細な説明は省略する。
また、疑問に思う点として、マスターチェーンと各ワーキングチェーンには接続関係があるため、すべてのクロスチェーン情報をマスターチェーンを中継して伝送すればよいのではないか、Cosmosのように、というのがある。しかし、TONの設計理念では、マスターチェーンは多数のワーキングチェーンの最終性を維持するという最も重要なタスクのみを処理する。メッセージをマスターチェーン経由でルーティングすることも不可能ではないが、その際に発生する手数料は非常に高額になる。
最後に、そのコンセンサスアルゴリズムについて簡単に触れておく。TONはBFT＋PoS方式を採用しており、任意のステーカーがブロック生成に参加できる可能性がある。TONの選挙ガバナンスコントラクトは定期的に、すべてのステーカーの中からランダムにブロック生成検証者クラスターを選出する。選ばれた検証者ノードはBFTアルゴリズムを使ってブロックを生成する。誤った情報を生成したり悪意のある行動を取った場合は、ステークされたトークンが没収され、逆に正しくブロックを生成した場合は報酬を得る。これはすでに比較的一般的な選択肢であり、ここでの詳述は省く。
Actorモデルに基づくスマートコントラクトと完全並列実行環境
TONのもう一つの主流ブロックチェーンプロトコルとの相違点は、スマートコントラクトの実行環境にある。主流プロトコルのTPS制限を突破するため、TONは「下から上へ」という設計思想を取り入れ、Actorモデルを用いてスマートコントラクトとその実行方法を再構築し、完全な並列実行能力を実現している。
我々が知る限り、主流のブロックチェーンプロトコルの多くはシングルスレッドの逐次実行環境を採用している。例えばイーサリアムの場合、実行環境であるEVMは取引を入力とするステートマシンであり、ブロック生成ノードが取引の順序を決定した後、その順序に従ってEVM上で取引を実行する。このプロセスは完全に逐次的かつシングルスレッドであり、同時に一度に一つの取引しか実行できない。この方式の利点は、取引順序が確定すれば、広範な分散クラスタ内で実行結果が一貫することにある。同時に、一度に一つの取引しか実行されないため、実行中に他の取引が特定の状態データを変更する可能性がなく、スマートコントラクト間の相互運用性が実現される。例えばUniswapでUSDTを使ってETHを購入する場合、その取引時にLPの分布状況が確定値となるため、数学モデルを用いて正確な結果を導き出せる。しかし、もし実行中に別のLPが新たな流動性を追加した場合、bonding curveの計算結果は古くなったものとなり、受け入れがたい結果となる。
しかし、このアーキテクチャにも明らかな限界があり、それがTPSのボトルネックである。現代のマルチコアプロセッサ環境では、この制約は時代遅れに見える。最新のPCで古いPCゲーム（例：コマンド＆コンquer）をプレイするようなものだ。ユニット数が一定以上になると、依然として動作が重くなる。これはソフトウェアアーキテクチャの問題である。
一部のプロトコルがこの問題に着目し、独自の並列化ソリューションを提示していることに気づくかもしれない。現在TPS最高とされるSolanaも並列実行機能を持っている。ただし、その設計思想はTONとは異なる。Solanaの核心は、すべての取引を実行依存関係に基づいてグループ分けし、異なるグループ間では状態データを共有しないようにするというものである。つまり、依存関係がなければ、異なるグループの取引は並列に実行でき、衝突の心配がない。一方、同じグループ内の取引については、従来通り逐次実行される。
一方、TONは逐次実行アーキテクチャを完全に放棄し、並列処理専用の開発パラダイムであるActorモデルを採用して実行環境を再構築している。Actorモデルは1973年にCarl Hewittによって初めて提唱され、従来の並列プログラムにおける共有状態の複雑さをメッセージパッシングで解決することを目的としている。各Actorは独自のプライベート状態と振る舞いを持ち、他のActorと状態情報を共有しない。Actorモデルは並列計算の計算モデルであり、メッセージパッシングによって並列処理を実現する。このモデルにおいて、「Actor」は基本的な作業単位であり、受信したメッセージの処理、新しいActorの生成、さらなるメッセージの送信、次のメッセージに対する応答方法の決定などを行う。Actorモデルは以下の特性を持つ必要がある。
-
カプセル化と独立性：各Actorはメッセージ処理において完全に独立しており、並列処理しても互いに干渉しない。
-
メッセージパッシング：Actor間のインタラクションは、メッセージの送受信のみで行われ、メッセージパッシングは非同期的である。
-
動的構造：Actorは実行時に新たなActorを生成でき、この動的性により、必要に応じてシステムを拡張できる。
TONはこのアーキテクチャを採用してスマートコントラクトモデルを設計しており、つまりTONでは各スマートコントラクトが一つのActorモデルであり、完全に独立したストレージ空間を持つ。外部データに依存しない。さらに、同一スマートコントラクトへの呼び出しは、受信キュー内のメッセージ順に実行されるため、TONの取引は効率的に並列実行でき、競合の心配がない。
しかし、このような設計案は新たな影響ももたらす。DApp開発者にとっては、これまでの開発習慣が壊されることになる。具体的には以下の通り。
1. スマートコントラクト間の非同期呼び出し：TONでは、スマートコントラクト内部から外部コントラクトを原子的に呼び出したり、外部コントラクトのデータにアクセスすることはできない。Solidityでは、コントラクトAのfunction1からコントラクトBのfunction2を呼び出す、あるいは読み取り専用のfunction3を通じてコントラクトCの状態データにアクセスするといった操作は、一つのトランザクション内で原子的に実行されることは容易である。しかし、TONではこれが不可能であり、外部スマートコントラクトとのあらゆるやり取りは、新しいトランザクションをパッケージングして非同期に実行される。スマートコントラクトが発行するこのようなトランザクションは「内部メッセージ」と呼ばれる。また、実行中に結果を待つためにブロッキングすることはできない。
例えばDEXを開発する場合、EVMで一般的なパターンでは、通常、取引ルーティングを管理する統一されたrouterコントラクトがあり、各Poolは特定の取引ペアのLPデータを個別に管理している。現在、USDT-DAIとDAI-ETHの二つのプールがあるとする。ユーザーがUSDTで直接ETHを購入したい場合、routerコントラクトを通じて一回のトランザクションで順次二つのプールにリクエストし、原子的取引を完了できる。しかし、TONではそう簡単には実現できない。新しい開発パラダイムを考える必要がある。もし従来のパターンを再利用するなら、情報の流れは次のようになるだろう。このリクエストは、ユーザーが発行するexternal messageと三つのinternal messageによって完了する（これは差異を説明するための例であり、実際の開発ではERC20のパターンすら再設計する必要があることに注意）。
2. スマートコントラクト間の呼び出しで実行エラーが発生した場合の処理フローを慎重に考慮し、各コントラクト呼び出しに応じたバウンス（bounce）関数を設計する必要がある。主流のEVMでは、取引実行中に問題が発生した場合、トランザクション全体がロールバックされ、初期状態に戻される。これは逐次シングルスレッドモデルでは理解しやすい。しかし、TONではコントラクト間の呼び出しが非同期で行われるため、後続の処理でエラーが発生しても、すでに成功した前の取引は実行・確定済みであるため、問題が生じる可能性がある。そのため、TONでは「バウンスメッセージ」という特殊なメッセージタイプを設けている。ある内部メッセージが引き起こした後続の処理でエラーが発生した場合、トリガーされたコントラクトは、トリガー元コントラクトに予め用意されたバウンス関数を呼び出して、トリガー元コントラクトの特定の状態をリセットできる。
3. 複雑な状況では、先に受信された取引が必ずしも先に実行完了するとは限らないため、このような時系列関係を前提にしないこと。このような非同期かつ並列なスマートコントラクト呼び出しシステムでは、操作順序の定義が難しい。そのため、TONでは各メッセージに論理時間（Lamport time、以下ltと略称）が割り当てられている。これにより、どのイベントが他を引き起こしたか、検証者が何を優先して処理すべきかを理解できる。単純なモデルでは、先に受信された取引は必ず先に実行完了する。
このモデルでは、AとBがそれぞれ二つのスマートコントラクトを表し、msg1_lt < msg2_lt ならば tx1_lt < tx2_lt の時系列関係が成り立つ。
しかし、より複雑な状況では、このルールは破られることがある。公式ドキュメントには次のような例がある。三つのコントラクトA、B、Cがあるとする。ある取引の中で、Aは二つの内部メッセージmsg1とmsg2を送信する：一つはB宛、もう一つはC宛である。これらは厳密な順序で作成されている（先にmsg1、次にmsg2）が、msg1がmsg2より先に処理される保証はない。なぜなら、AからB、AからCへのルーティングは長さや検証者セットが異なる可能性があるためである。これらのコントラクトが異なるシャードチェーンにある場合、一方のメッセージは数ブロックかけて対象コントラクトに到達する可能性がある。つまり、図に示すような二つの可能な取引経路が存在する。
4. TONでは、スマートコントラクトの永続化ストレージに、Cellを単位とする有向非巡回グラフ（DAG）をデータ構造として採用している。データはエンコードルールに従って圧縮され、Cellに格納され、DAGの形で下層に拡張していく。これはEVMのハッシュマップに基づく状態データ構造とは異なる。データ要求アルゴリズムが異なるため、TONでは深さの異なるデータ処理に異なるGas価格を設定しており、Cellの深さが深いほど必要なGasが高くなる。したがって、TONにはある種のDoS攻撃のパターンが存在する。悪意のあるユーザーが大量のゴミメッセージを送信し、特定のスマートコントラクト内のすべての浅いCellを占有することで、誠実なユーザーのストレージコストがますます高くなる。一方、EVMではハッシュマップの検索複雑度がO(1)のため、Gasは常に一定であり、同様の問題は発生しない。したがって、TONのDApp開発者は、スマートコントラクト内に無境界データ型が現れないよう注意すべきである。無境界データ型が発生する場合は、シャーディングによって分散させるべきである。
5. その他、あまり特異ではないが留意すべき特徴もある。例えば、スマートコントラクトはストレージに対して家賃を支払う必要がある。TONではスマートコントラクトは本質的にアップグレード可能であり、ネイティブな抽象アカウント機能も備えている。つまり、TONではすべてのウォレットアドレスがスマートコントラクトであり、ただ初期化されていないだけである。これらも開発者が注意すべき点である。
以上が、私が最近TONに関する技術を学んだ中での所感であり、皆様と共有したい。誤りがあればご指摘いただければ幸いである。同時に、Telegramが持つ莫大なトラフィックリソースを背景に、TONエコシステムはWeb3に全く新しいアプリケーションをもたらすと私は信じている。TONのDApp開発に興味のある方は、ぜひ私に連絡いただき、一緒に議論しましょう。
@web3_mario
