L2-15: Run Your Own Node（自分のノードを運用する） #

1. 問題 #

大多数のEthereum開発者（そして事実上すべての一般ユーザー）は、Ethereumとの対話にInfura、Alchemy、QuickNodeなどのサードパーティRPCプロバイダーに依存しています。これらのサービスは便利ですが、中央集権的な依存関係をもたらします。あなたのDAppは、このプロバイダーがオンラインで、かつあなたのAPIキーをレート制限していない場合にのみ正常に動作します。より根本的には、あなたは「ブロックチェーンの状態を教えてくれるある会社を信頼する」立場に自分を置いています — あなたのMetaMaskウォレットが表示する残高は、実際にはInfuraがそう伝えているものなのです。

自分自身のEthereumフルノードを運用することは、自分自身の「ブロックチェーンの真実の源」を持つことを意味します — あなたのノードはすべてのブロック、すべてのトランザクション、すべての状態変更を独立して検証します。RPC呼び出しにAPIキーは不要で、レート制限を受けず、月間呼び出しクォータもありません。最小のレイテンシでオンチェーンデータを読み取ることができ（ローカルネットワーク対インターネット）、データプライバシーを自分で管理できます。

本チャレンジ（scripts/run-node.md 参照）では、Ethereumフルノードをゼロから構築する全プロセスを完了します — 実行クライアントとコンセンサスクライアントのインストール・設定、JWT認証、同期監視、Docker化デプロイを含みます。

2. 理由 #

セルフホストノードは「Web3ユーザー」から「Web3インフラストラクチャオペレーター」へのアイデンティティの転換を表します。自分のノードを運用すると、Ethereumの二層アーキテクチャを真に理解できます。実行層（Execution Layer、トランザクション処理とEVM実行を担当）とコンセンサス層（Consensus Layer、PoSコンセンサスとブロックファイナリティを担当）です。これら二層はEngine API（JWT認証ベース）を通じて通信します — これは教科書の抽象概念ではなく、あなたが手動で設定する --authrpc.jwtsecret パラメータです。

ノードの運用は、プロフェッショナルなブロックチェーンエンジニアになるための必要なステップでもあります。MEV検索、トランザクションシミュレーション、高頻度DeFi戦略、L2シーケンサー開発において、自分自身の高可用性ノードを持つことはインフラストラクチャの前提条件です。ノードはRPCアクセスを提供するだけでなく、完全なmempool（保留中のトランザクションプール）を維持し、トランザクショントレーシングAPIを提供し、複雑な eth_call シミュレーション（状態上書きを含む）を実行できます。

さらに重要なのは、セルフホストノードがネットワークの分散化への貢献であることです。新たに参加するすべてのフルノードがEthereumネットワークをより検閲耐性が高く、より多様にします。十分な人々が自分のノードを運用すれば、「単一のRPCプロバイダーがあなたの見るブロックチェーン状態を決定できる」リスクは存在しなくなります。

3. 解決策 #

コアアーキテクチャ：実行クライアント + コンセンサスクライアント #

Ethereumフルノード
├── 実行クライアント (EL)     ← Geth / Nethermind / Besu / Erigon
│   ├── ワールド状態を維持（アカウント残高、コントラクトストレージ）
│   ├── EVMトランザクションを実行
│   ├── トランザクションプール（mempool）を管理
│   ├── JSON-RPC APIを提供（eth_call, eth_sendRawTransaction...）
│   └── Engine API（ポート8551）を通じてCLと通信
│
└── コンセンサスクライアント (CL) ← Lighthouse / Prysm / Teku / Nimbus
    ├── PoSチェーン（Beacon Chain）を追跡
    ├── ブロック検証とファイナリティに参加
    ├── Engine APIを通じてELに新ブロックを通知
    └── Beacon API（ポート5052）を提供

推奨構成：Geth + Lighthouse #

ステップ1：実行クライアントGethのインストール #

# Ubuntu/Debian
sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install -y ethereum

# macOS
brew install ethereum

# またはソースからコンパイル
git clone https://github.com/ethereum/go-ethereum.git
cd go-ethereum
make geth
sudo cp build/bin/geth /usr/local/bin/

ステップ2：コンセンサスクライアントLighthouseのインストール #

curl -LO https://github.com/sigp/lighthouse/releases/latest/download/lighthouse-linux-x86_64
chmod +x lighthouse-linux-x86_64
sudo mv lighthouse-linux-x86_64 /usr/local/bin/lighthouse

ステップ3：JWT Secretの設定（ELとCL間の認証） #

sudo mkdir -p /var/lib/ethereum
openssl rand -hex 32 | sudo tee /var/lib/ethereum/jwt.hex > /dev/null
# このjwt.hexファイルはELとCLの両方から読み取り可能でなければならない
# ELはこれを使ってCLのEngine API呼び出しを検証する
# CLはこれを使ってELへのEngine APIリクエストに署名する

ステップ4：実行クライアントの起動 #

geth \
  --mainnet \                          # メインネット（テストネットは --sepolia）
  --datadir /data/ethereum \           # ブロックチェーンデータ保存パス
  --http \                             # HTTP JSON-RPCを有効化
  --http.api eth,net,engine,admin \    # 公開API名前空間
  --http.addr 0.0.0.0 \               # 全インターフェースでリッスン（外部アクセス許可）
  --authrpc.jwtsecret /var/lib/ethereum/jwt.hex \  # JWTシークレットパス
  --syncmode snap \                    # スナップ同期（推奨）
  --cache 4096                         # メモリキャッシュ（MB）

主要パラメータ説明：

• --syncmode snap：スナップ同期 — 全トランザクションを最初から再生するのではなく、最新の状態スナップショットをダウンロード。同期時間は約12〜24時間
• --http.api eth,net,engine,admin：engine はCL通信に必須、eth は標準RPC、net と admin は運用API
• --cache 4096：状態ツリーに4GBのメモリキャッシュを割り当て。キャッシュが大きいほど同期が速い

ステップ5：コンセンサスクライアントの起動 #

lighthouse bn \
  --network mainnet \                           # メインネット
  --datadir /data/lighthouse \                  # Beaconチェーンデータ
  --http \                                      # Beacon APIを有効化
  --execution-endpoint http://localhost:8551 \  # EL Engine APIアドレス
  --execution-jwt /var/lib/ethereum/jwt.hex \  # JWTシークレットパス
  --checkpoint-sync-url https://sync-mainnet.beaconcha.in  # チェックポイント同期で高速化

--checkpoint-sync-url は重要な高速化パラメータです。信頼できるチェックポイントからBeaconチェーンの同期を開始し（ジェネシスブロックからではなく）、CL同期時間を数日から2〜3時間に短縮します。チェックポイントはコミュニティが信頼するノード（beaconcha.inはbeaconcha.inエクスプローラーのインフラストラクチャです）によって提供されます。

ステップ6：同期状態の検証 #

# EL同期進捗の確認
geth attach --exec "eth.syncing"
# falseを返す → 同期完了
# { currentBlock: ..., highestBlock: ... } を返す → 同期中

# CL同期状態の確認
curl http://localhost:5052/eth/v1/node/syncing
# {"data":{"head_slot":"...","sync_distance":"..."}}

ハードウェア要件 #

NVMe SSDは極めて重要です — SATA SSDのランダムIOPSは不十分で、同期速度が極端に遅くなります。ストレージは週に約2.5 GBずつ増加し（Ethereum状態の成長）、4 TBで約2〜3年の余裕を提供します。

Docker Compose クイックデプロイ #

version: '3.8'
services:
  geth:
    image: ethereum/client-go:latest
    volumes:
      - /data/geth:/root/.ethereum
      - /var/lib/ethereum/jwt.hex:/jwt.hex
    command: >
      --mainnet --http --http.addr 0.0.0.0
      --http.vhosts="*" --http.api eth,net,web3
      --authrpc.jwtsecret /jwt.hex
      --syncmode snap --cache 4096
    ports:
      - "8545:8545"     # HTTP RPC
      - "30303:30303"   # P2P TCP
      - "30303:30303/udp"  # P2P UDP

  lighthouse:
    image: sigp/lighthouse:latest
    volumes:
      - /data/lighthouse:/root/.lighthouse
      - /var/lib/ethereum/jwt.hex:/jwt.hex
    command: >
      lighthouse bn --network mainnet
      --execution-endpoint http://geth:8551
      --execution-jwt /jwt.hex
      --checkpoint-sync-url https://sync-mainnet.beaconcha.in
    ports:
      - "5052:5052"

docker compose up -d      # 起動
docker compose logs -f    # ログ確認

4. 遭遇した落とし穴 #

• 同期時間が予想を大きく超過：スナップ同期のドキュメントでは12時間とあるが、実際には2〜3日かかることがある — ハードウェアIOPSとピアノードの品質に依存
• ストレージ容量不足：メインネット状態は週に約2.5 GBずつ増加 — 2 TBディスクは12〜18ヶ月後に不足する可能性がある；ディスク満杯時、Gethはグレースフルデグラデーションではなくクラッシュする
• JWT設定ミス：ELとCLの --authrpc.jwtsecret が異なるファイルを指している、またはファイル権限が読み取り不可 — 両者が通信できずノードが停止
• ファイアウォール/P2P到達性：ポート30303（TCP/UDP）が開放されていない → ピアは発信接続のみで着信接続なし — 発見が遅く同期も遅い
• スナップ同期のセキュリティ前提：スナップ同期は同期ポイント以前の履歴状態を検証しない — スナップショットポイントが正しいことを信頼する
• RPC公開リスク：--http.addr 0.0.0.0 がRPCを公衆インターネットに公開 — ファイアウォール保護がない場合、誰でもあなたのノードを使用できる（DoSの可能性）

5. 落とし穴の原因 #

ストレージの線形成長は、Ethereumの「アカウントモデル」の特性によって決まります。UTXOモデル（ビットコインの未使用アウトプットは枝刈り可能）とは異なり、Ethereumはすべてのアカウント状態（残高、nonce、コントラクトストレージ）を継続的に維持する必要があります。何年も使用されていないアカウントでも、そのストレージスロットはディスク容量を占有し続けます。ディスクが100%満杯になると、GethのLevelDBデータベースがI/Oエラーを報告し、ノードプロセスが終了します — 手動でクリーンアップまたは容量拡張する必要があります。

JWT設定ミスの最も一般的な原因はパスの不一致です — ELの起動スクリプトは /var/lib/ethereum/jwt.hex を使用し、CLの起動スクリプトは /etc/ethereum/jwt.hex を使用し、両者が異なるファイルを指しています（一方は存在し、もう一方は空か内容が異なる可能性あり）。もう一つの一般的な問題はDockerボリュームマウントです — コンテナ内部パス /jwt.hex とホストパスを正しくマッピングする必要があります。

P2P到達性が同期速度に影響する理由：Ethereumのディスカバリー・プロトコル（discv5）は双方向です — あなたのノードは他のノードを見つけるだけでなく、他のノードもあなたのノードを見つけられる必要があります。デフォルトでは、起動後あなたのノードはブートストラップノードにクエリを送り、初期ピアリストを取得します。ポート30303が到達不能（NAT/ファイアウォール）の場合、他のノードはあなたに能動的に接続できず、発見したピアへの発信接続のみに依存せざるを得ません — これによりピアプールの多様性が大幅に減少します。

スナップ同期はセキュリティと速度のトレードオフです。完全同期（--syncmode full）はジェネシスブロックからすべてのトランザクションを再生します — これには数週間と数TBの容量が必要ですが、全履歴を検証します。スナップ同期は最近の「セーフポイント」から開始します — この「セーフポイント」はGethチームによってコード内にハードコードされており、Gethチームが悪意を持って誤った状態スナップショットを挿入していないことを信頼することになります。

6. 落とし穴の解決方法 #

自動ディスク監視を設定し、ディスク満杯前に警告を受け取る：

# crontab: 毎日ディスク使用量をチェック
0 9 * * * df -h /data/ethereum | mail -s "Disk Report" admin@example.com

またはPrometheus + Grafana監視システムを使用（Gethはポート6060でPrometheusメトリクスをエクスポート）。

--checkpoint-sync-url を使用してCL同期を高速化、ただし複数のソースからチェックポイントの信頼性をクロス検証する。beaconcha.inとethstaker.ccの両方がパブリックなチェックポイント同期エンドポイントを提供しています。

JWT一貫性の確保：環境変数または設定ファイルを使用してJWTパスを統一的に管理：

export JWT_PATH=/var/lib/ethereum/jwt.hex
geth --authrpc.jwtsecret $JWT_PATH ...
lighthouse bn --execution-jwt $JWT_PATH ...

NATトラバーサルを設定してP2P到達性を解決：

geth --nat extip:<your-public-ip>  # 手動でパブリックIPを指定
# またはルーターでUPnPを有効化

RPCセキュリティ強化：本番環境では personal と admin 名前空間を公開しない；リバースプロキシ（Nginx）を使用して認証層を追加：

geth --http.api eth,net --ws.api eth,net
# 必要なAPI名前空間のみ公開
# personal: アカウント管理（絶対に公開しない）
# admin: ノード管理（ローカルアクセスのみ）
# txpool: トランザクションプール内容（機密性あり）

バックアップと復旧計画の確立：定期的に datadir/chaindata をバックアップ（geth export でスナップショットをエクスポート）し、ディスク障害やデータ破損からの復旧に備える。

7. 技術的要点 #