この記事は「Tokamak: A Significant Improvement in End-to-End Latency」を引用/翻訳しています。
アップデートコールは、Internet Computer Protocol（ICP）の中核的な操作であり、ユーザーがInternet Computer上でホストされているスマートコントラクトであるキャニスター内で変更を行うことを可能にします。この記事では、アップデートコールのライフサイクルの各段階を探り、Tokamakマイルストーンがそのエンドツーエンドのレイテンシーをどのように最適化したかを説明します。
背景
アップデートコールのライフサイクルを完全に理解するために、Internet Computerのアーキテクチャの基本的なコンポーネントをいくつか説明します
キャニスター
キャニスターは、Internet Computer Protocol (ICP)上のスマートコントラクトで、状態を保存しコードを実行します。ユーザーは、スマートコントラクト上でアクションを開始するアップデートコールを送信することでキャニスターと対話します。
サブネット
サブネットは、キャニスターをホストして管理するノードのグループです。各サブネットは独立したブロックチェーンネットワークとして機能し、負荷を複数のサブネットに分散することでICPのスケーリングを可能にし、それぞれが固有のキャニスターセットを管理します。あるサブネット上のスマートコントラクトは、メッセージを送信することで別のサブネット上の別のスマートコントラクトと通信できます。
レプリカ
各サブネット内で、レプリカと呼ばれるノードは、そのサブネット上のすべてのキャニスターのコードとデータを保存します。各レプリカはまた、キャニスターのコードを実行します。このストレージと計算の複製により、一部のノードがクラッシュしたり悪意のある行為者によって侵害されたりしても、キャニスタースマートコントラクトが確実に動作することを保証する耐障害性が確保されます。
バウンダリーノード
バウンダリーノードは、リクエストを適切なサブネットにルーティングし、そのサブネット内のレプリカ間で負荷を分散する責任があります。
アップデートコールのライフサイクル
以下の図は、Internet Computer Protocolにおけるアップデートコールのライフサイクルを概説しています。
Internet Computer (IC)がアップデートコールを受信 アップデートコールは、ICエージェント実装（例：agent-rsやagent-js）を使用してリクエストを送信するユーザーから始まります。これらのライブラリは、リクエストのフォーマット、署名、通信プロトコルを処理する、ユーザーフレンドリーなインターフェースを提供します。リクエストは、DNSを通じて解決されたバウンダリーノードに送信されます。
バウンダリーノードを通じたルーティング バウンダリーノードは、ターゲットキャニスターをホストしているサブネット内のレプリカにアップデートコールをルーティングします。ラウンドロビン選択アプローチにより、パフォーマンスと信頼性を確保するためにF+1レプリカ間でリクエスト負荷を分散します。ここで、Fは各サブネットで許容できる故障レプリカの最大数を表すICPの耐障害性閾値です。Internet Computerの耐障害性の詳細については、こちらのリンクを参照してください。
アップデートコールのブロードキャスト レプリカがアップデートコールを受信すると、中断可能なブロードキャストプリミティブを使用してサブネット内の他のレプリカにリクエストをブロードキャストします。この方法は、ネットワーク輻輳、ピアまたはリンクの障害、バックプレッシャーの場合でも、強力な配信保証を確保します。
中断可能なブロードキャストは、ビザンチン障害許容（BFT）環境でのレプリカ間通信の効率性にとって不可欠です。これは帯域幅を保持し、悪意のあるピアが存在する場合でもすべてのデータ構造が有界であることを保証し、ICP内での一貫したアップデート処理のための信頼できる通信を維持します。技術的な詳細については、中断可能なブロードキャストソリューションを説明する論文をこちらで参照できます。
ブロック提案（ブロック作成） ブロックメーカーとして指定された1つのレプリカが、アップデートコールを含む新しいブロックを作成する責任を負います。ブロックメーカーは、このブロックを処理のためにサブネット内の他のレプリカに提案します。
ステップ4から7は、レプリカが提案されたブロックについて合意に達するために協力するInternet Computer上のコンセンサスラウンドの段階を構成します。コンセンサスメカニズムの詳細な説明については、こちらで詳しく読むことができます。
公証遅延
公証遅延として知られる短い遅延が、ネットワークを同期させ、すべてのレプリカにブロック提案を受信する時間を与えるために導入されます。この遅延は、レプリカ間で一貫した状態を維持するために重要です。
公証
公証段階では、レプリカは提案されたブロックの有効性を確認し、それを公証することに同意します。公証は、ブロックがICPの基準を満たしていることを示す初期のコンセンサスステップです。
確定化
公証された後、ブロックは確定化を経ます - これは、サブネット内のすべてのレプリカがその有効性に同意し、チェーンに追加されることを保証するプロセスです。確定化は、すべてのノードがブロックを承認し、ネットワーク全体でのコンセンサスを確保することを保証します。
実行
確定化後、ブロックは実行段階に入り、アップデートコールに従ってキャニスターの状態が更新されます。この段階のレイテンシーには、以下のような要因が影響します
・キャニスターコードの複雑さ
キャニスターのコードの複雑さは実行速度に直接影響します。より複雑なロジックやデータ量の多い操作は、追加のレイテンシーを引き起こす可能性があります。
サブネットの負荷
各サブネットは複数のキャニスターをホストするため、実行リソースは共有されます。サブネットの高負荷は、キャニスターが計算リソースを競合するため、レイテンシーを増加させる可能性があります。
単純な操作でも、サブネットのアクティビティによってレイテンシーが発生する可能性があります。ピーク使用時には、アップデートコールはリソースを待つ間に遅延に直面する可能性があります。
証明書の共有
実行後、レプリカはサブネット内で証明書情報を共有し、アップデートコールが正確に実行され、結果として生じる状態変更が一貫していることを検証します。
レプリカが証明書で応答
証明後、レプリカは証明書を含む応答をバウンダリーノードに送信し、アップデートコールの正常な完了を示します。
バウンダリーノードが応答を中継
最後に、バウンダリーノードは認証された応答をユーザーに中継し、アップデートコールのライフサイクルの終了を示します。
Tokamakマイルストーン
上記で説明したアップデートコールのライフサイクルの合理化されたフローは、Tokamakマイルストーンによって大幅に強化されました。これにより、Internet Computerにいくつかの重要な改善が導入されました
QUIC上の中断可能なブロードキャスト
QUICプロトコル上に実装された中断可能なブロードキャストプリミティブは、現在すべてのレプリカ間通信を管理し、ネットワーク全体で信頼性の高い効率的なメッセージ配信を提供します。このソリューションにより、信頼性を犠牲にすることなくコンセンサスを高速化する公証遅延の大幅な削減が可能になりました。
強化されたバウンダリーノードルーティング
バウンダリーノードの改善されたルーティングロジックは、ライフサイクルの第2段階で見られるように、レプリカへのアップデートコールの分散を最適化します。
同期アップデートコール
同期アップデートコールの導入により、証明直後にユーザーへの直接応答が可能になり、ライフサイクルの最終段階が簡素化され高速化されました。
これらの進歩は、集合的にInternet Computer上のアップデートコールの効率性、速度、信頼性を向上させ、よりシームレスなユーザー体験とより堅牢なプロトコルを作り出しました。
アップデートコールのレイテンシーに影響を与える主要な要因
Internet Computer上のエンドツーエンドレイテンシーは、いくつかの顕著な要因の影響を受けます
サブネットトポロジー
サブネットの物理的およびネットワークレイアウトは、レプリカ間のラウンドトリップタイム（RTT）に影響します。短いRTTはより速い通信を可能にしますが、レプリカ間の地理的距離が大きいとレイテンシーが増加する可能性があります。
サブネット負荷
サブネット上で処理されるキャニスターの数とメッセージの量がレイテンシーに影響します。ICは共有インフラストラクチャとして動作するため、負荷の高いサブネットに配置されたキャニスターは、同じリソースへの競合する要求のために高いレイテンシーを経験する可能性があります。
パイプラインアーキテクチャ
ICPのアーキテクチャは、コンセンサスと実行段階をパイプライン化することでスループットを最大化するように設計されています。この設計により、複数のプロセスが同時に実行できますが、トレードオフが発生します：スループットは増加しますが、パイプラインの各段階は前の段階の完了を待つ間に追加のレイテンシーを経験する可能性があります。
ICPの設計は、分散型の分散ネットワークに固有のパフォーマンストレードオフとこれらの要件のバランスを取りながら、高スループットとスケーラビリティを優先します。
TokamakによるICPの前後のベンチマーク
Tokamakマイルストーンの影響を測定するために、ICP上でホストされている3つの異なるスマートコントラクトのエンドツーエンド（E2E）レイテンシーを測定しました。ベースラインとして、Tokamakマイルストーンが展開される前にベンチマークを行い、その後マイルストーンの完了後にベンチマークを繰り返して比較しました。結果は非常に興味深く、ユーザーは今後ICPからより低いレイテンシーを期待でき、より良いユーザー体験につながることを示しています。
ベンチマークを行った各ユースケースについて、0-99.99パーセンタイルのE2Eレイテンシーを表示する表と図を添付しました。
ICPレジャー
ICPレジャーは、NNSサブネット上でホストされているスマートコントラクトで、ICPトークンのレジャーとして機能します。ユーザーは多くの方法でレジャーと対話できますが、最も人気のあるdappとフロントエンドは、NNSサブネット上でもホストされているNNS dappです。
数日間にわたってベンチマークを実行し、その間ICPトークンをループで送信し、トランザクションの送信からICPからの応答（トークンが送信されたことを証明する証明書付き）を受け取るまでの時間を記録しました。平均レイテンシーは4.57秒から2.23秒に51%減少しました。
インターネットアイデンティティ
インターネットアイデンティティサブネット上でホストされているインターネットアイデンティティdappは、Internet Computer上で実行される連携認証サービスです。ICP上のdappと対話したことがある場合、おそらくインターネットアイデンティティでサインインする時間を費やしたことがあるでしょう。このベンチマークは、インターネットアイデンティティサービスでサインインするのにかかる時間を測定します。
結果によると、サインイン時間の平均待ち時間は 7.12 秒から 3.9 秒に短縮され、45.2% の短縮となりました。下の図 2 は、さまざまなパーセンタイルの前後の結果を示しています。図から、50 パーセンタイル、つまり中央値では、サインイン時間が 6.9 秒から 3.2 秒に短縮されたことがわかります。紫色の領域は、各パーセンタイルの節約された時間を示しています。各パーセンタイルの結果のより詳しい情報については、表 2 をご覧ください。
アプリケーションサブネット
13 ノードのアプリケーション サブネットsnjpでホストされているキャニスターがあります。このサブネットを使用すると、Tokamak マイルストーン後に 13 ノードのアプリケーション サブネットがどのように改善されるかをテストできます。ベンチマークでは、平均 E2E レイテンシが 2.43 秒から 1.35 秒に減少し、約 44% の削減が達成されたことが示されています。
Kommentare