意見 | Ethereum に関する 5 つの質問: クライアントの多様性の問題はどこから来るのでしょうか?どうすれば解決できるでしょうか?

最近の第 90 回コア開発者会議は、ほぼ完全に 1 つの質問についての議論に費やされました。この会議を直接聞くことを強くお勧めします。

このセッションで、Alexey はクライアント開発者の過負荷の問題を提起しました。この議論は重要な出発点だとは思いますが、私たちは解決策を急いで見つけようとしており、問題を完全に理解することが不可欠です。時間をかけて問題を分析することが重要です。問題の意味を分析する場合、「5 つのなぜ」法は最もシンプルで効果的な方法の 1 つです。

では、早速最初の質問を見てみましょう。

質問 1: Geth 開発チームにかかるプレッシャーが過負荷になるほど大きいのはなぜですか?

etherscan を使用すると、各クライアントのインストール容量の統計を次のように確認できます。

• ゲス: 75%

• パリティ＆オープンイーサリアム：20%

• ネザーマインド: 1%

残りの 4% は、市場シェアが 1% 未満のクライアントで構成されているため、無視されます。

重要なのは、コンピューティング能力の 51% 以上が Geth クライアントに集中していることです。今後のベルリン ハードフォークで、EIP (Ethereum Improvement Proposals) の 1 つを実装する際に Geth にバグがあるとします。このクライアントの他の実装にバグがない場合でも、ブロックがこのバグに遭遇すると、Ethereum ネットワークがフォークすることになります。論理的には、このブロックは無効であり、他のクライアントもこれを無効なブロックと見なします。しかし、マイニングノードの 51% 以上が Geth クライアントを実行しているため、ネットワーク全体が間違ったフォーク チェーンに誘導されることになります。

これには、Geth クライアントと開発チームがミスをしてはならないことが求められます。

したがって、最初の質問に対する答えは次のようになります。

Ethereum ネットワークにはクライアントの多様性が十分ではないためです。

クライアントの多様化によって、クライアント開発が突然簡単な仕事になるわけではないことに注意が必要です。しかし、クライアントの多様性自体は、まだ探求する価値のある領域であり、開発チームの負担を軽減しながらクライアント開発の効率を向上させる方法を見つけるのに役立ちます。問題が Geth チームだけで解決できる可能性は低いことは否定できません。

質問 2: Ethereum ネットワークにクライアントの多様性が欠けているのはなぜですか?

Ethereum メインネットが稼働したとき、複数のクライアントが存在しました。最も重要な 2 つは Geth と CPPEthereum です。その後、Parity が出現し、CPPEthereum は排除されました。

それ以来、Parity 以外のクライアントは大きな市場シェアを獲得していません。昨年、Nethermind は新星として登場しましたが、現在のところ市場シェアはわずか 1% です。最近、Parity が遭遇したいくつかの挫折と暗い将来により、Parity の市場シェアは大幅に低下しました。理想的には、イーサリアム ネットワークには 3 つ以上のクライアントが必要であり、各クライアントのシェアは高すぎてはならず、単一のクライアントが市場シェアの 51% を大幅に超えるシェアを占めるべきではないと私たちは考えています。理想的な状況ではクライアントの多様性が達成されるはずですが、私たちはクライアント主導の状況に慣れてしまっています。

では、なぜ複数のクライアントが必要なのでしょうか?

私の個人的な経験から言うと、Ethereum クライアントの構築は非常に困難です。 Geth が Ethereum ネットワーク上で安定して実行できる理由は、多くの複雑な最適化を導入しているためです。 Geth チームは、このような高いレベルの複雑さに到達するまでに数年を費やし、現在も最適化を続けています。

遅れているクライアントにサポートと援助を提供する方法を見つけるべきだとすぐに提案する人もいるかもしれません。私はこの「神話的な人月」アプローチには警戒しています。ソフトウェア開発において、より多くのエンジニアを困難な問題に投入してもうまくいくことはめったになく、成功するとは期待していません。

むしろ、複雑さに焦点を当てるべきだと思います。

注: 人月という神話は、人数が多くても時間が短くてもソフトウェア開発の進捗を短縮することはできないことを示しています。群集心理で作業することはソフトウェアの生産には役立たず、むしろトラブルを引き起こし、より劣ったソフトウェアを生み出すことになります。すでに遅れているプロジェクトにさらに人員を追加すると、さらに遅れることになります。

質問 3: Ethereum クライアントの構築がなぜ難しいのでしょうか?

今、私たちは問題の根本に近づいています。

結局のところ、困難の多くは、イーサリアム クライアント ソフトウェアが相互に接続し、ブロックチェーン上で情報を共有するために使用するツールのセットであるネットワーク プロトコルから生じています。 Ethereum のネットワーク ルール (devp2p コードベースで定義) は、最終的には Ethereum クライアントの設計と要件に影響を与え、決定さえもします。

一部のネットワーク ツールでは、最適化されていないアーキテクチャが指定されており、Ethereum クライアントに不要な機能を実行することを要求するものもあります。クライアント開発者はこれらの制約内で作業する必要があります。

質問 4: インターネット プロトコルによってクライアント実装の難易度が上がるのはなぜですか?

この質問に対する答えは、基本的に 2 つの部分に分けられると思います。

• 状態管理

• 全体的なネットワーク相互接続要件

状態管理に関しては、Ethereum クライアントはネットワーク上の完全な状態を同期し、その状態のローカル コピーを維持できる必要があります。これらは両方とも達成するのが困難です。状態を同期するには、クライアントと状態要求を読み取って処理するサーバーの両方に対して、何百万もの要求を行い、ディスク I/O を飽和させる必要があります。データベースが新しいブロックを十分速く実行できるように、新しく同期された状態を維持および整理する必要があります。エンジニアリングの観点から見ると、これは深刻な課題です。

GetNodeData は、状態を同期するために使用する唯一のネットワーク ツールであり、特定の状態データベース形式 (俗に「ネイティブ レイアウト」と呼ばれる) に最適化されています。 Turbo Geth によって普及した「フラット」データベース レイアウトは、状態維持においてパフォーマンス上の大きな利点がありますが、このレイアウトを使用すると GetNodeData 要求の処理が難しくなります。

ネットワーク テクノロジー、特に DevP2P ETH プロトコルに注目すると、クライアントの複雑さを増す他の要因があることがわかります。このネットワークに参加するには、クライアントに次の機能が必要です。

• 最新のブロックによって生成された状態にアクセスするための GetNodeData 要求を処理します。

• ブロック ヘッダー、ブロック本体、領収書などのオンチェーン データ履歴へのアクセス要求を処理します。

これらのリクエストを処理するために必要な基礎データは、多くのクライアント操作では基本的に必要ではありませんが、これらの機能をサポートするためには必須となっています。これには、すべてのクライアントが独自のニーズを満たすだけでなく、多数の機能を構築する必要があります。たとえば、主にトランザクションを送信するためのゲートウェイとして機能するクライアントは、オンチェーンの履歴データを必要とせず、状態のごく小さなサブセットのみを必要とする場合があります。ただし、現在のバージョンの Ethereum では、クライアントは完全なコピーを保持する必要があります。

質問5: なぜ...

4つの「なぜ」を尋ねるだけで、根本的な原因が見つかったようです。 Ethereum プロトコルはまだ完全に成熟していません。 Ethereum プロトコルを設計していた当時は、今日発見されている問題のほとんどを認識していませんでした。あるいは、状態のサイズが小さく、開発の歴史が短かったため、これらの問題はまだ問題になっていませんでした。

解決

私は過去1年間この問題に焦点を当ててきました。 Ethereum の問題の多くはネットワーク層にまで遡ることができると私は思います。

おそらく最も明白な例は、ディスク I/O が歴史的にクライアント側のボトルネックとなってきたことです。このボトルネックが発生するのは、クライアントが状態データベースを実装するためにツリー構造 (トライ) の単純な表現を使用する傾向があるためです。状態データベースの構築方法は、GetNodeData ネットワーク要素によって決まります。

これを修正するには、Ethereum コンセンサス層とネットワーク層のさまざまな部分を全面的に見直す必要があります。現在、メンテナンス作業が開始されております。アレクセイと私が8か月間共同で主導してきた「Stateless Ethereum」という名前で、多くの作業が進行してきました。私たちが行った作業の一部は、Geth チームが何年もかけて開発してきた独自の SNAP 同期プロトコルを使用していたため、少なくとも Geth チームの負担を軽減しました。仕事のもう一つの部分では、問題を深く理解し、実行可能な解決策を考え出すことができる有能な人材が必要です。

現在、このような巨大な DevP2P ETH プロトコルは完全には解体されていません。このネットワークを 3 つの個別の専用ネットワークに分割する方法については基本的な理解がありますが、まだ誰もこれに直接取り組んでいません。

あるいは、これらの問題を完全に回避するメカニズムを提供する再生のようなアイデアもあります。これは革新的なアプローチであり、成功すれば私たちに大きな利点をもたらす可能性があります。

まず第一に、イーサリアム ネットワークにはまだ達成すべき困難なタスクが数多く残っており、これらのタスクを実行できるのはほんの一握りの人だけであることを明確にしておく必要があります。毎日ますます多くの開発者が参加していますが、必要なスキルを習得するには時間と労力を投資する必要があります。クライアント開発者は、日常のユーザーには見えない低レベルの問題の解決に注力する一方で、新しい EVM 機能を開発するための時間も確保する必要があります。

イーサリアム ネットワークを長期的に成功させたいのであれば、コミュニティ全体が協力してこれらの問題に対処し、その根本的な原因に十分な注意と議論を払うことが重要だと思います。最も重要なことは、私たちが協力して効果的な技術的ソリューションを作成することです。

（以上）

オリジナルリンク: https://snakecharmers.ethereum.org/applying-the-five-whys-to-the-client-diversity-problem/著者: Piper Merriam翻訳・校正: Min Min & A Jian

この記事へのリンク: https://www.8btc.com/article/623686
転載の際は出典を明記してください