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