---
title: "フルノード"
description: "検証を軸に、フルノード、Ethereum の実行・コンセンサスクライアント、同期チェックポイント、現在・過去の状態、プルーニング、RPC のプライバシー、ファイナリティ、運用容量を解説します。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# フルノード

> 教育目的の参考情報であり、投資助言やセキュリティ助言ではありません。フルノードも、正しいソフトウェア、チェーンとチェックポイントの設定、健全なピア、適時の更新、ローカル環境の安全性、ストレージおよびネットワークの可用性に依存します。

<a id="answer"></a>

## 直接の答え

フルノードは、プロトコルが必要とするデータをダウンロードし、ローカルのコンセンサス規則と実行規則に従ってブロックと状態遷移を検証し、その規則が選択したチェーンを追跡します。RPC プロバイダーに判断を委ねず、ピアから受け取った無効なデータを拒否できます。「フル」が示すのは検証責任であり、すべての過去状態の永久保存、ブロック生成、ステーキング、公開 API の提供、あるいはソフトウェアや設定ミスへの耐性ではありません。

プルーフ・オブ・ステークの Ethereum では、利用可能なフルノードは実行クライアントとコンセンサスクライアントを組み合わせます。実行クライアントはトランザクションと実行ペイロードを検証し、現在の実行状態を維持して JSON-RPC を提供します。コンセンサスクライアントはコンセンサス・オブジェクトを検証し、フォークチョイスを適用して、正当化とファイナライズを追跡します。バリデータークライアントは任意であり、ステーキングしたバリデーターが提案とアテステーションを行う場合にのみ必要です。

<a id="mechanism"></a>

## 仕組み

1. 検証目的とネットワークのスナップショットを定義します。プロトコル、チェーンとジェネシスの識別情報、フォーク予定、想定する `chainId`、現在およびファイナライズ済みのブロックハッシュ、クライアントのバージョン、同期方式、チェックポイントの入手元、プルーニング方式、RPC メソッド、過去状態の対象期間、必要な可用性を記録します。フルノードの要件はチェーンごとに異なります。
2. 独立した経路で入手して検証したクライアントを導入し、必要な構成要素を組み合わせます。現在の Ethereum では、認証済みのローカル Engine API を介して実行クライアントとコンセンサスクライアントを接続し、ステーキングする場合だけバリデーターを追加します。データディレクトリ、P2P ポート、RPC の公開範囲、署名者またはバリデーターの鍵は分離します。
3. 意図したトラストアンカーから起動します。ジェネシスからのフル同期はジェネシス以降を検証します。実行レイヤーの snap sync は比較的新しい認証済み状態から状態を構築・修復し、コンセンサスレイヤーのチェックポイント同期は弱い主観性チェックポイントから開始して以後のブロックを検証します。データベースを信頼する前に、ジェネシス情報、チェックポイントルート、チェーン ID、フォークダイジェスト、ファイナライズ済みヘッドを独立した経路で照合します。
4. 両方の処理系を監視します。実行・コンセンサスのピア、ヘッドとファイナライズの遅延、Engine API の状態、ステートルートの一致、時刻同期、ディスク増加量、入出力、メモリ、CPU、データベースエラー、フォークへの準備状況を確認します。「同期済み」とは、必要なクライアントが意図したチェーンで一致し、有効なデータを継続して取り込んでいる状態を指します。
5. 保存方針を照会要件に合わせます。プルーニングされたフルノードは現在状態と、検証に十分なブロック、レシート、スナップショットのデータを保持しますが、過去状態の再生成が必要になったり、過去状態の照会を拒否したりします。アーカイブ設定は過去の各状態を保存し、時点照会を高速化します。状態のプルーニング、ブロックとレシートの履歴、コンセンサスデータベース、blob の保持期間、オフチェーン索引は、それぞれ独立したクライアント・設定依存の範囲です。ライトクライアントは限定的なコミットメント経路を検証し、追加データを要求するもので、小型のフルノードではありません。
6. 必要最小限の RPC だけを公開します。管理 API と Engine API はローカルにバインドし、クライアントを認証し、ホストをファイアウォールで保護し、アプリケーション RPC をレート制限します。制御策なしに debug、trace、アカウント、トランザクションプールのメソッドを公開しません。対象ノードで `latest`、`safe`、`finalized` の各タグ、過去の呼び出し、ログ、トランザクション送信を試験し、独立して確認したエンドポイントだけをフェイルオーバー先にします。
7. 照合と復旧訓練を行います。別実装のクライアントまたは独立ノードとブロックハッシュ、ステートルート、ファイナライズ済みチェックポイントを比較します。正常終了、スナップショットと復元、データベース再構築、クライアント更新、フォーク有効化、ディスク交換、ピア喪失、RPC フェイルオーバーを訓練します。ログと設定を保存し、ノードが検証した出力をフロントエンド、オラクル、ブリッジ、アプリケーションの主張と区別します。

<a id="example"></a>

## 計算例

- **帯域幅モデル。** あるチェーンが `12 seconds` ごとにブロックを生成し、ダウンロードするブロック本体と必要な付随データの平均が `150 kB` だとします。ノードは 1 日に `86,400 / 12 = 7,200 blocks/day` を処理し、十進単位で `7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day` をダウンロードします。P2P のオーバーヘッド、再試行、コンセンサス通信、スナップショット、アップロードは含みません。これは容量計画上の仮定であり、Ethereum の現在値ではありません。
- **ディスクの余裕。** プルーニング済みノードの初期使用量を `1.20 TB`、実測したデータベース増加量を `18 GB/month` とします。`30 months` 後のモデル上の使用量は `1,200 + 18 * 30 = 1,740 GB` です。予測値より `25%` 多く確保すると、必要容量は `1,740 * 1.25 = 2,175 GB`、十進単位で `2.175 TB` です。クライアント変更、プルーニング、フォークにより線形モデルは外れる場合があります。
- **運用可用性。** `30 days = 720 hours` の間に、実行クライアント保守が `2 hours`、コンセンサスクライアント障害が `3 hours`、重複しない共通の停電が `1 hour` 発生したとします。停止は計 `6 hours`、観測可用性は `(720 - 6) / 720 = 99.1666666667%` です。プロセスが稼働していても、古い状態、ネットワーク分断、誤ったチェーン上にある可能性があり、稼働時間だけでは不十分です。
- **過去状態の再生成。** プルーニング済みクライアントにブロック `18,000,000` の利用可能なスナップショットがあり、ブロック `18,250,000` の状態が必要だとします。`250,000 blocks` の再実行が必要です。実測速度が `500 blocks/second` なら、理想的な計算時間は `250,000 / 500 = 500 seconds = 8.3333333333 minutes` です。状態読取り、レシート、リオーグ処理、キャッシュミスは含みません。アーカイブノードは、保存容量と引き換えに過去状態へ高速に直接アクセスできます。

<a id="risks"></a>

## リスク

- 誤ったチェーン、ジェネシス、フォーク予定、`chainId` に接続する。
- 悪意がある、古い、または十分に照合していない同期チェックポイントを信頼する。
- ネットワーク更新時に古いクライアントを使う。
- コンセンサス・実行クライアントが不一致になる、または Engine API 接続を失う。
- クライアント実装の不具合により、誤ったデータを受理、拒否、提供する。
- クライアントの単一化により、ノードとネットワークが相関障害にさらされる。
- ピアが少なすぎる、エクリプス攻撃を受ける、悪意あるピアや偏ったピアに接続する。
- 時刻のずれがコンセンサス業務、タイムスタンプ、ピア動作を損なう。
- ディスク容量不足、低速ストレージ、ファイルシステム障害、データベース破損。
- プロセス稼働時間を、同期・正規チェーン追跡・ファイナライズ済み動作と取り違える。
- リオーグ中にヘッド、safe、finalized の状態を混同する。
- プルーニング済みフルノードが全過去状態を即時照会できると考える。
- アーカイブノードが全オフチェーン索引、トレース、アプリケーションラベルを保存すると考える。
- 未認証の Engine、admin、debug、trace、トランザクションプール API を公開する。
- RPC ログからウォレットアドレス、照会、メタデータ、取引意図が漏れる。
- RPC 過負荷、無制限照会、DoS によりブロック検証の資源が奪われる。
- バックアップやスナップショット復元で、古いまたは内部不整合なデータが生じる。
- バリデーター鍵や署名鍵をノードサービスと不用意に同居させて失う。
- ローカル検証済みチェーンデータを、フロントエンド、オラクル、ブリッジの誠実性の証明とする。
- Ethereum の二クライアント構成、プルーニング、弱い主観性を別チェーンに当てはめる。

<a id="misconceptions"></a>

## よくある誤解

- すべてのフルノードは、全過去状態を永久保存するアーカイブノードである。
- フルノードを運用すれば、自動的にバリデーターやブロック提案者になる。
- 「同期済み」と表示されれば、意図した正規かつファイナライズ済みチェーン上に必ずいる。
- RPC を自前運用すれば、信頼、プライバシー、ソフトウェア、運用の全リスクがなくなる。
- ディスク、ピア、稼働時間が多いだけで、正しい検証とネットワーク安全性を証明できる。

<a id="related"></a>

## 関連トピック

- [ライトクライアント](/ja/crypto/light-client/)
- [RPC ノード](/ja/crypto/rpc-node/)
- [ステートルート](/ja/crypto/state-root/)

<a id="sources"></a>

## 出典

- [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org（参照日：2026-08-12）
- [Node architecture](https://ethereum.org/developers/docs/nodes-and-clients/node-architecture/) - Ethereum.org（参照日：2026-08-12）
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org（参照日：2026-08-12）
- [Ethereum Archive Node](https://ethereum.org/developers/docs/nodes-and-clients/archive-nodes/) - Ethereum.org（参照日：2026-08-12）
- [Client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org（参照日：2026-08-12）
- [Sync modes](https://geth.ethereum.org/docs/fundamentals/sync-modes) - go-ethereum（参照日：2026-08-12）
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org（参照日：2026-08-12）
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org（参照日：2026-08-12）

Source: https://wiki.fcontext.com/ja/crypto/full-node/index.mdx