イーサリアムのアーカイブ・ノード

アーカイブ・ノードは、すべての履歴状態のアーカイブを構築するように設定されたイーサリアムクライアントのインスタンスです。特定のユースケースにおいて有用なツールですが、フル・ノードよりも運用が難しい場合があります。

前提条件

イーサリアムのノードの概念、そのアーキテクチャ、同期戦略、およびノードの運用と使用に関する実践について理解しておく必要があります。

アーカイブ・ノードとは

アーカイブ・ノードの重要性を理解するために、「状態」の概念を明確にしましょう。イーサリアムは「トランザクションベースの状態遷移マシン」と呼ぶことができます。イーサリアムは、トランザクションを実行して自身の状態を変更するアカウントとアプリケーションで構成されています。各アカウントとコントラクトに関する情報を持つグローバルデータは、状態と呼ばれるトライデータベースに保存されます。これは実行レイヤー (EL) クライアントによって処理され、以下が含まれます。

アカウントの残高とナンス
コントラクトのコードとストレージ
コンセンサス関連のデータ（例：ステーキング・デポジット・コントラクト）

ネットワークとやり取りし、新しいブロックを検証および生成するために、イーサリアムクライアントは最新の変更（チェーンの先端）と現在の状態を常に把握しておく必要があります。フル・ノードとして設定された実行レイヤークライアントは、ネットワークの最新の状態を検証して追跡しますが、チェーンの再編成（reorg）を処理し、最近のデータへの高速なアクセスを提供するために、過去のいくつかの状態（例：過去128ブロックに関連する状態）のみをキャッシュします。最近の状態は、すべてのクライアントが受信したトランザクションを検証し、ネットワークを使用するために必要とするものです。

状態は特定のブロックにおけるネットワークの瞬間的なスナップショットであり、アーカイブは履歴のリプレイであると想像できます。

履歴状態はネットワークの運用に必要ではなく、クライアントがすべての古いデータを保持することは無駄に冗長であるため、安全にプルーニング（削除）できます。最近のブロック（例：先頭から128ブロック前）より前に存在した状態は、事実上破棄されます。フル・ノードは、履歴のブロックチェーンデータ（ブロックとトランザクション）と、要求に応じて古い状態を再生成するために使用できる時折の履歴スナップショットのみを保持します。これは、EVMで過去のトランザクションを再実行することによって行われますが、目的の状態が最も近いスナップショットから遠く離れている場合、計算負荷が高くなる可能性があります。

しかし、これはフル・ノードで履歴状態にアクセスすると大量の計算を消費することを意味します。クライアントは、すべての過去のトランザクションを実行し、ジェネシスから1つの履歴状態を計算する必要があるかもしれません。アーカイブ・ノードは、最新の状態だけでなく、各ブロックの後に作成されたすべての履歴状態を保存することでこれを解決します。基本的には、より大きなディスク容量を必要とするというトレードオフになります。

ネットワークは、すべての履歴データを保持および提供するためにアーカイブ・ノードに依存しているわけではないことに注意することが重要です。前述のように、すべての履歴の中間状態はフル・ノードで導出できます。トランザクションは任意のフル・ノードに保存されており（現在は400GB未満）、リプレイしてアーカイブ全体を構築することができます。

ユースケース

トランザクションの送信、コントラクトのデプロイ、コンセンサスの検証など、イーサリアムの通常の利用では、履歴状態へのアクセスは必要ありません。ユーザーがネットワークとの標準的なやり取りを行うためにアーカイブ・ノードを必要とすることは決してありません。

状態アーカイブの主な利点は、履歴状態に関するクエリへの迅速なアクセスです。たとえば、アーカイブ・ノードは次のような結果を即座に返します。

ブロック15537393におけるアカウント 0x1337... のETH残高はいくらだったか？
ブロック1920000におけるコントラクト 0x 内のトークン 0x の残高はいくらか？

上で説明したように、フル・ノードはCPUを使用し時間がかかるEVMの実行によってこのデータを生成する必要があります。アーカイブ・ノードはディスク上のデータにアクセスし、即座に応答を返します。これは、インフラストラクチャの特定の部分にとって有用な機能です。例えば：

ブロックエクスプローラーなどのサービスプロバイダー
研究者
セキュリティアナリスト
分散型アプリケーション (dapp) の開発者
監査とコンプライアンス

履歴データへのアクセスを可能にする様々な無料のサービスもあります。アーカイブ・ノードの運用はより要求が厳しいため、このアクセスはほとんど制限されており、時折のアクセスにのみ機能します。プロジェクトで履歴データへの継続的なアクセスが必要な場合は、自分でアーカイブ・ノードを運用することを検討すべきです。

実装と使用方法

この文脈におけるアーカイブ・ノードとは、状態データベースを処理し、JSON-RPCエンドポイントを提供する、ユーザー向け実行レイヤークライアントによって提供されるデータを意味します。設定オプション、同期時間、データベースのサイズはクライアントによって異なる場合があります。詳細については、使用するクライアントのドキュメントを参照してください。

独自のアーカイブ・ノードを起動する前に、クライアント間の違い、特に様々なハードウェア要件について学んでください。ほとんどのクライアントはこの機能に最適化されておらず、そのアーカイブには12TB以上の容量が必要です。対照的に、エリゴンのような実装は同じデータを3TB未満で保存できるため、アーカイブ・ノードを運用する最も効果的な方法となります。

推奨される実践

ノードの運用に関する一般的な推奨事項とは別に、アーカイブ・ノードはハードウェアとメンテナンスの面でより要求が厳しい場合があります。エリゴンの主要な機能 (opens in a new tab)を考慮すると、最も実用的なアプローチはエリゴンクライアントの実装を使用することです。

ハードウェア

常にクライアントのドキュメントで、特定のモードのハードウェア要件を確認するようにしてください。アーカイブ・ノードの最大の要件はディスク容量です。クライアントによって異なりますが、3TBから12TBの範囲です。大量のデータにはHDDがより良い解決策と考えられるかもしれませんが、同期を行い、チェーンの先頭を常に更新するにはSSDドライブが必要になります。SATA (opens in a new tab)ドライブで十分ですが、少なくともTLC (opens in a new tab)のような信頼できる品質のものであるべきです。ディスクは、デスクトップコンピュータや十分なスロットを持つサーバーに取り付けることができます。このような専用デバイスは、高い稼働率でノードを運用するのに理想的です。ノートパソコンで運用することも完全に可能ですが、携帯性には追加のコストがかかります。

すべてのデータは1つのボリュームに収まる必要があるため、例えばRAID0 (opens in a new tab)やLVMなどでディスクを結合する必要があります。また、低レベルのエラーなしにデータがディスクに正しく書き込まれることを保証する「コピーオンライト（Copy-on-write）」をサポートしているため、ZFS (opens in a new tab)の使用を検討する価値もあるかもしれません。

偶発的なデータベースの破損を防ぐための安定性とセキュリティをさらに高めるために、特にプロフェッショナルなセットアップでは、システムがサポートしている場合はECCメモリ (opens in a new tab)の使用を検討してください。RAMのサイズは一般的にフル・ノードと同じであることが推奨されますが、RAMが多いほど同期を高速化するのに役立ちます。

初期同期中、アーカイブモードのクライアントはジェネシス以降のすべてのトランザクションを実行します。実行速度は主にCPUによって制限されるため、より高速なCPUは初期同期時間の短縮に役立ちます。平均的な消費者向けコンピュータでは、初期同期に最大1か月かかる場合があります。