ピアツーピア ネットワーキング: Kademlia から Discv5 まで
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
、著者：dean、翻訳および校正：Pei Qi & A Jian、Odailyの許可を得て転載。
イーサリアムまたは関連テクノロジーに取り組んでいる場合は、おそらく discv4 または discv5 について聞いたことがあるでしょう。しかし、これらは一体何なのでしょうか？それらはどのように機能するのでしょうか?彼らの優秀さはどこにあるのでしょうか？これらの質問に答えるには、ゼロから始める必要があります。このブログ投稿は読者がこの分野に比較的慣れていないことを想定しているため、技術的な背景がない人でも読むことができます。
副題
物語の始まり: P2P (ピアツーピア) ネットワークでは、ノードの相互発見とネットワーク形成のプロセスでいくつかの問題に直面します。
Napster などの初期の P2P ファイル共有テクノロジは、単一のサーバーを使用して、誰がどのファイルを所有しているかを記録した情報を共有しました。ノードは中央サーバーへの接続を開始し、ノードが所有するファイルのリストを送信します。次に、別のノードが同じ中央サーバーへの接続を開始し、必要なファイルのストレージ ノードを探し、見つかったノードとの接続を確立します。ただし、これは欠陥のあるシステムです。システムは攻撃に対して脆弱であり、集中型サーバー ノードは訴訟の対象になる可能性があります。 (翻訳者注: ファイル コンテンツとノード間の対応関係は、単一のサーバーに保存されます。著作権で保護されたコンテンツへのリンクが提供されている場合、この集中サーバーのプロバイダーは、元の著作権所有者によって直接責任を負うことになります。)
したがって、ピアツーピア ネットワークには別のソリューションが緊急に必要です。数年間の研究と実験の後、研究者たちは分散ハッシュ テーブル (DHT) を提案しました。
副題
分散ハッシュテーブル
DHTについては上でも触れました。では、DHTとは一体何なのでしょうか？
Kademlia
分散ハッシュ テーブル (DHT) は、分散されたキーと値のリストです。 DHT に参加しているノードは、特定のキーに対応する値を簡単に取得できます。
ネットワーク内に 9 つのキーと値のペアと 3 つのノードがあると仮定します。理想的には、各ノードは 3 つのキーと値のペアのみを保存する必要があります (冗長性を提供するために 6 つのキーと値のペアを保存するのが最善の方法です)。キーと値のペアを更新する場合、一部のネットワーク ノードのみを更新する必要があります。一般的な考え方は、ネットワーク内のどのノードも、ノード間で情報が分散される方法に基づいて、必要な特定のキーと値のペアをどこで探せばよいかを知ることができるということです。
副題
XOR 10011001 00110010 -------- 10101011
DHT とは何かを理解したところで、discv4 の前身である Kademlia を見てみましょう。 Kademlia は、2002 年に Petar Maymounkov と David Mazières によって発明された DHT プロトコルです。このプロトコルはおそらく最も人気があり、広く使用されている DHT プロトコルであると思います。仕組みは簡単なので、見てみましょう。
Kademlia では、ノードと値は距離によって配置されます (配置は厳密に数学的に定義されます)。ここでの距離は地理的な距離ではなく、識別子ベースの表現です。何らかの距離関数を使用すると、2 つの識別子の間の距離を計算できます。
Kademlia は、距離関数として XOR (排他的論理和演算子) を使用します。 XOR 関数の特徴は、入力が異なる場合にのみ出力が true になることです。以下はバイナリ識別子で表現した例です。
上の例は、10 進数 153 と 50 の間の距離が 171 であることを示しています。
XOR を距離関数として使用する理由は次のとおりです。
ID とそれ自体からの距離は 0 です。
距離は対称であり、A から B までの距離は B から A までの距離と同じです。
三角不等式に従い、A、B、C が三角形上の 3 点である場合、A から B までの距離は、A から C までの距離に B から C までの距離を加えた値以下になります。
要約すると、ノードは距離関数に従ってどのノードが自分に近いかを判断し、この「距離」に基づいて決定を行うことができます。
Kademlia ノードにはルーティング テーブルが保存されます。ルーティング テーブルには複数のリストが含まれています。後続の各リストに記録されているノードは、前のリストのノードよりも少し離れています。各ノードは、それ自体に最も近いノードに関する情報を保持します。別のノードが遠ざかるほど、ローカル ノードが保持する情報の関連性は低くなります。
特定のノードを見つけたいとします。私がしなければならないのは、既知のノードにリクエストを送信し、ターゲット ノードに近いレコード内の近隣ノードを返すことだけです。近隣のグループがターゲット ノードを見つけるのを手伝ってくれるまで、このプロセスを繰り返します。
値についても同じプロセスが機能します。値とノードの識別子 ID が同じ方法で編成されているため、値とノード間の距離は決定的であり、この距離を計算できます。値を検索したい場合は、値を格納するノードが見つかるまで、値のキーに最も近いノードを探すだけです。
Kademlia ノードがこれらの機能をサポートするために、プロトコルは次のメッセージを通じて通信します。
PING - ノードがまだ実行中かどうかを確認するために使用されます。
FINDNODE - 指定された ID に要求された最も近いノードを返します。
Discv4
FINDVALUE - FINDNODE と同じですが、ノードが特定の値を格納している場合、その値を直接返します。
これは、さまざまな重要な詳細を省略して、Kademlia について非常に単純化した説明です。より包括的な理解のために、オリジナルの論文またはより深い設計仕様書を強くお勧めします。
副題
バックグラウンドへの道を切り開いた後、最終的には、イーサリアムの現在のノード検出プロトコルである discv4 (検出 v4 を意味します) に到達します。 Discv4 プロトコル自体は Kademlia に基づいていますが、いくつかの変更が加えられています。たとえば、DHT の値の部分は discv4 では使用されなくなりました。
Kademlia は主にネットワークの編成に使用されるため、ルーティング テーブルを使用して他のノードを見つけることができます。ただし、discv4 は DHT の値の部分をまったく使用しないため、Kademlia で使用されていた FINDVALUE および STORE コマンドを放棄できます。
以前、Kademlia のクエリ メソッドでは、ノードがピアを取得する方法について説明しました。ノードは、ノードを自分自身に近づけるために、他のノードに対してリクエストを開始します。新しいノードが見つからなくなるまで、このリクエスト プロセスを繰り返します。
さらに、discv4 では相互端末認証が追加されます。これは、FINDNODE 要求を開始したノードが同じノード検出プロトコルに参加していることを確認するためです。
最後に、すべての discv4 ノードは最新の ENR レコードを維持する必要があります。レコードにはノードに関する情報が含まれます。どのノードも ENRRequest と呼ばれる discv4 固有のパッケージを使用して ENR レコードを要求できます。
ENR についてさらに詳しく知りたい場合は、私の他のブログ投稿「イーサリアムのネットワーク アドレス」に進んでください。
ただし、discv4 ではいくつかの問題も発生します。そのうちのいくつかを見てみましょう。
次に、リプレイ攻撃を防ぐために、discv4 はタイムスタンプを使用します。ホストのクロックが狂うと、あらゆる種類の問題が発生する可能性があります。詳細については、discv4 仕様の「既知の問題」セクションを参照してください。
Discv5
最後に、端末の相互認証にも問題があります。パケット損失の可能性があるため、2 つのピアが相互に認証されているかどうかを知る方法はありません。つまり、私たちは認証されていると思っているかもしれませんが、通信しているピアは認証されておらず、結果として、FINDNODE パケットをドロップする可能性があります。
最後に、端末の相互認証にも問題があります。パケット損失の可能性があるため、2 つのピアが相互に認証されているかどうかを知る方法はありません。つまり、私たちは認証されていると思っているかもしれませんが、通信しているピアは認証されておらず、結果として、FINDNODE パケットをドロップする可能性があります。
副題
最後に、discv5 を見てみましょう。 Discv5 は discv4 の反復バージョンであり、Eth 2.0 のノード検出プロトコルとして機能します。 Discv5 は、discv4 に存在した問題の多くを修正することを目的としています。
最初の変更は、FINDNODE の動作方法です。従来の Kademlia と discv5 はどちらも識別子を使用します。 discv5 では、対数距離を使用します。つまり、FINDNODE リクエストを送信した後、応答に含まれるノードはすべて、送信側ノードから特定の対数距離内にあります。
対数距離とは、まず距離を計算し、次に底 2 の対数関数、つまり log2(A xor B) を使用することを意味します。
2 番目の非常に重要な変更は、discv5 が discv4 の最大の問題、つまりセカンダリ プロトコルの区別の解決に取り組んでいることです。 Discv5 ではトピック テーブルが追加されています。トピック テーブルは、特定のサービスを提供するノードの先入れ先出しリストです。ノードは、ピアにアドバタイズメントを登録することによって、自分自身をこのリストに追加します。
この記事の執筆時点では、このサブプロトコル区別スキームでの書き込み操作にはまだいくつかの問題があります。現時点では、ノードが複数のピアにアドバタイズする効率的な方法がないため、各ピアに個別のリクエストを送信する必要がありますが、大規模なネットワークでは非効率的です。
さらに、ノードがアドバタイズするピアの数と、どのピアにアドバタイズするかは不明です。詳細については、devp2p#136 を参照してください。
Discv5 には他にも多くの小さな変更がありますが、これらの変更はそれほど重要ではないため、この概要では省略しています。
