原作者： @Web3マリオ
はじめに: TON エコシステムの最大のゲームである Notcoin が Binance 上でリリースされ、完全に循環するトークン経済モデルによって引き起こされる莫大な富効果により、TON は短期間で大きな注目を集めました。友人とチャットした後、TON の技術的敷居は比較的高く、DApp 開発パラダイムは主流のパブリック チェーン プロトコルとは大きく異なることがわかりました。そのため、時間をかけて関連トピックについて徹底的に調査し、いくつかの洞察を共有しました。つまり、TON の中心となる設計コンセプトは、従来のブロックチェーン プロトコルを「ボトムアップ」方式で再構築し、相互運用性を犠牲にして高い同時実行性と高いスケーラビリティを実現するという究極の追求です。
TON の核となる設計思想 - 高い同時実行性と高いスケーラビリティ
TON におけるすべての複雑なテクノロジーの選択の目的は、高い同時実行性と高いスケーラビリティの追求から来ていると言えます。これは、その誕生の背景から理解するのが難しいことではありません。 TON (オープン ネットワーク) は、L1 ブロックチェーンと複数のコンポーネントを含む分散型コンピューティング ネットワークです。 TON はもともと Telegram の創設者 Nikolai Durov と彼のチームによって開発されましたが、現在は独立した貢献者の世界的なコミュニティによってサポートおよび維持されています。その誕生は、Telegram チームが独自にブロックチェーン ソリューションを模索し始めた 2017 年に遡ります。当時、既存の L1 ブロックチェーンは Telegram の 9 桁のユーザー ベースをサポートできなかったため、彼らは独自のブロックチェーンを設計することを決定し、当時 Telegram Open Network と呼ばれていました。時は 2018 年になりました。TON の実装に必要なリソースを入手するために、テレグラムは 2018 年の第 1 四半期にグラム トークン (後にトンコインと改名) の販売を開始しました。 2020 年、規制上の問題により Telegram チームは TON プロジェクトから撤退しました。その後、オープンソース開発者と Telegram コンペティションの優勝者の小グループが TON のコード ベースを引き継ぎ、プロジェクトの名前を The Open Network に変更し、元の TON ホワイト ペーパーで概説されている原則を遵守しながら、今日に至るまで積極的にブロックチェーンの開発を続けています。
Telegram の分散実行環境として設計されているため、最高の TPS として知られる Solana は、現在までのテクノロジーの発展により、当然のことながら、高い同時リクエストと大量のデータという 2 つの問題に直面する必要があります。測定された最大 TPS は 65,000 ですが、これは明らかに数百万の TPS を必要とする Telegram エコシステムをサポートするには十分ではありません。同時に、テレグラムの大規模なアプリケーションにより、ブロックチェーンが生成するデータの量はすでに膨大になっており、非常に冗長な分散システムとして、ネットワーク内のすべてのノードがデータの完全なコピーを保存する必要があります。非現実的でもあります。
したがって、上記の 2 つの問題を解決するために、TON は主流のブロックチェーン プロトコルに対して 2 つの最適化を行いました。
「無限シャーディング パラダイム」を採用してシステムを設計することで、データの冗長性の問題を解決し、ビッグデータを伝送できるようにし、パフォーマンスのボトルネックの問題を軽減します。
アクター モデルに基づく完全な並列実行環境を導入することにより、ネットワーク TPS が大幅に向上します。
ブロックチェーン チェーンを作成する - 無制限のシャーディング機能により、各アカウントに専用のアカウント チェーンが存在します。
現在、ほとんどのブロックチェーン プロトコルでは、シャーディングがパフォーマンスの向上とコスト削減のための主流のソリューションになっていることがわかっています。TON はこれを極限まで推し進め、無限シャーディング パラダイム、いわゆる無限シャーディング パラダイムを提案しました。ネットワーク負荷に基づいてシャードの数を動的に増減します。このパラダイムにより、TON は高いパフォーマンスを維持しながら大規模なトランザクションとスマート コントラクトの操作を処理できるようになり、各アカウントに専用のアカウント チェーンを確立し、特定のルールを通じてこれらのチェーン間の相互運用性を確保できます。
抽象的に理解すると、TON には合計 4 つのレベルのチェーン構造があります。
アカウント チェーン: このレイヤー チェーンは、アカウントに関連する一連のトランザクションで構成されるチェーンを表します。トランザクションがチェーン構造を形成できる理由は、ステート マシンでは、実行ルールが一貫している限り、同じシーケンスで命令を受け取った後に得られる結果は一貫しているため、トランザクションの連鎖順序付けはすべてのブロックチェーン分散システムで必要であり、TON も例外ではありません。アカウント チェーンは、TON ネットワークの最も基本的なコンポーネント単位です。通常、アカウント チェーンは仮想概念であり、独立したアカウント チェーンが実際に存在することは考えられません。
シャード チェーン: ほとんどの場合、シャード チェーンは TON の実際のコンポーネント単位であり、アカウント チェーンの集合です。
WorkChain: EVM ベースのワーク チェーンを作成し、その上で Solidity スマート コントラクトを実行するなど、カスタム ルールを備えた一連のシャーディング チェーンと呼ぶこともできます。理論的には、コミュニティの全員が独自の作業チェーンを作成できます。実際、それを作成するために (高価な) 料金を支払い、バリデーターの投票の 2/3 を獲得して作業チェーンの作成を承認する前に、それを構築するのはかなり複雑な作業です。
メインチェーン (MasterChain): 最後に、TON にはメインチェーンと呼ばれる特別なチェーンがあり、すべてのシャード チェーンにファイナリティをもたらす役割を果たします。シャード チェーンのブロックのハッシュがメイン チェーンのブロックにマージされると、そのシャード チェーン ブロックとそのすべての親ブロックは最終的なものとみなされ、変更されたコンテンツはすべてのシャードの後続のブロックによって参照されることになります。鎖。
このようなパラダイムを採用することにより、TON ネットワークは次の 3 つの特徴を備えています。
動的シャーディング: TON は、負荷の変化に適応するためにシャード チェーンを自動的に分割およびマージできます。これは、新しいブロックが常に迅速に生成され、トランザクションに長い待ち時間が発生しないことを意味します。
高いスケーラビリティ: 無限シャーディング パラダイムを通じて、TON はほぼ無制限の数のシャードをサポートでき、理論的には 2 の 60 乗に達するワーク チェーンを実現できます。
適応性: ネットワークの一部で負荷が増加した場合、その部分をより多くのシャードに分割して、トランザクション量の増加に対処できます。逆に、負荷が減少すると、シャードをマージして効率を高めることができます。
このようなマルチチェーン システムが最初に直面する必要があるのは、特に無制限のシャーディング機能によるクロスチェーン通信の問題です。ネットワーク内のシャードの数が一定のレベルに達すると、チェーン間の情報ルーティングが困難になります。難しいことになります。ネットワーク内に 4 つのノードがあり、各ノードが独立したワーク チェーンを維持する責任があると想像してください。リンク関係は、ノードが独自のワーク チェーン内でトランザクションをソートする責任に加えて、状態を監視および処理する必要があることを示しています。ターゲット チェーンの変更。これは、出力キュー内のメッセージを監視することによって TON に具体的に実装されます。
ワーク チェーン 1 のアカウント A がワーク チェーン 3 のアカウント C にメッセージを送信したいとします。この例では、ワーク チェーン 1 -> ワーク チェーン 2 -> ワーク チェーン 3、およびワーク チェーン 1 -> ワーク チェーン 4 -> ワーク チェーン 3 の 2 つのルーティング パスが存在します。
より複雑な状況に直面した場合、メッセージ通信を迅速に完了するには、効率的で低コストのルーティング アルゴリズムが必要です。TON は、クロスチェーン メッセージ通信ルートの発見を実現するために、いわゆる「ハイパーキューブ ルーティング アルゴリズム」を選択しました。いわゆるハイパーキューブ構造とは、n 次元のハイパーキューブは 2^n 個の頂点で構成され、各頂点は n ビットの 2 進数で一意に識別できます。この構造では、バイナリ表現で 1 ビットだけ異なる場合、任意の 2 つの頂点は隣接しています。たとえば、3 次元のハイパーキューブでは、頂点 000 と 001 は最後のビットのみが異なるため、隣接しています。上の例は 2 次元の超立方体です。
ハイパーキューブ ルーティング プロトコルでは、ソース ワーク チェーンからターゲット ワーク チェーンへのメッセージのルーティング プロセスは、ソース ワーク チェーンのバイナリ表現とターゲット ワーク チェーンのアドレスを比較することによって実行されます。ルーティング アルゴリズムは、これら 2 つのアドレス間の最小距離 (つまり、バイナリ表現内の異なるビットの数) を見つけ、ターゲットのワーク チェーンに到達するまで、隣接するワーク チェーンを通じて情報を段階的に転送します。この方法により、データ パケットが最短経路で送信されるため、ネットワークの通信効率が向上します。
もちろん、このプロセスを簡素化するために、TON は、ユーザーが特定のルーティング パス (通常はマークル トライ ルート) の有効な証明を提供できる場合、ノードはその信頼性を直接認識できるという楽観的な技術ソリューションも提案しています。ユーザーによって送信されたメッセージのプロパティ。これはインスタント ハイパーキューブ ルーティングとも呼ばれます。
したがって、TON と他のブロックチェーン プロトコルのアドレスには明らかな違いがあることがわかります。他のほとんどの主流ブロックチェーン プロトコルでは、楕円暗号化アルゴリズムによって生成された公開鍵と秘密鍵の公開鍵に対応するハッシュがアドレスとして使用されます。アドレスは一意のアドレスとしてのみ使用され、ルーティング アドレッシング機能を実行する必要はありません。TON のアドレスは 2 つの部分 (workchain_id、account_id) で構成されます。workchain_id はハイパーキューブ ルーティング アルゴリズムのアドレスに従ってエンコードされます。ここでは詳しく説明しません。
もう 1 つ疑問が生じやすい点があります。メイン チェーンには各動作チェーンとのリンク関係があるため、すべてのクロスチェーン情報がメイン チェーンを介して中継されれば十分ではないでしょうか。コスモスのように。 TON の設計コンセプトでは、メイン チェーンは最も重要なタスク、つまり多くのワーク チェーンのファイナリティを維持するためにのみ使用されます。メイン チェーンを介してメッセージをルーティングすることは不可能ではありませんが、その結果として発生する処理料金は非常に高価になります。 。
最後に、TON は BFT+PoS 方式を採用しています。つまり、TON の選挙ガバナンス契約により、定期的にすべてのステーカーからパッケージング検証者がランダムに選択されます。クラスターでは、バリデーターとして選択されたノードは、BFT アルゴリズムを通じてブロックをパッケージ化して生成します。間違った情報をパッケージ化したり、悪事を行った場合、ステーク トークンは没収され、そうでない場合はブロック報酬を受け取ります。これは基本的に一般的な選択ですので、ここでは紹介しません。
アクターモデルに基づくスマートコントラクトと完全並列実行環境
TON と主流のブロックチェーン プロトコルのもう 1 つの違いは、スマート コントラクトの実行環境です。主流のブロックチェーン プロトコル TPS の制限を突破するために、TON はボトムアップの設計アイデアを採用し、アクター モデルを使用してスマート コントラクトとその実行メソッドを再構築し、完全に並列化できる機能を提供します。
イーサリアムを例にとると、その実行環境の EVM は、ブロック生成ノードがソート後にブロックをパッケージ化することでトランザクションを完了するステートマシンです。 、トランザクションは EVM を介してこの順序で実行されます。プロセス全体が完全にシリアルかつシングルスレッドです。つまり、トランザクション シーケンスが一定である限り、一度に 1 つのトランザクションのみを実行できるという利点があります。広範囲の分散クラスタで一貫性が保たれます。同時に、同時に 1 つのトランザクションだけが直列に実行されるため、実行プロセス中に他のトランザクションが実行されることはありません。アクセスする特定の状態データを変更して、スマート コントラクト間の相互運用性を実現します。たとえば、USDT を使用して Uniswap を通じて ETH を購入すると、取引ペアの LP の分布は特定の値になります。このように、対応する結果は特定の数学モデルを通じて取得できます。そうではなく、特定の結合曲線の計算を実行するときに、他の LP が新しい流動性を追加すると、計算結果は古い結果となり、これは明らかに許容できません。
しかし、このアーキテクチャには明らかな制限もあり、これが TPS のボトルネックであり、最新の PC を使用して Red Alert などの古いコンピュータ ゲームをプレイする場合と同じように、このボトルネックは現在のマルチコア プロセッサでは非常に古いものであるように見えます。戦闘ユニットの数が特定のレベルに達しても、まだスタックしていることがわかります。これはソフトウェア アーキテクチャの問題です。
一部のプロトコルはすでにこの問題に注目しており、独自の並列ソリューションを提案していると聞いたかもしれません。現在最高の TPS を実現していると主張している Solana には、並列実行機能もあります。ただし、Solana の設計思想は TON とは異なり、すべてのトランザクションを実行の依存関係に応じていくつかのグループに分割することが中心的な考え方であり、異なるグループ間でステータス データが共有されることはありません。つまり、同一の依存関係は存在しないため、異なるグループ内のトランザクションは競合を気にすることなく並行して実行できますが、同じグループ内のトランザクションは引き続き従来のシリアル方式で実行されます。
TON では、シリアル実行アーキテクチャを完全に放棄し、代わりに並列処理用に特別に設計された開発パラダイムであるアクター モデルを採用して実行環境を再構築します。いわゆるアクター モデルは、メッセージ パッシングを通じて従来の同時プログラムにおける共有状態の複雑さを解決するために、1973 年にカール ヒューイットによって初めて提案されました。各アクターは独自のプライベートな状態と動作を持ち、他のアクターと状態情報を共有しません。アクター モデルは、メッセージ パッシングを通じて並列コンピューティングを実装する同時コンピューティング コンピューティング モデルです。このモデルでは、「アクター」は基本的な作業単位であり、受信したメッセージの処理、新しいアクターの作成、追加のメッセージの送信、および後続のメッセージへの応答方法の決定を行うことができます。アクター モデルには次の特性が必要です。
カプセル化と独立性: 各アクターはメッセージを処理する際に完全に独立しており、相互に干渉することなくメッセージを並行して処理できます。
メッセージ パッシング: アクターはメッセージを送受信することによってのみ相互に対話し、メッセージ パッシングは非同期です。
動的構造: アクターは実行時にさらに多くのアクターを作成できるため、アクター モデルは必要に応じてシステムを拡張できます。
TON は、このアーキテクチャを採用してスマート コントラクト モデルを設計します。つまり、TON では、各スマート コントラクトは完全に独立したストレージ領域を持つアクター モデルになります。外部データに依存しないためです。さらに、同じスマート コントラクトへの呼び出しは受信キュー内のメッセージの順序に従って実行されるため、TON のトランザクションは競合を心配することなく効率的に並列実行できます。
ただし、このような設計スキームは、DApp 開発者にとって、次のように、慣れ親しんだ開発パラダイムにいくつかの新たな影響をもたらします。
1. スマート コントラクト間の非同期呼び出し: TON のスマート コントラクト内で外部コントラクトをアトミックに呼び出したり、外部コントラクト データにアクセスしたりすることはできません。Solidity では、コントラクト A の関数 1 がコントラクト B の関数 2 を呼び出したり、特定の状態データにアクセスしたりすることができます。コントラクト C の読み取り専用関数 n3 を使用します。プロセス全体はアトミックであり、1 つのトランザクションで実行されます。ただし、TON では、外部スマート コントラクトとのすべての対話は実行できません。新しいトランザクションをパッケージ化することで非同期に実行されます。スマート コントラクトによって開始されるこのようなトランザクションは、内部メッセージとも呼ばれます。また、実行中にブロックして実行結果を取得することはできません。
たとえば、DEX を開発する場合、EVM で共通パラダイムを採用すると、通常、トランザクション ルーティングを管理するために使用されるユニファイド ルーター コントラクトが存在し、各プールが特定の取引ペアに関連する LP データを独立して管理すると仮定します。現在、USDT-DAI と DAI-ETH の 2 つのプールがあります。ユーザーが USDT を通じて ETH を直接購入したい場合、ルーター コントラクトを通じて 1 つのトランザクションでこれら 2 つのプールを順番にリクエストし、アトミック トランザクションを完了できます。ただし、TON での実装はそれほど簡単ではありません。このパラダイムを引き続き使用する場合、このリクエストには外部メッセージが伴う可能性があります。ユーザーメッセージと 3 つの内部メッセージが完成します (これは違いを説明するために使用されていることに注意してください。実際の開発では、ERC 20 のパラダイムさえも再設計する必要があります)。
2. コントラクトをまたがる呼び出し時の実行エラーの処理プロセスを慎重に検討し、コントラクト間の呼び出しごとに対応するバウンス関数を設計する必要があります。主流の EVM では、トランザクションの実行中に問題が発生すると、トランザクション全体がロールバックされ、実行の初期状態にリセットされることがわかっています。これは、シリアル シングルスレッド モデルで理解するのが簡単です。ただし、TONではコントラクト間の呼び出しが非同期で実行されるため、後続のリンクでエラーが発生しても、以前に正常に実行されたトランザクションがすでに実行され確認されているため、問題が発生する可能性があります。したがって、バウンス メッセージと呼ばれる特別なメッセージ タイプが TON に設定されます。つまり、内部メッセージによってトリガーされた後続の実行プロセスでエラーが発生した場合、トリガーされたコントラクトはバウンスをトリガーすることでコントラクト内の特定のイベントをトリガーできます。契約により予約された機能。一部のステータスがリセットされます。
3. 一部の複雑な状況では、最初に受信したトランザクションが最初に実行されない可能性があるため、このタイミング関係を事前に設定することはできません。このような非同期かつ並列のスマート コントラクト呼び出しシステムでは、操作が処理される順序を定義することが難しい場合があります。これが、TON の各メッセージに論理時間 Lamport time (以下 lt と呼びます) がある理由です。これは、どのイベントが別のイベントをトリガーしたか、バリデーターが最初に何を処理する必要があるかを理解するために使用されます。単純なモデルの場合、最初に受信したトランザクションを最初に実行する必要があります。
このモデルでは、A と B はそれぞれ 2 つのスマート コントラクトを表し、msg 1 _lt < msg 2 _lt の場合、tx 1 _lt < tx 2 _lt となるようなタイミング関係があります。
ただし、より複雑な状況では、このルールは破られます。公式ドキュメントにこの例があります。A、B、C という 3 つの契約があるとします。トランザクションでは、A は 2 つの内部メッセージ msg 1 と msg 2 を送信します。1 つは B に、もう 1 つは C に送信されます。これらは正確な順序 (最初に msg 1、次に msg 2) で作成されますが、msg 1 が msg 2 より前に処理されるかどうかは保証できません。これは、A から B へのルートと A から C へのルートの長さとバリデータ セットが異なる可能性があるためです。これらのコントラクトが異なるシャード チェーン上にある場合、メッセージの 1 つがターゲット コントラクトに到達するまでに数ブロックかかる可能性があります。つまり、図に示すように、考えられる取引パスが 2 つあります。
4. TON では、スマート コントラクトの永続ストレージは、Cell をデータ構造の単位とする有向非巡回グラフを使用します。データは、エンコーディング ルールに従って、同時に Cell にコンパクトに圧縮されます。有向非循環グラフは、EVM のステータス データのハッシュマップベースの構造構成とは異なり、データ処理の深度に応じて異なるガス価格を設定します。つまり、一部の悪意のあるユーザーが大量のスパム メッセージを送信することで、特定のスマート コントラクト内のすべての浅いセルを占有します。正直なユーザーのストレージコストはますます高くなるでしょう。 EVM では、ハッシュマップのクエリ複雑度が O(1) であるため、Gas は同じであり、同様の問題は発生しません。したがって、TON Dapp 開発者は、スマート コントラクトで無制限のデータ型を避けるように努める必要があります。無制限のデータ型が表示された場合は、シャーディングによって分割する必要があります。
5. ストレージの使用料を支払う必要があるスマート コントラクトなど、特別ではない機能もいくつかあります。TON のスマート コントラクトは当然アップグレード可能で、ネイティブの抽象アカウント機能、つまり TON のすべてのウォレット アドレスはスマート コントラクトです。初期化されていないなど。開発者はこれらに細心の注意を払う必要があります。
上記は、この期間中に TON 関連のテクノロジーを学んだ私の経験の一部です。間違いがあれば、修正していただければ幸いです。 、TON エコシステムは間違いなく Web3 のプラットフォームとして機能します。いくつかの新しいアプリケーションを持ち込んで、TON DApp 開発に興味のある友人も私に連絡して話し合うことができます。
X リンク: https://x.com/web3_mario
電報ハンドル: @MarioChin Web3
