共有する

TONの技術的特徴とスマートコントラクト開発のパラダイムについて詳述する

2024-06-11 09:57:51

コレクション

簡単に言えば、TONの核心設計理念は「ボトムアップ」の方法で従来のブロックチェーンプロトコルを再構築し、相互運用性を犠牲にすることで高い同時処理能力と高いスケーラビリティの極致を追求することです。

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

TONの核心設計思想------高同時処理能力と高スケーラビリティ

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

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

「無限分割パラダイム」（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にメッセージを送信したい場合、メッセージルーティングの問題が関与します。この例では、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アルゴリズムを使用してブロックをパッケージングし、誤った情報をパッケージングしたり悪行を行った場合、そのステークのトークンは没収され、逆にブロック生成の報酬を得ることになります。これは基本的に比較的一般的な選択であるため、ここでは詳しく説明しません。

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

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

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

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

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

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

カプセル化と独立性：各Actorはメッセージを処理する際に完全に独立しており、メッセージを並行して処理しても互いに干渉しません。
メッセージ伝達：Actor間の相互作用は、メッセージの送受信を通じてのみ行われ、メッセージ伝達は非同期です。
動的構造：Actorは実行時にさらに多くのActorを作成でき、この動的性がActorモデルを必要に応じて拡張可能にします。

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

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

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

たとえば、DEXを開発する場合、EVMで一般的なパラダイムを採用すると、通常、取引ルーティングを管理するための統一されたルーターコントラクトがあり、各プールは特定の取引ペアに関連するLPデータを個別に管理します。ユーザーがUSDTを介してETHを直接購入したい場合、ルーターコントラクトを通じて1つの取引内で順番にこの2つのプールにリクエストを行い、原子的な取引を完了できます。しかし、TONではこれを実現するのは容易ではありません。新しい開発パラダイムを考える必要があります。もしこのパラダイムを再利用する場合、情報の流れは次のようになります。このリクエストは、ユーザーが発起したexternal messageと3つのinternal messagesを伴って完了します（これは差異を説明するためのものであり、実際の開発ではERC20のパラダイムさえも再設計する必要があります）。

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

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

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

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

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

その他の特徴はそれほど特異ではありません。たとえば、スマートコントラクトはストレージのために賃料を支払う必要があり、TONではスマートコントラクトは自然にアップグレード可能であり、ネイティブの抽象アカウント機能、すなわちTONではすべてのウォレットアドレスがスマートコントラクトであることなどです。ただし、未初期化のものもあります。これらは開発者が注意を払う必要があります。

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

リスク警告