私たちはイーサリアム 2.0 テストネット上で約 3,000 のバリデーターを実行しています

星球君的朋友们

Odaily资深作者

2020-09-28 18:40 (UTC+8)

この記事は約4269文字で、全文を読むには約7分かかります

数万のバリデーターを実行するプロフェッショナルな PoS マイニングプールの場合、超高ブロックレートを確保するにはより高度な構成が必要です。バリデーターの数が増えると、ブロッ

AI要約

編集者注: この記事は以下から引用しましたHashQuark コミュニティ (ID: HashQuarkPool)、許可を得てOdailyによって転載されました。

Prysm は ETH2.0 の優れた実装であり、現在 Medalla テストネットで最も実行されている実装です。 PrysmはBeacon Chain Node + Validator Nodeのアーキテクチャを採用しており、前者はブロックデータの同期を担当し、後者はブロックの署名と監視を担当します。バリデーターノードは複数のバリデーターを同時にロードできるため、ロードできるバリデーターの数と関連するバリデーターのデプロイメント手順を定性的および定量的に理解するために、このテストを特別に用意しました。

副題

私たちは Medalla テストネットワークを複製し、HashQuark 独自の ETH2.0 ビーコンチェーンを構築し、2 ラウンドのテスト (合計 14 のテストケース) を実施し、数十万のバリデータを実行しました。 Prsym の実装は優れており、少量の ETH (数十から数百のバリデーター) でイーサリアムステーキングに参加したい一般ユーザーの場合、4 コア 8G クラウドサーバーでビーコンチェーンノードとバリデーターをスムーズに実行できます。実行プロセス中に発生する技術的な問題は、技術者ではない一般ユーザーが解決することはできません。

数万のバリデーターを実行するプロフェッショナルな PoS マイニングプールの場合、超高ブロックレートを確保するにはより高度な構成が必要です。バリデーターの数が増えると、ブロック率は低下します。

次に、メインのネットワーク環境に近づけるため、公開テストネットワーク Medalla で次のテストを実施する予定で、現在、Medalla 上ではネットワーク全体の 5% に相当する 3,000 台近くのバリデーターが正常に稼働しています。

副題

テスト環境

以下のテストで使用するクラウドホストの展開には、汎用の N モデルを選択し、CPU プラットフォームは Intel/Broadwell です。システムはUbuntu 18.04.2 LTSを使用しています。 geth バージョンは 1.9.19 安定版、Prysm バージョンは v1.0.0-alpha.24 です。

予備的な試みの第 1 段階

副題

テストプログラム

最も基本的な 2 つの ETH1.0 ノード + 2 つの ETH2.0 ビーコンチェーンノード + 2 つの検証ノードアーキテクチャを使用して、開始計画としてプライベートネットワークを構築します。ネットワークが安定して動作する 1 日を観測期間とします。

副題

以下の表は、テストの概要を示しています。

表1

副題

テスト中に、各インスタンスサーバーの CPU、メモリ、ディスク IO、ネットワーク帯域幅 IO、およびその他の指標を収集しました。

副題

テスト1では、2コアの4G Beacon Chain Nodeのメモリが段階的に増加し、約6時間実行した後にメモリ使用量が100%に達し、メモリ不足エラーによりプロセスが停止し、CPU使用率も徐々に上昇しました。増えた。以下に示すように:

図1

画像の説明

図2

その後、ビーコンチェーンノードの構成を4コア8Gにアップグレードしました。

その後、異なるリージョンに ETH2.0 ノードをデプロイして、異なるリージョンのネットワーク相互接続が各指標に大きな影響を与えるかどうかを観察しましたが、実験結果は正常でした。

副題

プライベートネットワークのテスト状況に応じて、Beacon Chain Node は 4 コア 8G 構成を推奨し、Validator ノードの 2 コア 4G 構成で十分ですが、キーファイルのインポート時に 1 コアの CPU を占有し、CPU 使用率が低下します。 (下図に示すように) は 100% です)、安全を期すために、4C6G を構成することをお勧めします。

画像の説明

さらに、テストのこの段階では、プライベートネットワークの理由により、ディスク I/O パフォーマンスと外部ネットワーク帯域幅の要件が非常に低く、対応する具体的なパフォーマンス要件は公式 ETH2.0 でテストする必要があります。テストネットワーク。

フェーズ2比較試験

副題

第 1 段階では主に、さまざまな数の検証者によるサーバーリソースへの負荷をテストしましたが、さらに、検証者のブロック生成と監視も検証者にとって重要な指標です。この目的のために、比較テストを実施しました。同じネットワーク内で、比較テストのために異なるリージョンに異なる数のバリデータがデプロイされます。

副題

テスト中に、CPU、メモリ、ディスク IO、ネットワーク帯域幅 IO、生成されるべきブロックの数、生成される実際のブロック数、監視されるべきブロックの数、監視される実際のブロック数などの指標を収集します。各インスタンスサーバー。

副題

以下はテストケースです。

画像の説明

表2

ETH1.0 ネットワークは、香港に 2 台、サンパウロに 1 台の計 3 台の 2 コア 4G クラウドサーバーで構成されています。ブロック時間は 15 秒に設定されます。

当社は、香港、シンガポール、ロサンゼルス、フランクフルト、サンパウロ、ロンドンにビーコンチェーンノードとバリデーターノードを導入しました。各リージョンのビーコンチェーンノードとバリデーターノードはイントラネットを介して接続されます。構成とバリデーターの対応する数を上の図に示します。

インスタンス 1 とインスタンス 2 には両方とも 1,000 個のバリデーターがあります。違いはバリデーターノードの構成にあります。バリデーターノードの構成は、インジケーターに対するさまざまな構成を持つバリデーターの数の影響を比較するために使用されます。

各リージョンのビーコンチェーンノードは他のノードに接続されます。

副題

テストネットパラメータの選択

まず、ETH1.0 ネットワーク上にデポジットコントラクトをデプロイし、必要な数のバリデータキーを生成した後、デポジットトランザクションをバッチで送信しました。 Prysm は次のパラメータが変更された状態で起動します。
MinGenesisActiveValidatorCount は 8192 に設定されています。テストには 40,000 個のバリデーターが含まれているため、これは満足です。
Eth1FollowDistance は 20 に設定されます。つまり、ETH1.0 ネットワーク上の入金契約は 5 分後に ETH2.0 ネットワークによって監視されます。
SecondsPerETH1Block は 15 に設定されており、これは ETH1.0 ネットワーク内の各ブロックの時間設定と一致しています。

実際、最も早い開始時間に設定されたバリデーターの最小数を満たすためにすべての入金トランザクションを事前に送信したため、ETH2.0 ネットワーク全体は 1599811207(2020-09-11T16:00:07+08:00) に開始されました。。

副題

統計とテスト結果

さらに、データをクエリするために ETH2.0 プライベートネットワークに接続するためのビーコンチェーンノードをデプロイしました。パラメータ --slots-per-archive-point=1 を追加して各ブロックのデータを永続的に保存し、クエリを高速化します。パラメータ --rpc-max-page-size=1000 を追加すると、毎回より多くのデータをクエリできるため、リクエストの数が減り、全体的な速度が向上します。

ネットワークが比較的安定していた期間を選択し、75 エポック (約 2020-09-12 00:00:00 +0800) から 1200 エポック (2020-09-17 00:00:00 +0800) までのサンプリングを行いました。このセグメントを取得する一定期間内のさまざまなインスタンスのブロック生成データと検証者の証人データが分析され、次の結果が得られます。
異なる地域のバリデーター証人は若干異なります。

画像の説明

表3

ここでは、証人率を、一定期間に含まれる証人の数で割ったものを、それに割り当てられた証人の数で割ったものと定義します。一般に、バリデーターの数が増加すると、証人率が低下することを理解するのは難しくありません。しかし、例 3 では、検証者の数はわずか 2,000 人ですが、証人率は 6,000 人、さらには 10,000 人よりも低くなります。

各検証者の割合を範囲に応じて分割し、次のデータを取得します。

画像の説明

各インスタンスの検証者の数が異なるため、変換率はより直感的になります。

画像の説明

表5

このため、インスタンス 3 のログを確認したところ、ビーコンチェーンノードおよび他のノードと ETH1.0 との接続が安定していないことがわかり、これが異常な目撃率の原因となっていると推測されますが、後で確認する必要があります。

副題

このラウンドのテストでは、次の表のパフォーマンスインデックスデータを観察しました。

画像の説明

Beacon Chain Node

表6

Validator Node

インスタンス 1 ～ 5 では、ビーコンチェーンノードの CPU 使用率は 5% ～ 10% の間であり、インスタンス 6 のビーコンチェーンノードの CPU 使用率は約 12% です。メモリは 12% から 17% の間で着実に増加しており、ディスク IO と帯域幅には大きな違いはありません。

さらに、検証キーファイルの生成には、推奨される Python コマンドラインを使用します。道具このツールのキー生成効率は比較的低く、マルチコアマシンでは 1 コアしか占有せず、2000 個のキーペアを生成するには約 2.5 時間かかります。一方、Validator Nodeのキーペアのインポートもシングルコア実行で、2000個のキーペアのインポートにかかる時間は約40分です。

副題

このラウンドのテストを通じて、プライベートネットワークでバリデーターの数の増加がノード上のすべてのバリデーターのブロック生成速度に影響を与えることを観察しました。単一のバリデーターの場合、最良の場合と最悪の場合、平均的なウィットネス1日あたり約10ブロック減ります。ブロック生成に関しては、テストでは違いが見つかりませんでした。 CPU と帯域幅と比較すると、バリデータの数が増えると、メモリとディスク IO の使用量がより明らかに増加します。