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

著者: @Web3Mario

はじめに

TONエコシステムにおけるCoinSafe最大のゲーム「Notcoin」のローンチと、完全流通トークン経済モデルによって引き起こされた巨大な富の効果により、TONはTONは短期間で大きな注目を集めた。友人と話した後、TONの技術的な敷居が比較的高いこと、DAppの開発パラダイムが主流のパブリックチェーンプロトコルとは大きく異なることを知りました。要するに、TONの中核となる設計コンセプトは、伝統的なブロックチェーン・プロトコルを「ボトムアップ」方式で再構築し、相互運用性を犠牲にしてでも高い同時実行性とスケーラビリティを究極まで追求することです。

TONの中核となる設計思想 - 高い並行性とスケーラビリティ

TONにおける複雑な技術的選択はすべて、高い並行性とスケーラビリティの追求から生まれたと言えますが、これはその誕生の背景から理解するのは難しくありません。TON（オープン・ネットワーク）は、L1ブロックチェーンと複数のコンポーネントを含む分散型コンピューティング・ネットワークである。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の実測最大TPSは65,000に過ぎず、Telegramの100万TPSの要件をサポートするには明らかに不十分であることがわかっています。エコシステム同時に、Telegramの大規模なアプリケーションでは、生成されるデータ量はすでに空を超え、ブロックチェーンは非常に冗長な分散システムとして、ネットワーク内のすべてのノードに完全なデータを保存するように求めると、これも非現実的です。

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

• 無限シャーディングパラダイムを採用することで、TONはブロックチェーンプロトコルをより効率的に設計しました。シャーディングパラダイム」の設計システムにより、データの冗長性問題を解決し、パフォーマンスのボトルネックを緩和しながらビッグデータを運ぶことができます。

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

次のことを行います。ブロックチェーンの連鎖 - 無限のシャーディング機能を通じて、各アカウントに排他的な連鎖を与える

私たちは、シャーディングがほとんどのブロックチェーンプロトコルで、パフォーマンスを向上させコストを削減するための主流のソリューションになっていることを知っています！TONは、ブロックチェーンがネットワーク負荷に基づいてシャードの数を動的に増減できるようにする無限シャーディングパラダイムを導入することで、これを次のレベルに引き上げました。このパラダイムにより、TONは高いパフォーマンスを維持しながら、大規模なトランザクションやスマートコントラクトの操作を処理することができます。 理論的には、TONはアカウントごとに排他的なアカウントチェーンを作成し、特定のルールによってこれらのチェーン間の一貫性を確保することができます。

抽象的に言えば、TONには合計4層のチェーン構造があります。paddingleft-2">

• ShardChain: ほとんどの文脈において、シャードチェーンはTONの実際の単位であり、アカウントチェーンの集合体です。

• WorkChain: これはカスタムルールを持つシャードチェーンのセットとも言えます。SmartContracts。理論的には、コミュニティの誰もが自分の作業チェーンを作成することができます。実際、作業チェーンの作成はかなり複雑な作業であり、作成に必要な(高価な)料金を支払い、バリデータから作業チェーンの作成を承認する2/3の投票を得る必要があります。

• MasterChain: 最後に、TONにはMasterChainと呼ばれる特別なチェーンがあります。断片化されたチェーンのブロックのハッシュがMasterChainのブロックにマージされると、断片化されたブロックとそのすべての親は最終的なものとみなされます。つまり、それらは固定された不変のものとみなすことができ、断片化されたチェーンの後続のすべてのブロックによって参照されます。

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

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

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

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

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

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

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

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

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

したがって、TONと他のブロックチェーンプロトコルのアドレスには明らかな違いがあることがわかります。他の主流のブロックチェーンプロトコルのほとんどは、アドレスは区別の一意性を行うだけであり、ルーティングアドレスの機能を運ぶ必要がないため、アドレスとしてハッシュに対応する公開鍵および秘密鍵を生成するために楕円暗号化アルゴリズムを使用し、TONは、2つの部分のアドレス、（workchain_id、account_id。id、account_id）のうち、workchain_idはハイパーキューブルーティングアルゴリズムのアドレスに従って符号化されるが、ここでは詳細な説明を省略する。

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

最後に、そのコンセンサス・アルゴリズムについて簡単に触れたいと思います。TONはBFT+PoS方式を採用しており、どのステーカーにもブロック・パッキングに参加する機会があります。パッケージ化されたノードが誤報や悪事を働いた場合、そのステーク・トークンは没収され、逆にブロックをパッケージ化したノードには報酬が与えられます。これは基本的に十分に一般的な選択なので、ここでは拡大しません。

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

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

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

しかし、このアーキテクチャにも明確な限界があり、それはTPSのボトルネックです。このボトルネックは、現在のマルチコアプロセッサでは古く見えます。ちょうど、最新のPCを使って、レッドアラートのような古いコンピュータゲームをプレイすると、戦闘ユニットが一定数あるときに、まだ動かないことに気づくように、これはソフトウェアアーキテクチャの問題です。

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

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

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

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

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

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

しかし、この設計ソリューションは、DApp開発者に以下のような、慣習的な開発パラダイムを壊すような、まったく新しい意味合いももたらします:

1.スマートコントラクト間の非同期呼び出し: TONのスマートコントラクト内で、外部コントラクトをアトミックに呼び出したり、外部コントラクトデータにアクセスしたりする方法はありません。Solidityでは、コントラクトAがコントラクトBのファンクション2をファンクション1で呼び出したり、コントラクトCの読み取り専用ファンクション3を通してステートデータにアクセスしたりするのは非常に簡単で、プロセス全体がアトミックで単一のトランザクションで実行されることを知っています。スマート・コントラクトによって開始されるこのトランザクションは、内部メッセージとしても知られている。スマートコントラクトによって開始されたこのトランザクションは内部メッセージとしても知られており、実行中にブロックして実行結果を得ることはできません。

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

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

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

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

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

4.TONでは、スマートコントラクト用の永続ストレージとして、Cellベースのこれは、EVMのハッシュマップに基づく状態データの構造組織とは異なります。データ要求アルゴリズムの違いにより、TONではデータ処理の深さに応じて異なるガス価格を設定しています。つまり、悪意のあるユーザーが大量のスパムメッセージを送信することで、あるスマートコントラクトの浅いセルをすべて占有してしまい、正直なユーザーのストレージコストがどんどん高くなってしまうのです。一方、EVMでは、ハッシュマップのクエリ複雑度はo(1)であるため、同じガスを持っており、同様の問題は発生しない。そのため、TON Dappの開発者は、スマートコントラクトにおいて未束縛のデータ型を避けるようにすべきである。非束縛データ型が現れたら、それらはスライスによって分割されるべきである。

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