Beam Sync: Ethereum ノードを同期する新しい方法
編集者注: この記事は以下からのものです。イーサリアム愛好家 (ID: ethfans)イーサリアム愛好家 (ID: ethfans)
、著者：Jason Carver、翻訳および校正：Chen Liang & A Jian、Odailyの許可を得て転載。
文章
ノードの同期エクスペリエンスを向上させる理由は何ですか?
オンチェーン アプリケーションと対話するために (Metamask、Gnosis-Safe などを介して) Infura をまだ使用している人がどれだけいるかを考えると、少し身がすくんでしまいます。 Infura のサービスは優れていますが、ほとんどのユーザーが独自のノードを実行しないのは明らかに正しくありません。最も有能で意欲的な開発者であっても、Infura への依存を完全に取り除くことはできません。現時点では、イーサリアムの「自己検証」ビジョンの重要な部分はまだ完了していません。
私たちのチームは、この傾向を逆転させるために自分たちの役割を果たしたいと考えています。私たちの使命は、ネットワーク上のノードの数、特に愛好家、研究者、開発者によって運営されるノードの数をできる限り増やすことです。なぜ独自のノードを実行しなかったのかと尋ねると、その答えは次のようなものでした。「クライアント ソフトウェアをインストールし、ブロックチェーンを同期しようとしましたが、まったく同期しないようでした。それで、他にやるべきことがあるのでやめました」する。"
最初のレベルのタイトル
既存の同期方法
副題
Full Sync（完全同期方式）
完全同期アプローチでは、genesis ブロック以降のすべてのブロックを実行します。ジェネシス ブロックは、初期ジェネシス状態をマークします (状態の内容には、アカウント残高、契約バイトコード、契約ストレージ コンテンツなどが含まれます)。いわゆる「実行ブロック」とは、ブロックがダウンロードされるたびに、以前の状態が読み取られて新しい状態が (ブロックの内容に従って) 生成され、その新しい状態が状態ルートの検証に使用されることを意味します。ブロック ヘッダー (ブロック ブロックが有効なブロックではないことを確認するため)。イーサリアムメインネットでは完全同期は非常に遅く、ネットワークが老朽化するにつれて、完全同期方法を使用して最新のブロックに同期するのにますます時間がかかるようになります。そこで人々は「高速同期」方式を開発しました。
副題
Fast Sync（高速同期方式）
高速同期が開始ブロックを実行する前に、必要なブロック状態には、コントラクト バイトコード、アカウント、およびコントラクト ストレージ コンテンツが含まれます。これらの値は、トランザクションの実行時に読み取る必要がある場合があります。したがって、高速同期アプローチでは、ブロックが開始される前の状態のスナップショットを他のピアから取得する必要があります。スナップショットは状態ルート ハッシュ値でマークされます。いわゆる状態ルート ハッシュ値は、すべての状態コンテンツのハッシュ マークル ツリー ルート値です。ノードはこの状態ルート ハッシュを使用して、他のピアからダウンロードされた状態データがブロック内のマイナーによって要求された状態と一致することを確認します。
高速同期メソッドが必要な状態をすべてダウンロードした後は、ノードにはトランザクションの実行に必要なすべてのデータがすでに存在していることになります。この時点から、ノードは完全同期モードに切り替わり、開始ブロックの前に完全同期プロセスが完了したノードと同様に、開始ブロックからブロックを 1 つずつ実行できます。
副題
その他の方法
他の高速同期方法には、ワープ同期や、現在実証されていないいくつかの同期方法が含まれます。より抽象的なレベルでは、それらはすべて、さまざまな形式の高速同期メソッドに属します。さらに、これらの他の同期方法の原理を理解しても、ビーム同期戦略を理解するのには役立ちません。そのため、これらの同期原理はこの記事の焦点ではありません。これについては後ほど説明します。
最初のレベルのタイトル
クイック同期方法の速度はどれくらいですか?
高速同期方法は、現在の主要なネットワーク オペレーティング環境ではいくつかの課題に直面しています。同期には大量のデータ、さらには 100 GB を超えるデータをダウンロードする必要があるためです。そのため、上記の 2 番目のステップ「すべての状態の取得」で可能になる可能性があります。図』は長い間行き詰まる予定でした。
30 分以内にすべての状態データをダウンロードできない場合 (ネタバレ注意: 本当に完了することはできません)、ピボット (ピボット)、つまり新しいブート ブロックに変更して同期を再開する必要があります。 0 からではありませんが、ブロックのダウンロードと検証にかかる時間も増加します。
最初のレベルのタイトル
概要
ビームシンク方式
副題
ビーム同期方式は高速同期方式を直接改良したものであり、2 つの同期方式の違いは、ビーム同期方式では最初にスタートアップ ブロックを直接実行し、ローカル データベースに欠落している状態データのみを要求することです。 、入力状態と出力状態をローカルに保存します。ブロックを実行した後、次のブロックに同期してプロセスを繰り返し、必要に応じて欠落しているデータを要求します。
時間の経過とともに、欠落データはますます少なくなります。特定の状態にアクセスされない場合、クライアントは決してその状態を要求しない (したがって、状態データのこの部分を取得することはない) ことに注意してください。そのため、これらのギャップを埋めるためにバックグラウンドで別のプロセスを実行します。このバックフィル プロセスを通じて、Beam Sync は最終的にすべての状態データをフェッチしてローカルに保存し、ノードは完全に同期された状態に切り替えることができます。
各ブロックの実行に必要なデータセットを「ブロック監視」と呼びます。マークル ツリーの構造のおかげで、完全な状態をダウンロードすることなく、証人データが実際にこの状態から取得されたものであることを証明できます (翻訳者注: これはいわゆる「マークル証明」です)。
副題
簡単にするために、ブロックの実行に必要なデータ要素の数を指すために「ブロック監視データ サイズ」を使用します。このようなデータ要素は、メインアカウントのステートツリー上のノード、コントラクトストレージツリー上のノード、またはコントラクトの完全なバイトコードである可能性があります（訳者注：ここでの「ステートツリー」、「ストレージツリー」はすべてマークルツリー構造のデータです） ）。
ブロック監視データ サイズの分析は、ビーム同期方法のパフォーマンスを理解する鍵となります。高速同期メソッドでは、最初のブロック (開始ブロック) を実行する前にすべての状態データをダウンロードする必要がありますが、ビーム同期では、ダウンロードされたブロック監視データに完全な状態の 3 分の 1 が含まれている場合、1 つのブロックの監視データをダウンロードするだけで済みます。 1 つ目は、Beam Sync が Fast Sync の約 3 倍効率的に実行されることです。
したがって、明らかに、次のステップは、メインネット監視データが実際にどのくらいの大きさであるかを確認することです。直接結論を出すには時期尚早かもしれませんが、初期のテスト結果では、3000 個のステート ツリー ノードが妥当な推定値 (90% の信頼水準) であることが示唆されています。メイン ネットワークの合計状態情報には 3 億以上のツリー ノードがあります。
副題
ビーム同期の速度向上
「実行開始」時間という新しい基準を定義してみましょう。これは、空のデータベースでノードを開始してから、最新のブロックの完全なインポートが完了するまでにかかる時間です。
Beam が 3,000 のステート ツリー ノードをダウンロードするだけでよく、高速同期では 3 億のツリー ノードをダウンロードする必要がある場合、Beam Sync メソッドの速度制限を決定できます。メインネットを同期する場合、「開始から実行まで」の時間になる可能性があります。最大100,000倍のブーストを獲得しましょう！
ただし、Beam Sync アプローチでは、実際には 100,000 倍の改善を達成できないことがよくあります。理由には次のようなものがありますが、これらに限定されません。
ブロック監視データはオンデマンドで決定されます。つまり、どの状態データが必要になるかを事前に予測することはできません (1 つのデータを受信した後にのみ、次に必要なデータが何であるかを決定できます)。したがって、ピアノードからデータをリクエストする場合、一度に 1 つの状態データのみをリクエストできます。対照的に、Fast Sync は一度に最大 384 個のツリー ノードを要求できるため、Beam Sync はピア ネットワークの遅延の影響をより受けやすくなります。
高品質で低遅延の同期ノードを見つけるには時間がかかります。正直に言うと、どのようなピアノードに遭遇するかは真のランダムイベントです。
高速同期方式とは異なり、ビーム同期方式では開始ブロックの後にブロック状態のダウンロードが継続されるため、ブロックのインポート時間も遅くなります。これについて直感があれば、ブロック監視を収集する平均時間がブロックを生成する平均時間よりも長い場合、問題が悪化することに気づくかもしれません。
副題
ビームシンクラグ
ブロック監視データの収集の遅延は徐々に増加する可能性があり、その後、Beam 同期ノードが 5 分遅れていることがわかります。つまり、ローカルにある最新のブロックは、実際には 5 分前にネットワーク全体によって生成されたブロックです。これは、RPC が現在のノード アカウント残高を呼び出すと、ノードが 5 分前の残高をフィードバックすることを意味します。
Beam Sync Pivot
事例テストでは、遅延時間が 1 分から 20 分の範囲で大きく異なるのが一般的です。幸いなことに、ブロック同期の遅れから回復するためのいくつかのトリックがあり、実際、一般的に言えば、遅れが多ければ多いほど回復がうまくいき、ラグタイムの大きな変動につながります。その後、急速に追いつき、サイクルが繰り返されます。
ブロックが遅れている場合に、より早く追いつくことができる理由の 1 つは、複数のブロックの目撃データを事前かつ同時に生成できるためです。結局のところ、これらの将来のブロックを利用できるのは、遅れている場合のみです。もちろん、必要なブロック データの収集にかかる時間が常にブロックの生成時間を超える場合、ブロックチェーンの成長からますます遅れを取ることは間違いありません。これを計画してください。
副題
ビーム同期のピボット メカニズムは高速同期と似ており、ノードはスキップする一連のブロックを選択し、チェーンの先頭近くにある新しいブロック ヘッダーを選択します。その後、ビーム同期が再び開始され、ノードは正確には異なります。最初から同期しても、前回の同期のデータはすべて残っています。
さて、実際の状況がどのようなものかを見てみましょう。
最初のレベルのタイトル
Trinity クライアントでのビーム同期
副題
プロトタイプを発表
Trinity クライアントの新しいアルファ バージョンが先週発表されました。このバージョンには、ハイエンド ハードウェアで実行される Beam の同期メソッドのプロトタイプが含まれています。
注: ブロックのガス制限を 8M から 10M に引き上げると、平均ラグタイムが増加するようです。イスタンブールのアップグレードにより、ブロックチェーンに状態データを書き込むために必要なガス消費量が増加するため、ラグタイムが減少する可能性があります。
Trinity は現在まだアルファ版であり、最新版でも 1 ～ 2 日経つと突然同期が停止するなどの問題が多くあります。 Trinity クライアントのインストールには追加の作業が必要で、コマンド ラインの出力は混乱していました。したがって、Trinity は現在、興味があり、試してみることを気にしない開発者と研究者のみを対象としています。
未解決の問題は基本的に日々の開発で顕在化するため、これらの問題は「バックグラウンド ログのバグ」となります。現時点では、Beam Sync が実現不可能な夢になるのではないかと心配する人は誰もいないと言っても過言ではありません。ビーム同期に対するこの信頼性は新しいものです。しかし、今後も 1 か月前と同様に、解決すべき未知の問題が突然発生する可能性もあると考えています。
残りの作業
基本的なデバッグと実装の作業に加えて、他にもやるべきことがまだたくさんあります。 Trinity は、状態のバックフィル メカニズム (つまり、開始ブロックの前に古いイベント、トランザクション、データをダウンロードする) をまだ実装していません。現在、切り替えメカニズムをアクティブにする唯一の方法は Trinity を再起動することですが、ビーム同期方法に必要な最小ハードウェア構成は不明です (関連データの収集にご協力いただける皆様を歓迎します)。
上記の問題はすべて活発な研究開発が行われており、これは、これらの取り組みに対する後援と支援に対するイーサリアム財団のおかげで、Trinity に関する多くの作業の 1 つにすぎません。
最初のレベルのタイトル
Beam Sync の新機能は何ですか?
ビーム同期方法は、他の理論と同様、以前の研究成果に基づいています。最新の状態をダウンロードし、古いブロックの実行をスキップすることで同期を高速化する方法 (高速同期方法) は、私たちが発明したものではありません。完全な状態ではなく監視データに依存してブロックを実行し、実行を高速化する方法は私たちが発明したものではありません。詳細については、ステートレス クライアントを参照してください。
