※この記事は、「A new P2P layer is coming to the Internet Computer」を引用/翻訳したものです。
インターネット コンピュータ上での新しい P2P レイヤーの展開が開始されました。その設計により、堅牢性と速度が向上し、インターネット コンピュータを止められないものにするために必要なすべての保証が提供されます。
著者:ヨタム・ハーチョル
インターネット コンピュータ ブロックチェーンは、各サブネットのノード間でメッセージ (アーティファクト) を配布するピアツーピア (P2P) プロトコルに依存しています。このプロトコルは、インターネット コンピュータ ブロックチェーンを操作するプロトコルのセットであり、インターネット コンピュータ コンセンサス プロトコル、DKG (分散キー生成) プロトコル、または状態同期プロトコルが含まれます。このような各プロトコルはアーティファクトを生成し、これらのアーティファクトをサブネット内のピアに配布するために P2P レイヤーを必要とします。P2P レイヤーの上位レイヤー コンポーネントとして実装されるこれらの各プロトコルを、P2P クライアントと呼びます。
状態同期用の個別の P2P レイヤーを導入した後、インターネット コンピュータ プロトコル スタック内の他のすべての P2P クライアント用の新しい P2P レイヤーが導入されます。この新しい P2P レイヤーにより、ネットワーク パフォーマンスが向上し、コンセンサス プロトコルに必要な保証が確保され、ノードの不正動作の検出が容易になります。
新しく提案された P2P 層は、最近導入された新しい QUIC ベースのトランスポート層を使用します。したがって、この新しい層への移行により、インターネット コンピュータの P2P 層は TCP の使用を完全に停止します。QUIC への移行は、P2P 層の完全な非同期実装への移行も意味します。各リクエストは新しい QUIC ストリームとして送信され、他のリクエストとは独立して処理されます。これにより、少なくとも理論上はライブネスの問題につながる可能性のあるヘッドオブライン ブロッキングの問題を回避できます。
新しい P2P レイヤーでは、スロット テーブルと呼ばれる新しい抽象データ構造が導入され、接続品質に基づいて各ピアへの適切な送信レートを維持しながら、他のピアに影響を与えることなく、ピアへのアーティファクトの配布を制御しやすくなります。また、ピアの不正行為の検出も容易になります。
提案された新しい P2P レイヤーが承認されると、各クライアントは P2P プロトコルの個別のインスタンスを使用します。状態同期では、そのクライアント専用に設計されたインスタンスが使用され、残りのクライアントは、この投稿で詳しく説明する新しい P2P レイヤーの個別のインスタンスを使用します。新しく提案された P2P レイヤーの展開は、HTTPS アウトコール アーティファクト配布を新しい P2P レイヤーを使用するように移行した一連の NNS 提案の採用から始まりました。その後、コンセンサス プロトコルを含む残りのすべてのクライアントが移行され、最終的に古い P2P レイヤーは廃止されます。
背景・インターネットコンピュータのP2P層
非常に高いレベルでは、P2P プロトコルは、各クライアントの検証済みアーティファクト プールに存在するアーティファクトを同じサブネット内のピアに配布する役割を担っています。検証済みアーティファクト プールは、これらのアーティファクトをピアにブロードキャストするニーズに基づいてクライアントによって埋められます。
図 2 は、P2P とその上位のクライアント間のインターフェイスを示しています。クライアントは、on_state_change() を呼び出すたびに、アーティファクト プールを任意に変更することができます。このような呼び出しは、最終的に、そのクライアントの検証済みアーティファクト プールからのアーティファクトの追加と削除に対応する ChangeActions のセットを返します。P2P レイヤーは、この情報を使用して、検証済みプールのコンテンツをピアに伝播する必要があります。
インターネット コンピュータの既存の P2P プロトコルは、各ノードからそのピアへのアーティファクトのストリーミングに基づいています。アーティファクトが検証済みプールに追加されるたびに、すべてのピアに広告がブロードキャストされます。広告は、アーティファクトを説明する小さなメッセージです。帯域幅を節約するための手段として、アーティファクト自体の代わりに送信されます。これにより、受信者は (潜在的に大きい) アーティファクトをダウンロードするかどうかを決定できます。送信ノードは、各ピアに対して単一の TCP ストリームを維持し、そのストリームで広告 (および要求に応じて後でアーティファクトも) が送信されます。
P2P レイヤーは、誠実なノードと運用ノード間の成果物の配信を保証する必要があり、潜在的に悪意のあるノードによる悪意のある動作に対して耐性を持つ必要があります。
P2P レイヤーのすべてのコンセンサス関連クライアントには、2 つの重要なプロパティがあります。
P1: アクティブなアーティファクトの制限された数:検証されたアーティファクト プールは、どの時点でもサイズが制限されています。コンセンサス プロトコルは、アーティファクトを定期的に消去できるチェックポイントを使用するため、プールの最大サイズ C は、チェックポイント間隔 (ブロック数で測定) とサブネットのサイズの関数として計算できます。
P2: アーティファクトの明示的な有効期限:アーティファクトがプールから削除された場合 (パージされている場合)、それをピアに配布する必要はなくなります。または、受信側から見ると、ピアに特定のアーティファクトがない場合、他のすべてのピアによって削除されるまでに受信側がそのアーティファクトを受信できなかったとしても、受信側はそのアーティファクトを必要としないことが保証されます。
これら 2 つのプロパティは、後ほど説明する重要な設計上の決定を可能にするため、ここで強調されています。
ネットワークバックプレッシャー
従来のクライアント サーバー アプリケーションでは、バックプレッシャーの概念が広く使用されています。受信側がメッセージの消費を遅くすると、送信側のバッファーがいっぱいになり、送信側のネットワーク層は次の 3 つのパスのいずれかを実行する必要があります。
バックプレッシャーをアプリケーション層に伝播し、アプリケーションのデータ生成を遅くします。
メッセージをバッファリングします（無期限に保持される可能性があります）。
出力メッセージをドロップします。
ブロックチェーンでは、これはさらに複雑になります。送信者が 1 つのピアからバックプレッシャーを受けると想像してください。このピアは正直かもしれませんし、そうでないかもしれません。上記のいずれかのアプローチを取ると、深刻な問題につながります。
データ生成を遅くすることは、ブロックチェーンを遅くすることを意味します。この動作を許可すると、サービス拒否 (DoS) 攻撃ベクトルになります。
バッファは、潜在的に無期限に、攻撃ベクトルにもなります。
出力メッセージをドロップすると、正直だが遅いノードへの配信が保証されない可能性があります。
ほとんどのブロックチェーンは、オプション 1 と 2 のセキュリティ リスクのため、オプション 3 を選択しました。ただし、オプション 3 はブロックチェーンのライブネスにリスクをもたらします (つまり、十分な数のメッセージがドロップされると、ブロックが停止する可能性があります)。インターネット コンピューター用に提案されている新しい P2P レイヤーは、メッセージをドロップすることなくリスクを克服します。
新しいP2Pレイヤー
新しい P2P レイヤーは、既存のレイヤーとはまったく異なる方法で動作します。まず、常に広告を使用するわけではありません。アーティファクトが十分に小さい場合は、広告なしですぐに送信されます。次に、単一のストリームを使用するのではなく、同じ QUIC 接続で複数のストリームを使用します。3 番目に、単一のストリームを使用しないため、アーティファクトの送信の管理方法が大きく異なります。4 番目に、同じサブネット内のピア間の通信にわずかに異なるプロトコルを導入します。
少し立ち止まって、コンセンサス プロトコルや、同様の要件 (つまり、状態同期ではない) を持つ他のクライアントにサービスを提供する際の P2P レイヤーの目的を見てみましょう。その目的は、すべての正直なノードに対して、ピアがそのノードの検証済みアーティファクト プールにあるものをすべて受信できるようにすることです。もちろん、すべてを安全、スケーラブル、高性能に保ちながら行います。
新しい P2P レイヤーは、スロット テーブルと呼ばれる新しい抽象データ構造を導入することでこの目的を達成します。スロット テーブルは、検証済みアーティファクト プールのコンテンツと、そのコンテンツについてピアを更新するプロセスを追跡するために使用されます。スロット テーブルのデータ構造はシンプルですが、要件を満たすために必要なものを正確に提供します。
スロットテーブルのデータ構造
スロット テーブルは、送信側のすべてのノードによって維持され、受信側のすべてのノードによっても推測される抽象データ構造です。送信側のスロット テーブルのサイズは、検証済みプール内のアクティブな成果物の数と正確に一致します。上記のプロパティ P1 を思い出すと、これはスロット テーブルが定数 C に制限されることを意味します。
検証済みプールにアーティファクトが追加されるたびに、送信側のスロット テーブルの空きスロットに追加されます。スロット更新メッセージがすべてのピアに送信され、スロットの内容が変更されたことが通知されます。受信側の各ピアは、新しいスロット更新メッセージの到着に基づいて、各ピアのスロット テーブルの状態を追跡します。ただし、ネットワークの輻輳とバックプレッシャーによって、これらの更新が遅れる可能性があることに注意してください。したがって、受信側のビューは、送信側のスロット テーブルと最終的に一致するだけです。
各スロットには、アーティファクト情報に加えて、バージョン番号があります。このバージョン番号は、検証済みプールへの更新ごとにグローバルに増加します。そのため、受信側は、更新メッセージを受信したときに、既存のバージョン番号よりも高いバージョン番号の更新のみを受け入れることで、それが新しい更新か古い更新かを知ることができます。
図 3 は、このプロセスの例を示しています。送信者はアーティファクト A から F を生成します。また、プロセス中にそれらのいくつかを削除します。削除は必ずしもピアに伝播されるわけではないため、ピアのスロット テーブルのビューには削除されたアーティファクトが残っている可能性があります。これは正しいことです。なぜなら、最終的にはスロットの内容が更新され、それが伝播されるからです。
送信側の各スロットに対して、新しい非同期タスクのセット (つまり、グリーン スレッド) が生成されます。これは、ピアごとにスロットごとに 1 つのタスクです。タスクは非常に軽量であるため、これはより大きなサブネットに対しても拡張可能です。各タスクは、対応するスロットと対応するピアのスロット更新メッセージを確実にプッシュする役割を担います。つまり、タスクは確認応答を受信するまで更新のプッシュを再試行します。スロットの内容が変更されるたびに、タスクは古い内容のプッシュを中止し、代わりに新しい内容のプッシュを試行し始めます。低速のピアは更新の取得に時間がかかるかもしれませんが、高速のピアに干渉することはありません。
このアプローチは、上記のバックプレッシャーの説明におけるアプローチ 2 と 3 (ネットワーク層でメッセージをバッファリングし、メッセージをドロップする) を組み合わせたようなもので、回復力と活性を犠牲にすることなくバックプレッシャーの問題を解決します。
このアプローチの正しさは、前述のクライアントのプロパティ P1、つまりアクティブなアーティファクトの数が限られていることに由来します。これにより、C スロットがあらゆる状況で十分であることが保証され、スロットを再利用できます。上記のプロトコルにより、ピアは検証済みアーティファクト プールのコンテンツを同期できるだけでなく、ノードはピアが一度に C を超えるアーティファクトをアドバタイズしないようにすることもできます。更新メッセージのスロット番号が C より大きい場合、受信者は送信者の不正行為をすぐに推測できます。
受信側で、ノードが、そのピアのスロット テーブルにアーティファクトが存在しなくなったことに気付いた場合、ノードは、アーティファクトがまだ存在する場合は、検証されていないアーティファクト プールからアーティファクトを安全に削除するか、アーティファクトがまだ取得されていない場合は、このアーティファクトを取得する試みを停止することができます。
前述のプロパティ P2: アーティファクトの明示的な有効期限は、そのようなアーティファクトがどのピアにも不要であることを保証します。したがって、スロット テーブルは、検証されていないアーティファクト プールのサイズにも暗黙的な制限を課します。検証されていないプールには、正直なピアからのアーティファクトを最大 C 個しか含めることができません (検証済みプールの内容はすべてほぼ同じであるため)。また、悪意のあるピアごとに最大 C 個のアーティファクトを追加できます。これは、IC に C 個のまったく異なるアーティファクトをスパム送信する可能性があるためです。ノードの 1/3 未満が悪意のあるノードである可能性があるため、検証されていないプールの合計サイズは、アーティファクト C*4*n/3 個を超えることはできません。
上記の設計の説明では、アーティファクトのみについて言及しており、広告については触れていないことにお気づきかもしれません。その理由は、広告は帯域幅の利用率を向上させるための最適化にすぎないからです。新しい P2P レイヤーでは、大きなアーティファクトに対してのみ広告を使用します (現在のしきい値は 1 KB に設定されています)。
しきい値より小さいアーティファクトはスロット更新メッセージで送信されるため、後で受信側が明示的に要求する必要はありません。しきい値より大きいアーティファクトの場合、広告が生成され、更新メッセージで送信されます。受信側クライアントは、広告を要求するかどうか、またどのピアから要求するかを決定できます。
パフォーマンスを向上させた
QUIC を使用した非同期実装と、小さな成果物の直接プッシュにより、ネットワーク パフォーマンスが向上し、その結果、コンセンサス パフォーマンスも向上します。
図 4: (上、既存の P2P レイヤー / 下、新しい P2P レイヤー) 60 ノードのサブネットで人工的にリンク遅延を追加した状態で、サブネットの負荷が高い場合と低い場合の時間の経過に伴うブロック レート。垂直線は高負荷の終了を示します。図 4 は、既存の P2P レイヤーと新しい P2P レイヤーのパフォーマンスを比較するために行った 1 つの実験の結果を示しています。この実験では、1 つのデータセンターで 60 ノードのサブネットを 1 秒あたり 200x100KB のリクエストの負荷で実行し、コンセンサス ブロック レートを測定しました。グラフは、各ノードの線で時間の経過に伴うブロック レートを示しています。地理的に分散したサブネットをシミュレートするために、両方の実験ですべてのネットワーク リンクに 80 ミリ秒のラウンドトリップの人工的なリンク遅延を追加しました。
上のグラフは、既存の P2P レイヤーでのブロック レートを示しています。サブネットは正常に進行していますが、負荷が高いときはブロック レートが非常に不安定です。負荷がなくなると正常に戻りますが、負荷が高い間は、サブネット全体のブロック レートが低下し、ユーザーが感じるレイテンシが大きくなることを意味します。下のグラフは、新しく提案された P2P レイヤーでのブロック レートの堅牢性を示しています。サブネットは、高負荷でも非常に安定したブロック レートで動作し続けます。
結論
コンセンサスおよび類似クライアント用の新しい P2P レイヤーにより、インターネット コンピュータのパフォーマンスが向上し、スケーラビリティが向上し、コードの複雑さが軽減され、不完全なネットワーク条件での動作が改善されます。
これは、HTTPS アウトコール関連のアーティファクトに対してのみ、特定のサブネットですでに有効化されています。他のクライアントに対しても有効化する提案は、DFINITY Foundation からまもなく提出される予定です。承認され、実行されると、インターネット コンピュータの P2P レイヤー全体が TCP ではなく QUIC を使用するようになり、インターネット コンピュータのネットワーク レイヤーの堅牢性、スケーラビリティ、パフォーマンスが向上します。
インターネット コンピュータについて詳しくは、以下をご覧ください。
Comentários