クライアントの多様性

イーサリアムノードの動作は、ノードが実行するクライアントソフトウェアによって制御されています。プロダクションレベルのイーサリアムクライアントは複数存在しており、それぞれ別のチームにより、異なるプログラミング言語で開発され、保守されています。これらのクライアントは共通の仕様に基づいて構築されており、クライアント間のシームレスな連携、共通する機能、同等のユーザーエクスペリエンスを提供しています。しかしながら、現時点ではクライアントの占有率は偏ってしまっており、ネットワークの安全性が最大限にまで高められていません。クライアントの多様性を可能な限り高めるには、クライアント別の利用者数は同程度になることが望ましいです。

前提条件

ノードやクライアントについてまだ理解していない場合は、ノードとクライアントをご覧ください。レイヤーとレイヤーは、用語集で定義されています。

クライアントが複数ある理由

独立して開発・保守されるクライアントが複数存在するのは、クライアントの多様性が攻撃やバグに対するネットワークの耐性を高めるからです。複数のクライアントがあることはイーサリアム固有の強みです。他のブロックチェーンでは、単一のクライアントに依存しており、そのクライアントに絶対に誤りがないという前提に基づいています。しかし、ただ複数のクライアントがあるだけでは不十分です。クライアントはコミュニティで採用され、すべてのアクティブノードが比較的均等に複数のクライアントに分散している必要があります。

クライアント実装の多様性が重要な理由

独立して開発・保守される多くのクライアントがあることは、分散型ネットワークの健全性には不可欠です。この理由を探ってみましょう。

バグ

個々のクライアントにあるバグは、そのクライアントがイーサリアムノードのマイノリティである場合は、ネットワークへのリスクは低くなります。多数のクライアントにノードがほぼ均等に分散しているならば、大半のクライアントで共通の問題がある可能性は小さいため、結果的としてネットワークはより堅牢になります。

攻撃耐性

クライアントの多様性は、攻撃に対する耐性も同時にもたらします。例えば、特定のクライアントを騙してopens in a new tab特定のチェーンブランチに誘導する攻撃は、他のクライアントが同様の方法で悪用される可能性が低く、正規のチェーンは破損しないままであるため、成功する可能性は低いです。クライアントの多様性が低いほど、多数派のクライアントへの攻撃に関するリスクが高まります。クライアントの多様性がネットワーク上の悪意のある攻撃に対する重要な防御となることは、すでに証明されています。例えば、2016年の上海でのサービス拒否攻撃は、攻撃者が支配的なクライアント(Geth)を騙して、ブロックごとに何万回も遅いディスクi/o操作を実行させることができたために可能でした。この脆弱性を持たない他のクライアントもオンラインであったため、イーサリアムはGethの脆弱性が修正されている間も攻撃に耐え、稼働を続けることができました。

プルーフ・オブ・ステークのファイナリティ

イーサリアムノードの33%以上を占めるコンセンサスクライアントのバグがあると、コンセンサスレイヤーのファイナライズを妨げる可能性があります。つまり、トランザクションの取り消しや改ざんが発生するおそれがあります。これはイーサリアム上に構築された多くのアプリ、特に分散型金融(DeFi)にとって非常に大きな問題となります。

さらに悪いことに、3分の2の多数を占めるクライアントの重大なバグにより、チェーンが誤って分割されファイナライズされることで、多数のバリデータが無効なチェーン上で立ち往生する可能性があります。これらのバリデータが正しいチェーンに再び参加しようとする場合、スラッシングのペナルティを受けるか、時間がかかり高額となる任意退出後に、再度アクティベーションを行います。スラッシングの規模は過失のあるノードの数に比例し、3分の2のマジョリティが最大のスラッシング(32 ETH)を受けます。

これらは可能性が低いシナリオですが、アクティブなノードにクライアントを均等に分散することで、イーサリアムのエコシステムはリスクを軽減することが出来ます。特定のコンセンサスクライアントが、全ノードの33%のシェアを占めないことが理想です。

共同責任

マジョリティクライアントを維持するためには人件費もかかります。小規模な開発チームは過剰な負担と責任を負わなければなりません。クライアントの多様性が低いほど、マジョリティクライアントを保守するデベロッパーの責任が大きくなります。この責任を複数のチームに分散させることは、イーサリアムのノードネットワークの健全性と、人々の繋がりの両方にとって望ましいことです。

現在のクライアントの多様性

実行クライアント

コンセンサスクライアント

この図は古い可能性があります。最新情報については、ethernodes.orgopens in a new tabおよびclientdiversity.orgopens in a new tabをご覧ください。

上記の2つの円グラフは、実行レイヤーとコンセンサスレイヤーの現在のクライアントの多様性のスナップショットを示しています(2025年10月執筆時点)。クライアントの多様性は年々改善されており、実行レイヤーではGethopens in a new tabによる支配が減少し、Nethermindopens in a new tabが僅差で2位、Besuopens in a new tabが3位、Erigonopens in a new tabが4位となり、その他のクライアントがネットワークの3%未満を占めています。コンセンサスレイヤーで最も一般的に使用されているクライアントであるLighthouseopens in a new tabは、2番目に多く使用されているクライアントとかなり僅差です。 Prysmopens in a new tabとTekuopens in a new tabがそれぞれ約31%と約14%を占め、その他のクライアントはほとんど使用されていません。

実行レイヤーのデータは、2025年10月26日にsupermajority.infoopens in a new tabから取得したものです。コンセンサスクライアントのデータはMichael Sproulopens in a new tabから取得しました。コンセンサスレイヤーのクライアントは、コンセンサスクライアントを識別するための明確な痕跡を常に持っているわけではないため、コンセンサスクライアントのデータを取得することが難しい場合があります。このデータは、マイノリティクライアントの一部を時々混同する分類アルゴリズムを使用して生成されました(詳細はこちらopens in a new tabを参照)。上の図では、これらの曖昧な分類は、どちらか一方のラベル(例: Nimbus/Teku)で記載されています。いずれにせよ、ネットワークのマジョリティがPrysmを実行していることは明白です。これはスナップショットに過ぎませんが、図中の値は、クライアントの多様性の現状をよく表すものです。

コンセンサスレイヤーに関する最新のクライアント多様性データは、clientdiversity.orgopens in a new tabで入手できます。

実行レイヤー

これまでクライアントの多様性に関する議論は、主にコンセンサスレイヤーに焦点が当てられていました。しかし、実行クライアントのGethopens in a new tabは現在、全ノードの約85%を占めています。この高い占有率は、コンセンサスクライアントと同じ理由で問題になります。例えば、トランザクション処理や実行ペイロードの構築に影響を与えるバグがGethにあると、コンセンサスクライアントが問題や不具合のあるトランザクションをファイナライズする可能性があります。そのため、使われる実行クライアントがより均一に分散されると、イーサリアムの健全性が高まります。ネットワークの33%以上を占めるクライアントが存在しないことが理想です。

マイノリティクライアントを使用する

クライアントの多様性に対応するには、個々のユーザーがマイノリティクライアントを選ぶだけでなく、バリデータプールや、メジャーな分散型アプリ(Dapp)や取引所などの機関がクライアントを切り替えることも必要です。しかし、すべてのユーザーは現在の不均衡を是正し、利用可能なすべてのイーサリアムソフトウェアの使用の正常化に向けて貢献することができます。マージ後はすべてのノードオペレーターは、実行クライアントとコンセンサスクライアントの両方を実行する必要があります。以下に示すクライアントの組み合わせを選ぶことは、クライアントの多様性の向上につながります。

実行クライアント

コンセンサスクライアント

ノードオペレーターを大多数を占めるクライアントからの移行を奨励し、移行プロセスを加速できるよう、技術系のユーザーはマイノリティクライアント向けのチュートリアルやドキュメントの作成にご協力ください。マイノリティのコンセンサスクライアントに切り替えるためのガイドは、clientdiversity.orgopens in a new tabで入手できます。