この記事は「A Journey into Stellarator: Part 3」を引用/翻訳しています。
イングレスメッセージスループットの向上
著者：Kamil Popielarz、Yvonne-Anne Pignolet
この3部作のシリーズでは、Internet Computer Protocol (ICP)上で実行されるアプリケーションのデータ処理能力を大幅に向上させる技術的成果について明らかにします。
このアップグレードは、現在ネットワーク全体に展開されているICPロードマップのStellaratorマイルストーンを指します。Stellaratorはオンチェーンデータストレージとスループットにおけるブレークスルーであり、各サブネットがサブネットあたり1TB以上のメモリをホストし、データをより迅速にアップロードすることを可能にし、これまでのストレージとスループットの制約によって制限されていたデータ集約型アプリケーションの機会を解放します。
この進歩により、開発者は大規模なデータ処理を必要とする高度なアプリケーションを構築できるようになり、ブロックチェーン技術に新しいレベルの有用性をもたらします。
このシリーズの最終回では、Kamil PopielarzとYvonne-Anne PignoletがInternet Computer上でのイングレスメッセージスループットの向上に関する最新情報を共有します。このシリーズの前回までの部分を見逃した方は、こちらとこちらでご覧いただけます。
イングレスメッセージスループットの向上
私たちと同じように、dappへのデータのアップロードを待つことは好きな暇つぶしではないでしょう。そのため、Network Nervous System (NNS)がコンセンサススループットを改善するためにInternet Computer Protocolの最適化を展開していることを発表できることを大変嬉しく思います。
これらのプロトコル変更は、ICPのセキュリティ特性を維持しながら、ブロックの配信に必要な帯域幅消費と時間を削減します。その結果、ユーザーはICPのdappとのインタラクションをより迅速に楽しむことができます。
背景
Internet Computer Protocolは、一部のノードがプロトコルから逸脱した場合でも、分散コンピューティングサービスを提供するようにネットワークノードを調整します。
ご存知の通り、ICPはキャニスターと呼ばれるコードとデータを組み合わせた任意のアプリケーションをホストできます。キャニスターは、ユーザーが送信したイングレスメッセージを処理し、他のキャニスターとメッセージを交換して実行することができます。
各キャニスターの実行をすべてのノードで複製する代わりに、ネットワークのノードはサブネットと呼ばれるシャードに分割されています。各サブネットは、そのノード上でホストされているキャニスターの一貫した実行と状態を確保するために、堅牢なコンセンサスプロトコルを採用しています。
コンセンサスプロトコルは、キャニスターメッセージのセットを含む各ブロックの作成と検証を担当します。これらのブロックの順序と内容に合意した後、ノードは対応するキャニスターコードを決定論的かつ一貫した方法で実行し、コンピューティングサービスの整合性を保持できます。
ブロックのペイロードには、ユーザーが複製されたキャニスターコールをトリガーするために送信したイングレスメッセージが含まれています。ユーザーからイングレスメッセージを受信すると、ノードは一連のチェック（署名、サイズ、有効期限など）を実行します。これらのチェックが成功すると、ノードはメッセージをそのイングレスプールに追加し、ICPのピアツーピア（P2P）プロトコルを使用してサブネット内の他のノードにメッセージをブロードキャストします。
ブロック提案を作成する順番が来ると、ノードはそのイングレスプールからイングレスメッセージのセットを含めます。その後、ノードはこの提案をピアにブロードキャストします。
しかし、ほとんどのピアがすでにこれらのイングレスメッセージの大部分をローカルプールに保持しているため、このプロセスは帯域幅を無駄にしています。
このアプローチのもう一つの欠点は、例えば4KBの1000個のメッセージを含む提案を送信するのに、1000個のハッシュを含む提案をすべてのピアに送信するよりもはるかに多くの時間がかかるという事実です。
レプリカが推奨される最小帯域幅の300Mbit/sを持っている場合を考えると、13ノードのサブネットですべてのピアに4MBのペイロードを持つブロック提案をブロードキャストするには：4MB * (13-1) / 300Mbit/s = 1.28秒かかるはずです。50バイト未満の各ハッシュを使用すると、同じ提案を800倍以上速くすべてのノードに配信できます。より大きなサブネットでは、これらの違いが蓄積されるため、さらに重要になります。
最適化
提案の配信時間と帯域幅消費を削減するために、プロトコルは完全なメッセージの代わりにブロック内のイングレスメッセージへの参照（ハッシュ）を含めるように改善されました。ノードはいずれにしてもP2Pプロトコルでイングレスメッセージをブロードキャストするため、レプリカは参照を使用して各イングレスプールからすべてのイングレスメッセージを取得することでブロック提案を再構築できるはずです。
ただし、一部のイングレスメッセージがノードのローカルイングレスプールに欠けている可能性があります。これは、ネットワーク状態が悪い、プールが満杯、ノードがクラッシュ、または悪意のあるノードの動作により発生する可能性があります。ノードは提案を検証および/または実行できるように、提案のすべてのイングレスメッセージを持っている必要があります。欠けているイングレスメッセージを取得するために、ノードは提案を広告するピアからまだ持っていないメッセージを要求できます。
そのハッシュを含むブロックが提案される前に、すべてのイングレスメッセージがすべてのピアのイングレスプールに存在する可能性を高めるために、イングレスプールの実装のいくつかの側面が変更されました。
まず第一に、ノードはピアにメッセージを要求するのを待つ広告を送信する代わりに、イングレスメッセージを直接ピアに送信するようになりました。これにより少なくとも1回の往復が節約され、ピアへのイングレスメッセージのブロードキャストが高速化されます。
さらに、イングレスプールサイズの管理が改良されました。これまでは、メッセージ数と占有できる総サイズにグローバルな制限がありました。これらの制限を超えると、ノードはピアがブロードキャストする任意のイングレスメッセージを拒否していました。
その結果、非常に重い負荷の下では、単一のサブネット上のノードが相互にほぼ素のイングレスプールを持つことになる可能性がありました。この場合、各ブロック提案に対して、すべてのノードがブロック作成者からすべてのメッセージを要求する必要があり、レイテンシーが増加しスループットが低下していました。
この問題に対処するために、グローバルな制限はピアごとの制限に置き換えられました。現在では、イングレスプールにそのピアのスペースがまだある限り、ノードはピアからのイングレスメッセージを受け入れます。
誠実なレプリカは任意の時点でピアごとの制限までイングレスメッセージをブロードキャストするため、重い負荷の下でも同じサブネット上のノードが高度に交差するイングレスプールを持つことが高い確信度で期待できます。
プロトコル全体への変更を最小限に抑えるために、P2PとConsensusの間に新しいコンポーネントが追加され、送信側で提案からイングレスメッセージを取り除き、受信側で追加し直す責任を持ちます。P2Pとコンセンサスロジックの残りの部分は変更されません。
パフォーマンス評価
最適化の影響を示すために、13ノードのテストネットサブネットで実験を実施し、ノード間に300msのRTTを課し、帯域幅を300 Mbpsに制限しました。
実験では、多くの小さな（約4KB）メッセージを使用した場合、スループットが2MB/sから6MB/sに増加することを示しています。
同様に、大きな（2MBわずかに下回る）メッセージを送信する実験でも、スループットが2MB/sから7MB/sに増加します。
なお、実験ではコンセンサススループットにのみ焦点を当て、メッセージを送信したキャニスターは意味のある作業を行いませんでした。
以下の図は、前述の実験中のスループットを示しています。
図1：小さなメッセージのスループット。現在の実装では、サイズ4KB各のメッセージを約2MB/s維持できますが、新しい実装では、サイズ4KB各のメッセージを約6MB/s維持できます。古い実装では、サブネットがデータを処理するために追加で3分必要であることに注目してください。
図2：大きなメッセージのベースラインスループット。現在の実装では、サイズ2MBのメッセージを2MB/s維持できますが、新しい実装では、サイズ2MBのメッセージを約7MB/s維持できます。古い実装では、サブネットがデータを処理するために追加で3分必要であることに注目してください。
また、サブネットに参加するノード（追いつき）とノード障害、および多くのキャニスターまたは多くのノードを持つサブネットのパフォーマンスが少なくとも以前と同様（多くの場合はるかに優れている）であることを示す実験も実施しました。
結論
これらのプロトコル変更は、Internet Computerのユーザー体験を改善し、より多くの、より大きなメッセージを処理できるようにするための更なる変更の基礎を築きます。
これらの変更はすでに特定のメインネットサブネットで有効化されています。これらのサブネットでは、合成トラフィックパターンを持つ小規模な実験だけでなく、実際のネットワーク条件と変動する負荷に対してもメリットが適用されることを体験できます。
フィードバックをお寄せください。
DFINITY Developers Xチャンネルと開発者フォーラムで常にご意見を共有いただけます。また、今後のTech Roadmapの更新にご期待ください。
Comments