イーサリアムに関する 5 つの質問: クライアントの多様性の問題はどこから来るのでしょうか?
編集者注: この記事は以下から引用しましたイーサリアム愛好家 (ID: ethfans)編集者注: この記事は以下から引用しました
イーサリアム愛好家 (ID: ethfans)
イーサリアム愛好家 (ID: ethfans)
最近の第 90 回コア開発会議では、ほぼずっと 1 つの問題に集中していました。ぜひ皆さんもこのセッションを自分の目で聞いてみることを強くお勧めします。
このセッションで、Alexey はクライアント開発者の過負荷の問題を提起しました。この議論は重要な出発点であると思いますが、私たちは問題を完全に理解するために解決策を見つけることに熱心すぎます。少し時間をとって問題を分析することが重要です。質問の意味を分析する場合、「5 つのなぜ」は最もシンプルで効果的な方法の 1 つです。
早速、最初の質問が何であるかを見てみましょう。
Geth: 75%
Parity & OpenEthereum: 20%
Nethermind: 1%
副題
最初の質問: なぜ Geth 開発チームに対するプレッシャーはこれほど大きく、過負荷にまで達しているのでしょうか?
etherscan を通じて、次のように各クライアントのインストール容量の統計を確認できます。
残りの 4% は、市場シェアが 1% 未満の一部のクライアントで構成されているため、無視されます。
重要なのは、コンピューティング能力の 51% 以上が Geth クライアントに集中していることです。今後のベルリンのハードフォークで、ゲスが EIP (イーサリアム改善提案) の 1 つの実装にバグを抱えていると仮定します。このクライアントの他の実装にバグがない場合でも、ブロックがこのバグに遭遇すると、イーサリアム ネットワークがフォークされてしまいます。論理的には、このブロックは無効であり、他のクライアントはそれを無効なブロックとして扱います。ただし、マイニング ノードの 51% 以上が Geth クライアントを実行しているため、ネットワーク全体が間違ったフォーク チェーンに誘導されてしまいます。
したがって、最初の質問に対する答えは次のようになります。
イーサリアムネットワークのクライアントには十分な多様性が欠けているためです。
クライアントの多様化によって、クライアントの開発が突然簡単になるわけではないことは言及しておく価値があります。しかし、クライアントの多様性自体はまだ検討する価値のある領域であり、開発チームの負担を軽減しながらクライアント開発の効率を向上させる方法を見つけるのに役立ちます。 Geth チームだけでこの問題を解決できる可能性が低いことは否定できません。
副題
2 番目の質問: なぜイーサリアム ネットワークにはクライアントの多様性が欠けているのでしょうか?
イーサリアムメインネットが稼働したとき、私たちは複数のクライアントを抱えていました。主要なものの 2 つは Geth と CPPEthereum です。その後、Parity が登場し、CPPEthereum は排除されました。
それ以来、パリティ以外のクライアントは大きな市場シェアを獲得していません。昨年、Nethermind は新星として台頭しましたが、現在市場のシェアは 1% にすぎません。最近、パリティの市場シェアは、いくつかの浮き沈みとパリティの暗い将来により大幅に低下しました。私たちは、理想的には、イーサリアム ネットワークには 3 つ以上のクライアントが必要であり、各クライアントのクライアント シェアが高すぎてはならず、どのクライアントも市場シェアの 51% を大きく超えることができないと考えています。理想的には顧客の多様化が達成されるべきですが、私たちは顧客の覇権に慣れています。
では、なぜ複数のクライアントが必要なのでしょうか?
誰かがすぐに、遅れをとっているクライアントをサポートし支援する方法を考え出すように提案するかもしれません。私はこの「神話の人月」ソリューションには警戒しています。ソフトウェア開発においてより多くのエンジニアを困難な問題に投入しても、うまくいくことはめったにありませんし、私もうまくいくとは期待していません。
代わりに、複雑さに焦点を当てる必要があると思います。
注: The Mythical Man-Month (神話上の人月) は、多数の人員と短期間によってソフトウェア開発の進捗を短縮することはできないと指摘しています。混雑はソフトウェアの生産に役立たないどころか、トラブルを引き起こし、より質の悪いソフトウェアを生産します。スケジュールが遅れているプロジェクトに人員を追加しても、スケジュールはさらに遅れるだけです。
副題
今、私たちは問題の根本に近づきつつあります。
問題のほとんどは、イーサリアム クライアント ソフトウェアが相互に接続し、ブロックチェーンに関する情報を共有するために使用する一連のツールであるネットワーク プロトコルに起因していることが判明しました。イーサリアムのネットワーキング ルール (devp2p コードベースで定義) は、最終的にはイーサリアム クライアントの設計と要件に影響を与え、決定することさえあります。
一部のネットワーキング ツールは、最適化されていないアーキテクチャを指定しており、イーサリアム クライアントに不要な機能の実行を要求する場合もあります。クライアント開発者は、これらの制約内で作業する必要があります。
副題
質問 4: ネットワーク相互接続プロトコルによってクライアント実装の難易度が高くなるのはなぜですか?
この質問に対する答えは基本的に 2 つに分けられると思います。
状態管理
全体的なネットワーク相互接続要件
状態管理に関する限り、Ethereum クライアントはネットワーク上の完全な状態を同期し、その状態のローカル コピーを維持できなければなりません。どちらも実行するのは難しいです。状態を同期するには、状態リクエストを読み取って処理するクライアントとサーバーに何百万ものリクエストが必要であり、ディスク I/O が飽和状態になる可能性があります。データベースが新しいブロックを十分な速度で実行できるように、新しく同期された状態を維持し、プルーニングする必要があります。エンジニアリングの観点から見ると、これは重大な課題です。
GetNodeData は、状態を同期するために使用する唯一のネットワーク ツールであり、特定の状態データベース形式 (一般に「ネイティブ レイアウト」として知られています) に最適化されています。 Turbo Geth によって普及した「フラット」データベース レイアウトには、状態の維持という点でパフォーマンスに大きな利点がありますが、このレイアウトを使用すると GetNodeData リクエストの処理が難しくなります。
最新のブロックによって生成された状態にアクセスするための GetNodeData リクエストを処理します。
ブロックヘッダー、ブロック本体、レシートなどのオンチェーンデータの履歴にアクセスするリクエストを処理します。
質問5: なぜ...
解決
根本原因にたどり着くには、4 つの「なぜ」を尋ねるだけで済んだようです。イーサリアム プロトコルはまだ完全には成熟していません。イーサリアムプロトコルを設計するとき、私たちは現在見つかっている問題のほとんどを認識していませんでした。あるいは、国家が小さく開発の歴史が短かったため、当時は問題ではありませんでした。
副題
解決
私はこの1年間、この質問を追いかけてきました。イーサリアムに関する多くの問題の根源は、実際にはネットワーク層にまで遡ることができるということに私は気づきました。
おそらく最も明白な例は、歴史的にディスク I/O がクライアントのボトルネックになっていたことです。このボトルネックが存在するのは、クライアントがツリー構造 (トライ) の単純な表現を使用して状態データベースを実装する傾向があるためです。状態データベースの構築方法は、GetNodeData ネットワーク要素によって決定されます。
これを修正するには、ネットワーク層だけでなくイーサリアムコンセンサス層のさまざまな部分を徹底的に見直す必要があります。現在、メンテナンス作業を開始しております。 Alexey と私が 8 か月間共同で主導してきた「Stateless Ethereum」という名前の下で、多くの作業が行われてきました。私たちが行った作業の一部は、Geth チームが長年にわたって開発してきた SNAP 同期プロトコルを使用しているため、少なくともその負担を軽減します。問題を深く理解し、実現可能な解決策を考える才能ある人材が取り組む必要のある仕事がまだ残っています。
現時点では、このような巨大な DevP2P ETH プロトコルは完全には解体されていません。このネットワークを 3 つの個別のプライベート ネットワークに分割する方法については基本的に理解していますが、それを直接実行した人はまだいません。
