ノードと RPC インフラ

article technology medium #blockchain-node#rpc#full-node#archive-node#light-node#alchemy#infura#quicknode#client-diversity#ethereum-client
Created: 2026-06-07 Updated:

ブロックチェーンのノード種別（フル・アーカイブ・ライト）と RPC プロバイダ（Alchemy・Infura・QuickNode）の全体像。実行/コンセンサスクライアント多様性、セルフホストとマネージドの選択基準を整理する。

ノードと RPC インフラ

ブロックチェーンネットワークを維持・利用するためのノードとインフラ層を解説する。フルノード・アーカイブノード・ライトノードの種別と役割、主要 RPC プロバイダのサービス比較、Ethereum における実行/コンセンサスクライアントの多様性の意義を扱う。P2P ネットワークトポロジ・peer discovery・gossip 伝播の詳細は tech-210 に委譲する。情報カットオフ ~2025-08、confidence: medium 固定（2026-06 時点での外部再検証は未実施）。

ノード種別と役割

ブロックチェーンネットワークには複数種類のノードが存在し、それぞれ保存データと機能が異なる。

**フルノード（Full Node）**はブロックチェーンの全ブロックをダウンロードし、すべてのトランザクションを独立して検証する。現在の「世界状態（World State）」は保持するが、中間状態は保持しないことが多い。Bitcoin フルノードは約 600 GB 超（2025 年）のチェーンデータが必要で、Ethereum は実行レイヤーのステートデータも含めると 1 TB 超となる。ネットワークの分散性とセキュリティの基盤であり、自分のトランザクションを第三者なしに検証したいユーザーに必須。

**アーカイブノード（Archive Node）**はフルノードの機能に加えて、全ブロック・全時点での全アカウントの状態履歴を保持する。Ethereum アーカイブノードは 15〜20 TB 超（2025 年）のストレージを要する。eth_getBalance（過去ブロック高での残高照会）・デバッグ API・オンチェーン分析ツール・DeFi プロトコルの一部機能がアーカイブノードを必要とする。一般ユーザーには不要だが、インフラプロバイダ・分析企業・大規模 DeFi プロトコルには不可欠。

**ライトノード（Light Node / Light Client）**はブロックヘッダーのみをダウンロードし、Merkle Proof を用いてトランザクションの包含を検証する（SPV: Simplified Payment Verification）。フルノードに比べてストレージ・帯域・計算資源を大幅に削減できる。スマートフォン・IoT デバイス・埋め込みシステムでの利用を想定。Ethereum では Altair アップグレード後に正式なライトクライアント仕様が整備された。欠点は「フルノードが提供する情報を信頼する」という依存関係があること（Fraud Proof での異議申立が必要）。

RPC（Remote Procedure Call）インターフェース

RPC（Remote Procedure Call）は dApp・ウォレット・開発ツールがブロックチェーンノードと通信するための標準 API インターフェースである。Ethereum では JSON-RPC over HTTP/WebSocket が標準で、eth_getBalance・eth_sendRawTransaction・eth_getLogs などのメソッドが定義されている。

セルフホストノードは検閲耐性・プライバシー・可用性制御の面で優れるが、構築・保守コストが高い。そのため多くの開発者・プロジェクトはマネージド RPC プロバイダを利用する。

主要 RPC プロバイダの比較

プロバイダ特徴対応チェーン無料枠
Alchemy高信頼性、Enhanced API（NFT/Token API）、2021 年ユニコーン化Ethereum・Polygon・Arbitrum・Optimism・Base 等 25+300M CU/月
Infura老舗（2016 年、ConsenSys 傘下）、MetaMask のバックエンド、IPFS ゲートウェイ統合Ethereum・Polygon・Arbitrum・Palm 等100K req/日
QuickNode低レイテンシ、グローバル 20+ PoP、マルチチェーン最多対応（60+ チェーン）Bitcoin・Ethereum・Solana・Avalanche・Aptos 等50M credits/月
Ankr分散型ノードネットワーク、パブリック RPC 無料提供Ethereum・BSC・Polygon 等制限付き無料
Chainstackプロジェクト管理 UI、Dedicated ノードと共有ノード選択25+ チェーン3M req/月

中央集権化の懸念として、MetaMask のデフォルト RPC は Infura を指し、Infura が 2020 年に Iran 等からのリクエストをブロックした事例は単一プロバイダ依存のリスクを示している。分散型代替として Pocket Network（POKT：トークンインセンティブ型 RPC ネットワーク）・Lava Network（マルチチェーン分散 RPC）が台頭している。

Ethereum クライアント多様性

Ethereum は実行レイヤー（EL）とコンセンサスレイヤー（CL）の二層構造（The Merge 以降）を持ち、各層に複数のクライアント実装が存在する。

実行クライアント（Execution Layer）:

クライアント言語特徴
GethGo最多使用（シェア ~60%）、参照実装
NethermindC#Windows 対応・Snap Sync 最速
BesuJavaエンタープライズ機能・Hyperledger 傘下
ErigonGoアーカイブノード最小フットプリント
RethRust高性能・新興実装

コンセンサスクライアント（Consensus Layer）:

クライアント言語特徴
LighthouseRustパフォーマンス重視
PrysmGo最多使用（シェア ~40%）、使いやすさ重視
TekuJavaEF 直系・エンタープライズ向け
NimbusNim軽量・リソース制限環境向け
LodestarTypeScriptブラウザ/軽量クライアント開発用

クライアント多様性はネットワークのレジリエンスに直結する。単一クライアントのバグが 33% 超のバリデータに影響するとファイナリティ障害が発生するため、Ethereum Foundation はクライアントシェアの分散化を強く推奨している。2023 年以降、Prysm の CL シェアが低下し Lighthouse・Nimbus が増加するなど改善が進んでいる。

セルフホスト vs マネージド RPC の選択基準

観点セルフホストマネージド RPC
検閲耐性高（自己判断）低-中（プロバイダポリシー依存）
プライバシー高（IP・クエリが露出しない）低（プロバイダにクエリ履歴が残る）
コストサーバ費+運用工数従量/定額課金
セットアップ難度高低（API キー 1 枚）
可用性自己責任SLA 99.9%+
スケーラビリティ手動スケールアップ自動スケール

ミッションクリティカルな dApp・DEX・ブリッジは RPC プロバイダ障害へのフォールバックとして複数プロバイダの冗長化（Round-robin / ヘルスチェック fallback）を採用するのが標準的実践となっている。

Backlinks

Local graph