メインコンテンツへスキップ
Change page

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

アーカイブノードは、すべての状態の履歴をもつアーカイブをビルドするように構成されたイーサリアムクライアントのインスタンスです。 特定のユースケースにおいて、アーカイブノードは便利なツールですが、フルノードよりも実行する難易度が高くなっています。

前提知識

イーサリアムノードのコンセプト、 アーキテクチャ、同期戦略、実行の経験、ノードの使用などの知識があることを前提にしています。

アーカイブノードとは

アーカイブノードの重要性を理解するには、まず「状態」の概念を明確にする必要があります。 イーサリアムは、トランザクションベースの状態マシンと言えます。 トランザクションを実行するアカウントとアプリケーションで構成され、トランザクションはイーサリアムの状態を変更します。 各アカウントおよびコントラクトに関する情報を持つグローバルデータは、状態と呼ばれるツリーデータベースに保存されます。 グローバルデータは、実行レイヤー(EL)クライアントが管理します。具体的には、以下のものが含まれます。

  • アカウント残高とノンス
  • コントラクトコードとストレージ
  • コンセンサス関連のデータ(例: ステーキングデポジットコントラクト)

イーサリアムクライアントでは、ネットワークとやり取りし、新しいブロックを検証・生成するために、常に最新の状態である「最新の変更(チェーンの先端)」を把握している必要があります。 フルノードとして構成された実行レイヤークライアントは、ネットワークの最新の状態を検証・追跡しますが、一部の過去の状態のみをキャッシュします。例えば、 最後の128ブロックに関連付けられた状態では、チェーンの再編成を処理して、最新のデータに素早くアクセスすることができます。 この最新の状態は、すべてのクライアントにおいて受信したトランザクションを検証するのに必要であり、ネットワークで使用されます。

状態は、特定のブロックにおけるネットワークの状態を瞬間的に記録したスナップショットであり、アーカイブは、ネットワークの状態の履歴を再生したものと考えることができます。

状態の履歴は、安全に取り除くことができます。これは、ネットワークの動作には関係なく、クライアントが古いデータをすべて保持しても意味がないためです。 最近のブロック(例: 先頭から128ブロック)より前の状態は、事実上破棄されます。 フルノードは、ブロックチェーンの履歴データ(ブロックとトランザクション)と、リクエストに応じて古い状態を再生成するのに使用する予備のスナップショットの履歴のみを保存しています。 再生成は、EVMで過去のトランザクションを再実行することによって行われます。取得したい状態が最も近いスナップショットからか遠く離れている場合、計算負荷が高くなる傾向があります。

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

ネットワークでは、すべての履歴データを保存・提供するのに、アーカイブノードに依存していないことが重要です。 上記で述べたように、すべての状態の一時的な履歴は、フルノードから導出することができます。 トランザクションは、どのフルノード(現在は400G未満)にも保存されています。これらのトランザクションを再実行することで、アーカイブ全体を構築することができます。

ユースケース

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

状態のアーカイブによる主なメリットは、状態の履歴に関するクエリに素早くアクセスできることです。 例えば、アーカイブノードは、次の結果を即座に返します。

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

上述したように、フルノードでは、EVMを実行してこのデータを生成する必要があります。これはCPUを使用し、処理に時間がかかります。 一方、アーカイブノードでは、ディスク上のデータにアクセスするため、即座に応答を返すことができます。 これは、インフラストラクチャの側面において、以下の役割を担う人に役立ちます。

  • ブロックエクスプローラなどのサービスプロバイダー
  • 研究者
  • セキュリティアナリスト
  • 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(opens in a new tab)を使って結合する必要があります。 ZFS(opens in a new tab)では、低レベルのエラーの影響を受けずに正しいデータを確実に書き込む「コピーオンライト」をサポートしているため、検討する価値があるかもしれません。

特に専門的なセットアップにおいては、さらなる安定性とセキュリティのために、偶発的なデータベースの破損を防ぐECCメモリ(opens in a new tab)の使用を検討してください。 RAMのサイズは通常、フルノードと同等のサイズにすることが推奨されますが、RAMのサイズが大きいほど、同期の速度は向上します。

アーカイブモードのクライアントは、最初の同期中に、ジェネシス以降のすべてのトランザクションを実行します。 CPUによって実行速度が異なるため、CPUが高速であれば、最初の同期にかかる時間を短くすることができます。 通常のコンシューマー向けのコンピューターでは、最初の同期に最大1か月程度かかる場合があります。

参考文献

back-to-top ↑

この記事は役に立ちましたか?