ETH Clientの選択
Rocket PoolのSmartnodeインストーラーは、お使いのマシンを完全なEthereumノードに変換できます。適切に動作するためには、ExecutionクライアントとConsensusクライアントの両方が必要です。
ETH1/ETH2という用語は廃止されました。 これ以降のガイドでは、チェーンを**Execution Layer (ETH1)とBeacon ChainまたはConsensus Layer (ETH2)**と呼びます。
別のマシンでExecutionクライアントとConsensusクライアントを既に稼働させている場合(例えば、既にソロステーキングを行っている場合)、このセクションをスキップして外部クライアントを使用したハイブリッドRocket Poolノードの設定セクションに進んでください。
それ以外の場合は、ExecutionクライアントとConsensusクライアントの選択肢について詳しく学ぶために読み進めてください。
2025年8月現在、Beacon Chain上のクライアント分布は概ね以下のようになっています:

データ取得元: https://clientdiversity.org
バリデーターがどのConsensusクライアントを実行しているかのデータを取得することは、クライアントが簡単に識別できないため、比較的困難な問題です。https://clientdiversity.orgのデータ手法ページには、異なるソースからデータを取得する方法が説明されています。追加のデータソースとしてhttps://ethernodes.org/もご覧ください。
現在、ノードオペレーターの圧倒的多数がExecution ClientとしてGethを、Consensus ClientとしてLighthouseまたはPrysmを使用しています。 Execution Layer(旧ETH1)とBeacon Chain(旧ETH2)の健全性をサポートする観点から、現在は異なるクライアントの使用を検討することをお勧めします。 均等なクライアントダイバーシティがネットワークの健全性にとって重要である理由について、詳しく学びたい場合は、以下の関連記事をご覧ください:
https://clientdiversity.org/#why
https://blog.ethereum.org/2020/08/21/validated-why-client-diversity-matters/
https://our.status.im/the-importance-of-client-diversity/
https://medium.com/prysmatic-labs/eth2-mainnet-incident-retrospective-f0338814340c
https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html
https://eth2book.info/bellatrix/part2/incentives/diversity迅速にセットアップして稼働させたいユーザーのために、SmartnodeインストーラーはRandom Clientオプションを提供しており、これが最適な選択である可能性があります。
使用したい特定のクライアントがあるユーザーのために、Rocket Poolのインストール中に簡単に選択できる機能を提供しています。
以下のオプションは、各クライアントについて説明しており、使用したいクライアントを指定したい場合に情報に基づいた判断ができるようになっています。
Execution Clients
Rocket Poolは4つの異なるExecution clientをサポートしています:Geth、Besu、Nethermind、およびRethです。
Execution clientを実行すると、マシン上にExecution layerブロックチェーンのコピーが保存されます。 他のECノードとピアツーピア通信で相互作用し、新しいブロックとトランザクションを記録および検証します。 ExecutionレイヤーとConsensusレイヤーが統合された現在、バリデーターを実行するには完全なExecution clientが必須です。
Geth
Geth(正式名称はGo Ethereum)は、Ethereumプロトコルの3つのオリジナル実装(C++とPythonと共に)の1つです。
Goで書かれており、完全にオープンソースでGNU LGPL v3の下でライセンスされています。
Gethは最も古く、世界中で最も広く使用されているExecution Clientです。 非常に安定していて信頼性があると評判です。
マルチスレッド対応で、CPUを最大限に活用できます。 RAM使用量は設定可能で、Mainnetで最小約4GBまで下げられます。 これにより、低電力システムと高電力システムの両方で使用可能です。
Gethは定期的にデータベースのオフライン剪定が必要です。データベースは時間とともに成長し、ディスク容量が少なくなったときに剪定しない限り、空きディスク容量をすべて消費します。 剪定が必要な頻度は、SSDのサイズによって異なります。
Gethの剪定の詳細については、Execution Clientの剪定ページをご覧ください。
Besu
Hyperledger Besuは、Apache 2.0ライセンスの下で開発された、Javaで書かれたオープンソースのEthereumクライアントです。 Besuの最も魅力的な機能は、状態ストレージにBonsai Triesを使用していることです。パフォーマンス特性の向上に加えて、Bonsai Triesは他のクライアントにはない2つの興味深い利点をBesuに与えます:
- Besuは全く剪定する必要がありません。この点で実質的にメンテナンスフリーです
- Besuはブロックチェーン内の任意の過去のブロックを参照できますが、これは各ブロックを巻き戻すことで行われるため、遠い昔のブロックに到達するには時間がかかる場合があります。
Besuは現在、少なくとも16 GBのRAMを推奨していますが、8 GBで正常に実行することも可能です。
Nethermind
Nethermindは.NET Coreで書かれています。 Execution clientの中で最速の同期速度を誇り、豊富な設定オプションを備えています。 ノードオペレーターを念頭に設計されており、役立つ多くの機能があります。
Gethと同様に、Nethermindも定期的なデータベースの剪定が必要です。 ただし、Gethとは異なり、Nethermindのデータベースはオンラインのまま剪定できます。 つまり、剪定するためにクライアントをオフにしてフォールバックに依存する必要はありません。 ただし、Nethermindのオンライン剪定プロセスはかなりリソースを消費するため、低電力ノードを実行しているユーザーは、プロセス中にパフォーマンスの低下が見られる可能性があります。
Nethermindは少なくとも16GBのRAMが必要ですが、多いほど望ましいです。
Nethermindは定期的にデータベースの剪定が必要です。データベースは時間とともに成長し、ディスク容量が少なくなったときに剪定しない限り、空きディスク容量をすべて消費します。 剪定が必要な頻度は、SSDのサイズによって異なります。
ただし、Gethとは異なり、Nethermindは剪定中もオンラインのままです。 これにより、剪定中のダウンタイムがないため、ノードにとって魅力的な選択肢となります。
Nethermindの剪定の詳細については、Execution Clientの剪定ページをご覧ください。
Reth
RethはRustで書かれたExecution layerクライアントで、Erigon staged-syncアーキテクチャを使用しています。 Rethは効率性、パフォーマンス、モジュール性を念頭に一から設計されています。Apache/MIT許可ライセンスの下でライセンスされており、小さく、よく抽象化され、よくテストされ、ベンチマークされたパッケージで構築されています。これにより、優れたオープンソース開発体験が提供され、Rethのコンポーネントを他のプロジェクトで使用できます。
エコシステム内で最も新しいクライアントとして、Rethは急速に進化し、採用が広がっています。RAMとCPUの要件は柔軟ですが、最も重要な要件はディスクです。優れたTLCディスクの使用をお勧めします。 Rethは完全ノードには少なくとも8 GBのRAM、アーカイブノードには16 GBのRAMが必要です。
クライアント比較表
Consensus Clients
Rocket Poolのインストーラーは、現在利用可能な5つのConsensus clientをサポートしています:Lighthouse、Lodestar、Nimbus、Prysm、およびTekuです。
これらはすべて完全クライアントであり、どのクライアントを選択してもConsensusネットワークの分散化に貢献します。
5つのクライアントすべてがリスクが低く、メンテナンスも少なく、検証による総報酬はほぼ同じです。 リソース要件と機能の点でわずかに異なりますが、どれを選んでも間違いはありません。
デフォルトでは、Rocket Poolインストーラーはランダムなconsensus clientを選択することを提案します。 これにより、ネットワーク全体の多様性に貢献できます。 これはセキュリティの観点から重要です。1つのクライアントがノードの大多数で使用され、深刻なバグや攻撃を受けた場合、それらのノードすべてが失敗し、Beacon Chain全体の安定性が脅かされる可能性があります。
Lighthouse
Lighthouseは、Sigma PrimeによってメンテナンスされているオープンソースのEthereum 2.0です。 Ethereum Foundation Researchチームによって定義されたEthereum 2.0仕様を実装しています。
Lighthouseは、プルーフオブステークコンセンサス、並列トランザクション実行、状態分離(シャーディング)など、ブロックチェーン研究の最前線にある技術を実装する最先端の分散システムプロジェクトです。
LighthouseはEthereum Foundationとの公式な関係はなく、Ethereumプロトコルとそれを取り巻くコミュニティの最善の利益に合致する限り、そのガイダンスに従い続けます。
LighthouseはRustで実装されており、セキュリティと効率性に重点を置いています。
Lodestar
Lodestarは、ChainSafe Systemsによってメンテナンスされている5番目のオープンソースEthereum consensusクライアントです。フラッグシップ製品は、Ethereum consensusのための本番対応のbeacon chainとvalidatorクライアントです。ソフトウェアとツールは、研究者と開発者の迅速なプロトタイピングとブラウザ使用のための頼りになるものとして独自に位置づけられています。世界中の何百万もの開発者がTypescriptに精通しており、Lodestarの高品質なコードベースはEthereumの世界への優れた入門となっています。
Lodestarは、Ethereumライトクライアントのライトクライアント研究、標準化、実装のリーダーでもあります。私たちは、ブロックチェーンから直接信頼のないデータをブラウザが利用することの重要性を実証するために、他のクライアント実装者、研究者、開発者と協力するよう努めています。
Lodestarのニッチは、実装言語であるTypescriptにあります。
Nimbus
Nimbusは、使用するリソースの点でできるだけ軽量であることを目指すEthereum 2.0とEthereum 1.0の両方のクライアント実装です。 これにより、組み込みシステムやリソース制限デバイスでも優れたパフォーマンスを発揮できます。
ただし、リソース制限ハードウェアだけがNimbusが得意とする分野ではありません。 リソース消費が低いため、サーバー上で他のワークロードと一緒にNimbusを実行することが容易になります(これは、サーバーインスタンスのコストを下げようとするステーカーにとって特に価値があります)。
NimbusはNimで書かれ、Status.imチームによってメンテナンスされています。
Prysm
Prysmプロジェクトは、完全にGo プログラミング言語で書かれたEthereum 2.0ネットワークの完全な機能の実装です。
Prysmatic Labsによって作成されたPrysmは、Ethereum Foundationを含むEthereumエコシステム全体のさまざまなチームによる継続的な集団研究開発の成果である公式Ethereum 2.0仕様を実装しています。
Teku
Teku(以前はArtemisとして知られていました)は、機関のニーズとセキュリティ要件を満たすように設計および構築されたJavaベースのEthereum consensusクライアントです。 PegaSysは、コアEthereumプラットフォームと対話するためのエンタープライズ対応クライアントとツールの構築に専念するConsenSysの部門です。
TekuはApache 2.0ライセンスでJavaで書かれており、Javaはその成熟性と普及性で知られる言語です。