クライアントの多様性

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

前提知識

ノードやクライアントが何かについてご存知ではない場合、ノードとクライアントを参照してください。とは用語集に定義が記載されています。

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

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

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

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

バグ

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

攻撃耐性

クライアントの多様性は、攻撃に対する耐性も同時にもたらします。例えば、特定のクライアントに対する攻撃(opens in a new tab)で不正なチェーンへと改ざんしようとする試みが成功する可能性は低くなります。これは、他のクライアントに同じような攻撃ができる可能性は低く、正規のチェーンは壊れないためです。クライアントの多様性が低いほど、多数派のクライアントへの攻撃に関するリスクが高まります。クライアントの多様性がネットワーク上の悪意のある攻撃に対する重要な防御となることは、既に証明されています。例えば、2016年の上海DOS攻撃の事例は、多数派のクライアント(Geth)に対して、ブロックごとに何万回も遅いディスクi/o操作を実行したため起こりました。この脆弱性を持たない他のクライアントもオンラインであったため、イーサリアムはGethの脆弱性が修正されている間も攻撃に耐え、稼働を続けることができました。

プルーフ・オブ・ステークにおけるファイナリティ

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

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

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

責任の共有

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

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

図のデータはethernodes.org(opens in a new tab)とclientdiversity.org(opens in a new tab)から引用

上の2つの円グラフは、実行レイヤーとコンセンサスレイヤーの現在(2022年1月の執筆時点)のクライアントの多様性のスナップショットを示しています。実行レイヤーの大多数はGeth(opens in a new tab)が占めており、1位と大差をつけてOpen Ethereum(opens in a new tab)が2位、次にErigon(opens in a new tab)、Nethermind(opens in a new tab)と続きますが、その他のクライアントはネットワークの1%未満に過ぎません。コンセンサスレイヤーで最も一般的に使用されているPrysm(opens in a new tab)は、Gethほど独占しているわけではありませんが、それでもネットワークの60%以上を占めています。 Lighthouse(opens in a new tab)とTeku(opens in a new tab)がそれぞれ約20%と約14%を占め、他のクライアントはほとんど使われていません。

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

コンセンサスレイヤーのクライアントの多様性についての最新のデータは、clientdiversity.org(opens in a new tab)から入手できます。

実行レイヤー

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

マイノリティクライアントの使用

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

実行クライアント

Besu(opens in a new tab)

Nethermind(opens in a new tab)

Erigon(opens in a new tab)

Go-Ethereum(opens in a new tab)

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

Nimbus(opens in a new tab)

Lighthouse(opens in a new tab)

Teku(opens in a new tab)

ロードスター(opens in a new tab)

プリズム(opens in a new tab)

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