イーサリアムにおけるアクティブなデータ同期の簡単な分析

I.はじめに

端的に言えば、イーサリアムのデータ同期は、主にヘッダー、本文、およびレシートで構成されるデータ主体を保存および送信するデータ キャリアとしてノード (ピア) を使用します。データ同期トランザクションは、イーサリアム p2p 通信プロトコルを通じて管理され、最終的にサーバーに渡されます。 executor (アクティブな同期はダウンローダーに引き渡され、パッシブな同期はフェッチャーに引き渡されます) は、最終的なデータ ダウンロード タスクを実行します。

次に、データ主体に、同期のためにどのデータを同期する必要があるのか​​を尋ねます。さまざまなデータを分類して同期する必要がありますか?

Chuangyu Blockchain Security Lab が包括的かつ詳細な分析を実施したことを知ってください。

2. データ主体:

データ同期を実行するには、まず同期するデータ主体が何で構成されているかを明確にする必要があります。一般的には 2 つのタイプがあります。1 つはノードがアクティブな同期リクエストを送信する必要がなく、ノードが自らネットワークにブロードキャストするタイプです。データがパッケージ化されるとき、このタイプには 3 つのタイプのデータがあります: タイプ - フル ブロック、ブロック ハッシュ、およびトランザクション トランザクション。今日は次のカテゴリのデータに焦点を当てます。

2 番目のタイプのデータは、ノードが能動的に同期要求を送信し、他のノードがそのデータに応答して同期する必要があるデータです。最初のタイプのデータを除き、同期する必要があるその他のデータは 2 番目のタイプに属します。 、そのため、そのタイプはより複雑であり、最も重要であると言えます。また、ブロックヘッダー、ブロックボディ、トランザクションレシートレシート（特定のコード⬇⬇⬇）の3種類があり、最初のタイプとは異なり、これら3つは次のとおりです。完全なブロックの特定の部分であると言われており、これも示しています。能動的に同期するには、ノード間のデータ同期の範囲を自由かつ制御可能であり、必要なデータを最初に同期し、一時的に非必須のデータを同期できることが望まれます。データは諦めることができます。

⬆Headerとはブロックのヘッダーのことで、ブロック内で非常に重要な役割を果たしており、ParentHashは前のブロックのブロックハッシュを記録し、uncleHashはアンクルブロックのハッシュを記録し、coinbaseはマイナーのアドレスを特定します。 Root、Txhash、および ReceiptHash は、それぞれ状態トライ、tx トライ、および Receipt.trie の 3 つのプレフィックス ツリーのルート ノードです。1 つの RLP コード ハッシュは世界の状態を記述するために使用され、もう 1 つはトランザクションを記述するために使用されます。もう 1 つはトランザクションの受領書を記述するために使用されます。ブルームは、ターゲット ハッシュが特定のセットに含まれるかどうかを迅速に判断するためのブロック ヘッダー内のブルーム フィルターです。ヘッダー内の上記のデータは、ハッシュを使用してブロックとブロック内の重要なデータ モジュールを識別するためにブロック ヘッダーによって使用されます。残りのデータには独自のニーズがあります。ブロック ヘッダーは基本的にブロック フレームを記述していることがわかり、これにより、後述するデータ同期戦略への道も開かれます。

⬆Body は比較的簡潔で、トランザクション オブジェクトのセットと Uncle ブロックのブロック ヘッダーの配列が含まれます。

⬆Receiptは、ブロック内のすべてのトランザクションオブジェクトの実行後に生成される配列であり、トランザクションの処理情報を記録するために使用されます。生成後、Receipt トライに 1 つずつ挿入され、ブロックヘッダーの ReceiptHash も生成されます。トランザクション レシートには、トランザクションの管理と識別のための 3 つの部分の情報が記録されます。最初の部分は、コンセンサス部分、PostState、Status、CumulativeGasused、Bloom、および Logs です。これら 5 つのデータのみが ReceiptRLP でエンコードされてレシート ハッシュを形成し、その後、受信ハッシュはコンセンサスに参加します。データの 2 番目の部分はトランザクション部分です。TxHash はトランザクション受信に対応するトランザクション ハッシュを指します。ContractAddress はトランザクションがデプロイされるときの新しいコントラクトのアドレスです。Gasused はガスを示します。トランザクションの使用法の 3 番目の部分はブロック部分で、BlockHash ブロック ハッシュ、BlockNumber は現在のブロック番号、TransactionIndex はブロック内のトランザクションのシリアル番号を記録します。受信には、データ同期戦略に直感的な違いがあります。以下で説明する fullSync と fastSync の最も直感的な違いは、ピアの受信を同期するか、ローカルで受信を生成するかです。

3. データキャリア

データ伝送キャリアはピアノードです. このデータキャリアピア, ソースコードを注意深く検索すると、いくつかの隅にpeer.goが見つかります. まず、データ同期モジュールについて私が見つけたピア構造をリストします。 。 p2p/peer.go、eth/peer.go、les/peer.go、eth/downloader/peer.go があります。イーサリアムのネットワークには、トランスポート層、セッション層、プレゼンテーション層、プロトコル層もあります。

p2p パッケージのピアは基礎となるノード モデルとして機能し、トランスポート層は UDP プロトコルに基づいて隣接するピアを検出し、ピア接続を維持し、また TCP プロトコルに基づいてピア間の情報交換チャネルを確立します。セッション層でのピア管理は主にノードと上位層のサブプロトコル間の対話を管理し、NodeTable 管理は主に UDP プロトコルに基づいて構築された基盤となるノード接続テーブルを管理します。したがって、p2p 層のピアノードは、サブプロトコルを取得して開くことができる必要があり、また、他のノードに ping を送信でき、もちろん他のノードからメッセージを受信できる必要もあります。これは、p2p/peer.go の 3 つの重要な機能モジュール、pingLoop、readLoop、および startProtocols に反映されています。これらは、peer.run() メソッドの 3 つの関数でもあります。

上の図は基礎となるピア構造であり、下の図はサブプロトコル層のピア構造であることがわかります。サブプロトコル層が異なればピア構造も異なります。そのため、eth/peer.go と eth/peer.go が存在します。結局のところ、les/peer.go さまざまなサブプロトコルがさまざまなデータ シナリオに適用されます。

データキャリアには最下層ピアとサブプロトコル層ピアがあり、データ同期には通信プロトコルを使用して2層のピアを管理および接続する必要があることがわかります。最下層はピアのメッセージ配信、メッセージ監視を実現します。 、サブプロトコル層のピアはデータのダウンロードと同期を実行します。非常に重要なプロトコルマネージャーは、これら 2 つの層間の管理と通信に必要です。

4. データ同期プロセス

では、protocolManager を起動するにはどうすればよいでしょうか?上でピア構造を紹介しました. これは主に他のリモート ノードを表します. イーサリアムには、ノードも表す別のタイプの構造ノードがあります. これは主にローカル ノード自体を表しますが、これは少し異なり、ノードは p2p を開始したいと考えていますローカル Node モジュールに依存する必要があり、このモジュールは Node.Start() 関数を使用して 2 つのタスク (1 つは Ethereum サービスの開始、Ethereum.start はプロトコル マネージャーの開始) を開始し、もう 1 つは p2p の開始です。サーバーでは、 K バケット を作成および更新し、UDP ポート監視と TCP ポート監視を同時に有効にして、リモート ノードから送信されたメッセージを処理します。

protocolManager が開始されると、基礎となるロジック層ピア (p2p) と最上位層のプロトコル層ピア (eth) に接続する必要があります。

プロトコルマネージャーが開始されると、ノードは最初に初期化して NewProtocolManager を呼び出します。初期化プロセス中に、サブプロトコル関数が呼び出されて、ダンジョン p2p.peer からメッセージ読み取りおよび書き込みチャネルを取得し、メッセージ プロセッサ ハンドル、ハンドルを構築します。これは、同期を要求するメッセージを受け入れるだけでなく、ノード応答のメッセージも受け入れます。protocolManger の start メソッドで、通常の同期コルーチン syncer が開始され、fecher または downloader executor を呼び出して、メッセージに従ってデータ同期を実行します。通知。

• データ同期モード

• アクティブなデータ同期とは、ローカル ノードが隣接ノードから自発的にブロック データを要求し、データ エントリが eth/downloader/downloader および eth/handler にあることを意味します。

• パッシブなデータ同期とは、ローカル ノードが他のノードからデータ同期メッセージ (メッセージ) を受信し、ブロック データを要求することを意味します。データ エントリは eth/fetcher/fetcher.go にあります。

• アクティブな同期プロセス アクティブな同期を例に挙げます。ダウンローダー エグゼキューターが呼び出されると、最初に findAncestor を呼び出してローカル チェーンとリモート チェーンの共通の祖先を見つけ、共通の祖先から同期を開始します。4 つのフェッチャーを構成します。 、つまり fetcherHeader と fetcherBodies 、 fetcherReceipts 、 ProcessHeaders は、最後に同期モードに従って processFullSyncContent と processFastSyncContent を呼び出し、最後に spawnSync を呼び出して同期を実行します。

上記は同期処理のソースコードですが、ソースコードからは主なダウンロードタスクが彼が構築した拡張可能なフェッチャー、つまりフェッチャータスクキューに集中していることがわかります。データ同期戦略が異なると、フェッチャータスクキューの構造が異なるだけでなく、フェッチャー間のコラボレーションプロセスも異なります。

5. データ同期戦略

フェッチャー タスク キューの役割は、進行中、データ充填、データ アセンブリ、最終的なデータ挿入として要約されます。どのような種類のデータが入力されるか、どのデータを組み立てる必要があるか、いつデータを挿入するかはすべて、データ同期戦略を表す重要なデータ構造モードによって識別され、主に 3 つのタイプに分類されます。

• lightSync: ライト ノードの同期。データを埋めるとき、ブロック ヘッダー データのみが埋められ、データ アセンブリは必要ありません。insertHeaderchain を呼び出してブロック ヘッダーを直接挿入します。

• fullSync: フルノード同期 データを入力するときは、ブロック ヘッダーとブロック本体に入力する必要がありますが、トランザクション レシートには入力せず、データを結果セット Result にアセンブルしてから、importBlockResults を呼び出してデータを挿入します。 lightSync の違いは、ライト同期にはブロック本体がないため、トランザクションの実行と検証が行われないのに対し、fullSync フルノード同期はデータの挿入中にトランザクションを実行して検証することです。これが理由です。同期速度は遅いですが、トランザクション受領書は自動的に生成されるため、入力と組み立てに参加するために受領書を必要としません。

• 6. 結論

6. 結論

イーサリアムのデータ同期は非常に複雑で、ネットワーク アーキテクチャ、通信プロトコル管理、データ送信チャネルの連携、データ同期戦略の配置、データ同期速度を高速化するアルゴリズムが含まれます。多くの詳細と論理的関係があります。そして、データ同期はブロックチェーンノードと外部世界との間の通信の基礎であり、驚くべき建築上のイースターエッグがさらにあります。次回の記事を楽しみにお待ちしています。