フルノードとアーカイブノードの違いを解説：ブロックチェーンノードガイド |QuicknodeHyperliquid ノードを運用していますか？Hyperliquid のピアリング機能を使用して、ブロックおよびフルメンプールへのダイレクトパスを有効にします。
詳細はこちら 回答>ブロックチェーンノードについて学ぶ>フルノードとアーカイブノードの違い // Tags
フルノードとアーカイブノードethereum アーカイブノード
要約：フルノードはブロックチェーンの現在の状態を保存し、すべての新しいトランザクションやブロックを検証しますが、ストレージ容量を節約するために古い履歴データは削除します。アーカイブノードは、フルノードが行うすべての処理に加え、ジェネシスブロック以降におけるチェーンの完全な履歴状態を保持します。どちらのタイプが必要かは、アプリケーションが現在のデータを必要とするか、あるいは任意の時点における履歴状態へのアクセスを必要とするかによって異なります。
わかりやすい説明
すべてのブロックチェーンノードはチェーンをダウンロードして検証しますが、すべてのノードが同量のデータを保持しているわけではありません。これは、図書館と国立公文書館の違いに例えることができます。フルノードは図書館のようなもので、現在流通しているすべての本を所蔵しており、今棚に何があるかを教えてくれます。一方、アーカイブノードは国立公文書館のようなもので、これまでに刊行されたすべての本、すべての版、そして創設当初にさかのぼる絶版になった原稿までをすべて所蔵しています。
Ethereum において、フルノードは、すべてのアカウント、残高、スマートコントラクトの現在の状態に加え、チェーンの整合性を検証するのに十分な最近のブロック履歴を保存します。デフォルトでは、ほとんどのEthereum クライアントは、直近の 128 ブロック分の状態データをすぐにアクセスできる状態で保持しており、これはネットワーク上の活動のおよそ過去 25 分から 30 分分をカバーしています。 それより古いデータは、ディスク容量を節約するために削除されます。技術的には、フルノードはジェネシスブロックからのトランザクションを再生することで古い状態を再構築することは可能ですが、その処理は非常に時間がかかり、計算コストもかかります。
アーカイブノードは、プルーニングを完全に省略します。このノードは、ブロックチェーンの開始以来、すべてのブロックごとにブロックチェーンの状態全体のスナップショットを保存します。つまり、チェーンの履歴上のどの時点であっても、任意のウォレットの残高、任意のスマートコントラクトのストレージ、または任意のトランザクションの出力を照会して、即座に結果を得ることができます。 リプレイは不要です。その代償として、ストレージ容量が必要となります。Gethを実行するフルEthereum ノードには、約1TBのSSD容量が必要です。Gethを実行するアーカイブノードには12TB以上が必要であり、その容量は日々増加しています。ストレージ効率に優れたクライアントであるErigonを使用すれば、アーカイブに必要な容量を約2TBまで抑えることができますが、それでもプルーニング済みのフルノードに比べれば依然として大幅に多い容量となります。
SOC 2 タイプ II 認証取得・ISO 27001
フルノードとアーカイブノードの違いは何ですか？
属性 | フルノード | アーカイブノード |
|---|
過去の状態 | 約128ブロック後にプルーニングされる | 『ジェネシス』から引き継がれた |
ストレージ（Ethereum 、Geth） | 約1TB | 12TB以上（Erigon上では約2TB） |
過去のステータス照会 | 欠落しているトライノードのエラーを返す | どのブロック高でも即座に |
同期時間 | 数時間から数日 | 数日から数週間 |
こんな方に最適 | ウォレット、dApp、決済、リアルタイム読み取り | 調査、分析、監査、追跡 |
フルノードが必要な場合
フルノードは、あらゆるブロックチェーンネットワークの要です。フルノードは、新しいブロックをすべて検証し、コンセンサスルールを適用し、無効な取引を拒否するとともに、ブロックチェーン全体を保存しないライトウェイトクライアントにとっての信頼の拠り所となります。ウォレットや、現在の残高と直近の取引データのみを必要とするDapp、あるいはネットワークに取引を送信するサービスを構築する場合、フルノードがあれば十分です。
実運用されているアプリケーションのほとんどは、このカテゴリーに分類されます。分散型取引所（DEX）は、現在のトークン残高を把握し、リアルタイムでスワップを実行する必要があります。決済処理業者は、受信した取引が有効であり、確認済みであることを検証する必要があります。ウォレットは、現在の残高を表示し、新しい取引をブロードキャストする必要があります。これらのユースケースのいずれも、50万ブロック前の特定のアカウントの残高を照会する必要はありません。現在の状態さえあれば十分であり、フルノードはアーカイブノードよりもはるかに低いハードウェア要件でそれを提供します。
フルノードは、ネットワークの健全性においても極めて重要な役割を果たしています。ブロックチェーン上で稼働する独立したフルノードが多ければ多いほど、ネットワークはより分散化され、耐障害性が高まります。各フルノードが独立してチェーンを検証するため、単一のノードやノードのグループが一方的に記録を改ざんすることはできません。フルノードを稼働させることは、ブロックチェーンのセキュリティモデルに参加し、それを支えるための最も直接的な方法です。
アーカイブノードが必要な場合
アプリケーションがブロックチェーンの履歴データに依存する場合、アーカイブノードは不可欠となります。チェーンの履歴上の任意の時点におけるトランザクションやアカウントの状態をユーザーが検索できるブロックエクスプローラーを構築している場合は、アーカイブへのアクセス権が必要です。トークンの保有状況、スマートコントラクトの状態、またはDeFiプロトコルの指標が時間の経過とともにどのように変化したかを追跡する分析を実行している場合も、アーカイブへのアクセス権が必要です。 HardhatやFoundryなどの開発ツールを使用してmainnet をフォークし、テストのために過去の状況をシミュレートする場合も、アーカイブへのアクセスが必要です。
特定の技術的なシナリオにおいても、アーカイブノードが必要となります。過去のブロック番号（ほとんどのクライアントでは、直近128ブロックより古いもの）で eth_getBalance や eth_call を呼び出すには、アーカイブデータが必要です。数週間前に失敗したトランザクションの実行を追跡してデバッグする場合にも、アーカイブデータが必要です。 清算イベントを監査するために、特定のブロック時点での貸付プロトコルの状態を再構築する場合にも、アーカイブデータが必要です。アーカイブノードがない場合、データはプルーニングされているため、これらのクエリは「missing trie node」エラーを返します。
アーカイブノードのターゲット層は限定的ですが、極めて重要です。具体的には、ブロックチェーン分析プラットフォーム、フォレンジック調査員、プロトコル監査人、The Graphのようなインデックスサービス、そして現在だけでなく過去に関する質問に答える必要があるあらゆるアプリケーションが挙げられます。
フルノードでは、なぜ履歴クエリが失敗するのでしょうか？
フルノードは、おおよそ直近128ブロックより古いステートを削除するため、それより古いブロックで eth_getBalance や eth_call を呼び出すと、「トライノードが見つからない」というエラーが返されます。トランザクションの記録自体は残っていますが、その時点のステートは容量を節約するために削除されています。 これを復元するには、アーカイブノードまたは保存されたデータセットが必要であり、これがブロックチェーンの履歴データにアクセスするための基本的な考え方です。また、このプリニングが理由となって、大規模なブロックチェーンデータのクエリには、多くの場合、単一のフルノードだけでは不十分となります。
各ノードタイプには、どれくらいのストレージ容量が必要ですか？
ストレージは実用上の最大の違いであり、チェーンやクライアントによって異なります。表には、Ethereum の代表的な数値が示されています。これらの数値は継続的に増加しており、これが多くのチームが「リアルタイムのブロックチェーンデータと履歴データ」の項で説明したように、代わりにプロバイダーを通じて履歴状態を照会する理由の一つとなっています。
設定 | おおよその保存期間 | 注記 |
|---|
フルノード（Geth） | 約1TB | プルーンの以前の状態 |
アーカイブノード（Geth） | 12TB以上 | すべての状態のスナップショットを保存します |
アーカイブノード（Erigon） | およそ2TB | ストレージ効率に優れたクライアント |
ストレージとコストの現実
独自のアーカイブノードを運用することは、多大な負担を伴います。Ethereum 単体で 12TB 以上のストレージ容量が必要となるだけでなく、十分なクエリ速度を確保するためには高性能な SSD（HDD ではなく）が必要となります。また、アーカイブノードの同期をゼロから行うには、ハードウェアやインターネット接続の状況によっては数週間かかることもあります。初期同期中にノードの同期がずれたり、クラッシュしたりした場合は、最初からやり直す必要があるかもしれません。これを、アプリケーションがサポートするすべてのチェーンに当てはめると、インフラストラクチャへの負担は急速に増大します。
そのため、ほとんどの開発者やチームは、アーカイブノードを自ら運用するのではなく、インフラプロバイダーに依存しています。Quicknode では、すべてのプランでアーカイブデータへのアクセスが含まれており、基盤となるストレージや同期プロセスを管理することなく、サポートされているあらゆるチェーン上の過去の状態をクエリできます。 過去10分間のデータが必要であっても、ジェネシスまでの完全な履歴が必要であっても、QuicknodeのCore APIは、同じRPCendpoint を通じて処理します。専用かつ隔離されたインフラストラクチャを必要とするチーム向けに、Quicknode のDedicatedClusters は、稼働時間のSLAが保証され、予測可能なパフォーマンスを備えたプライベートなアーカイブノードへのアクセスを提供します。
1つのendpoint で、フルデータとアーカイブデータの両方を提供することは可能ですか？
はい。多くのプロバイダーは、単一のURLを通じて、現在の状態に関するリクエストをフルノードへ、過去の状態に関するリクエストをアーカイブノードへそれぞれルーティングしているため、2つの設定を管理する必要はありません。アプリケーション側からは、 endpoint という1つのRPC呼び出しだけで、直近のクエリと過去のクエリの両方に対応できます。
参考資料
よくある質問
アーカイブノードはフルノードと同じものですか？
いいえ。アーカイブノードはフルノードが行うすべての処理を行うほか、ジェネシス以降のすべての過去の状態スナップショットも保持しています。フルノードはディスク容量を節約するために古い状態を削除するため、任意の過去の状態に関するクエリには応答できません。
自分のDappにはアーカイブノードが必要ですか？
ほとんどのDapp、ウォレット、決済アプリは現在の状態情報さえあれば十分なので、フルノードがあれば十分です。アーカイブへのアクセスが必要となるのは、主にブロックエクスプローラー、分析、監査、mainnet のフォーク、および過去の取引の追跡を行う場合です。
なぜ古いブロックで eth_getBalance が失敗するのですか？
フルノードはそのブロックの状態をプリニングしているため、この呼び出しではトライノードが見つからないというエラーが返されます。すべての状態スナップショットを保持しているアーカイブノードにクエリを実行すれば、この問題は解決されます。
Ethereum のアーカイブノードには、どれくらいの容量が保存できますか？
Gethでは約12TB以上かかるのに対し、フルノードでは約1TBです。ストレージ効率に優れたErigonクライアントを使用すると、アーカイブの保存容量は約2TBまで削減できますが、これらの数値はいずれも時間の経過とともに増加していきます。
アーカイブノードはインデックス作成とどのように関連しているのでしょうか？
インデクサーは、クエリ可能なデータベースを構築するために、アーカイブノードやバックフィルされたデータセットから履歴データを読み込むことがよくあります。この層の仕組みについては、「ブロックチェーンインデクシングとは」をご覧ください。
