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