ネットワーク操作に欠かせない3つのミニプロトコル
2020年7月9日 Marcin Szamotulski 読了時間6分
CardanoおよびOuroborosプロトコル次回リリースには、分散化そしてShelley期へと導く変更が含まれます。この「開発者を掘り下げる」シリーズ第3弾では、この段階へのアプローチ方法を紹介します。ステーキングプロセスを伴うShelley用Praosアルゴリズムのリリースとともに、ステークプールのセットアップが可能となり、ADA保有者はステークを委任できるようになります。ネットワーキングチームは現在、完全な分散型システムの稼働を可能とする2つの機能に焦点を当てています。本稿ではまず、簡単にネットワークの設計およびエンジニアリング方法について説明し、現状について概要を述べたいと思います。最上層の抽象化からスタック底部まで追うデザインの旅が、興味深いものであることを願っています。
型付きプロトコル
スタックの最上部には、アプリケーションレベルのプロトコル設計を可能にするIOHKの型プロトコルフレームワークがあります。Ouroboros用プロトコル設計における最大の目的は、ネットワークの参加者にブロックのチェーンとトランザクションを配信することであり、これを3つのミニプロトコルによって達成します。
- ヘッダーのチェーンを効果的に同期するために使用するchain-sync
- ブロックのプルが可能となるblock-fetch
- トランザクションを送信するtx-submission
3つのミニプロトコルはすべて、分散型システムを実行中に生じうる脅威を考慮し、細心の注意を払って設計されています。これは非常に重要です。なぜならサイバー攻撃は非常に一般的であり、特に強力なインセンティブを示すターゲットが狙われやすいからです。このレベルには多彩な攻撃可能性があり、すべて防ぐことができなければなりませんが、中でも特に注意したのがリソースを消費するタイプの攻撃です。こうした攻撃を防ぐために、消費者側が受信するデータ量はプロトコルにより常にコントロール下に置かれており、究極的にはそのリソース（例：メモリー、CPU、オープンファイルディスクリプター）の使用を一定レベル以下に保ちます。
型付きプロトコルの詳細は、去年行われたHaskellイベントにおける発表およびワークショップがエンジニアコミュニティで好評を博しました。関心の向きは、特に次の発表Duncan Coutts talk at Haskell eXchangeと、私が主催したワークショップMonadic Partyを参照してください。
マルチプレクサの役割
TCP/IPプロトコルはインターネットにデプロイされているなかで最も遍在しているプロトコルスイートです。また、最も研究されている部類のプロトコルでもあり、ほぼすべてのオペレーティングシステムやコンピューターアーキテクチャーで使用できるため、私たちの目的にとって最初に選ぶべきものです。TCP/IPによりインターネットのサーバー間にある双方向のコミュニケーションチャネルへのアクセスが可能となります。型付きプロトコル唯一の高レベル要件は順序付けられたネットワークパケットの配信であり、これはTCPプロトコルにより保証されます。
オペレーティングシステムは所与の時点の接続数を制限します。例えば、Linuxではデフォルトでプロセスごとに1,024接続を開くことができますが、macOSでは256に限られています。リソースの超過使用を避けるため、マルチプレクサを使用します。これにより、コミュニケーションチャネルを1つにまとめて、3つのミニプロトコルすべてを単一のTCP接続で実行することができます。リソースを節約するもう1つの方法は、TCPの双方向性を使用することです。つまり、メッセージの送受信を両エンドで同時に行うことができます。この機能はByronリブートでは使用しませんでしたが、分散型のShelley期では活用しようと思っています。
P2Pガバナー
3つの全ミニプロトコルを両方向で実行できる、双方向接続を使用するためには、接続が実行されていることを知覚するコンポーネントが必要です。ノードが新たなピアに接続されると、まずそのピアとの接続が既に開かれているかどうかをチェックできます。ピアが既に接続されている場合、開かれていると判断できます。ただし、これは必要となる接続管理のほんの一部です。
別の要件はP2Pガバナーに関連します。システムのこの部分はピアを発見し、どれを接続するか選択する役割を持ちます。接続には時間がかかり、ネットワーク接続の質や物理的距離などのファクターに左右されます。Ouroborosはリアルタイムシステムであるため、ここにレイテンシーの一部を隠蔽することは有益です。システムにプレッシャーがかかっている状態で新しいピアとの接続が必要になるのは好ましくありません。システムが新たなタスクに対応できる一握りの予備接続を維持している方が遥かに健全です。ノードは既存の接続のどれが最高のパフォーマンスを生み出せるかを、学習に基づき判断できるべきです。このため、ピアを3タイプに分類することにしました。
- コールドピア：存在は認識できるが、確立したネットワーク接続は存在しない
- ウォームピア：接続は存在するが、ネットワーク測定に使用されるのみであり、ノード2ノードのミニプロトコルには使用されていない
- ホットピア：接続があり、3つ全部のノード2ノードミニプロトコルに使用されている。
ノードは潜在的に何千ものコールドピアを知ることができ、数百のウォームピアを維持し、数十のホットピアを持つことができます（20は現時点で妥当な数）。P2Pガバナーの判断を促すポリシー設計を巡っては、興味深く困難な課題があります。このようなポリシーを選択することは、ネットワークトポロジーに影響し、ネットワークのパフォーマンス特性（重負荷時や悪質な行為による影響を含む）を変化させます。これにより、ブロック拡散（ブロックサイズによりパラメーター化）やトランザクションをタイムリーに分散するよう調整します。こうしたシステムの実行は未知のことが多いため、2段階に分けて行うことを計画しています。第1段階は、数週間内（おそらくPraos、すなわちShelleyリリース直後）を予定しており、すべてのP2Pコンポーネントの準備を整えつつ、連合型モードによる実行を続けます。加えて、接続管理を接続を受容するサーバーの実装、およびそれをP2Pガバナーと統合したものを配信します。この段階では、P2Pガバナーはサブスクリプションメカニズムとして使用されます。多様なプライベートおよびパブリックテストネットを実行しながら、拡張テストも行うことにより、十分に確信を得てからメインネットにリリースできると期待しています。
第2段階では、ミニプロトコルをゴシッププロトコルに拡張します。これにより、ピアについて情報交換し、ネットワーククオリティ測定を仕上げ、ブロックフェッチロジック（誰からブロックをダウンロードするかを決定）およびP2Pガバナーに入れることが可能となります。この時点で、P2Pポリシーがいかにネットワークを形成するのかを発見するために実験を設計し実行したい、そして準最適（または敵対的）トポロジーから回復する仕組みを確認したいと思います。
本稿が、Cardano分散化の設計および実装に関する現状、そしてShelley期へを向かうロードマップについての理解の一助となることを期待します。今後の進捗状況は週刊技術レポートを参照してください。
本稿はソフトウェアエンジニアリングチームによるテクニカルな記事をお届けする「開発者が掘り下げる」シリーズ第3弾です。