ゲスの中央集権化がステーキング資産の喪失を招くと憂慮するのはなぜか？

明らかに、Geth クライアントを使ったステーキングが資産の損失につながると主張するこの記事は、過度に警戒しています。

著者は、Nethermind クライアントの失敗でノードが叩かれたケースを使い、Geth クライアントの 84% が失敗した場合に起こりうる悪い状況を想定しています。これは極端な仮定であり、Gethクライアントの中心性の問題を過剰に解釈しているとだけ言っておきましょう。

1)イーサのノードクライアントには、Geth、Nethrmind、Besu、Erigon、Rethなどのクライアントがあります。これらの実行クライアントは、開発者がブロック外の権利を実行するためのエンドポイント構成の選択肢に過ぎず、チェーンのコンセンサス、特にブロック外の権利とは直接関係ありません。

唯一の違いは、親しみやすさやコスト面からNethermindのような小さなクライアントを選ぶ開発者もいれば、流れに乗ってGethを選ぶ開発者もいるということです。 開発者がどのタイプのクライアントを使おうとも、POSでのブロックの確率は誓約されたETHに関係するだけです。Gethクライアントはカバレッジ率が高いため、直感的にはブロック権のほとんどがGethにあるように感じますが、実際にはほとんどのノードがGethを使用しており、その上側に誓約されたETHの量が多いため、論理的な相関関係が生じているだけです。

2)Gethクライアントが主流クライアントの84%を占める理由については、その優れたパフォーマンス、互換性、そして最も人気のあるクライアントであるという事実が挙げられます。これは、Geth自身の優れた性能、互換性、豊富な機能、成熟度、安定性の結果である。ポジティブなサイクル：Gethのパフォーマンスが良い - 開発者が積極的 - バグがすぐに修正される - 安定していて使いやすい - 開発者がより積極的 - Gethがより安定していて使いやすい - 開発者がより積極的 - Gethがより安定していて使いやすい。-開発者が活発であればあるほど、Gethのシェアは大きくなる。EtherFoundationも継続的なGrantを通じて他のクライアントの比重を高めていますが、結果は参考にならず、Gethクライアントのコンセンサスはますます強くなっています。

記事の著者の論理に従うと、Gethクライアントの割合が大きいため、一度Geth Etherのブロック外に問題が発生すると不安定になり、ステーキングに大きな問題を引き起こします。その理由は、もしGethクライアントが優秀でなかったら、ブロックが不安定になり、ステーキングに莫大なスラッシュダメージを与えていただろう、というものですが、これは誤った命題です。というのも、Gethクライアントがうまく機能していなければ、シェアが最大になることはありませんし、シェアが大きいということは使い方がうまいということですから、仮にGethに問題がある確率はどれくらいなのでしょうか？

3)Restakingと同様にStakingにもAVS(Activity Validator Set)の概念があり、Stakingに関与するノードは自身のデータを使用できなければなりません。これにより、ステーキングに参加するノードは、通信接続の安定性、ソフトウェアの安定性とバグ修正率、効果的なブロックと検証プロセスなどを確保することができます。

つまり、StakingとRestakingに参加するノードはGethクライアントを優先する傾向があり、Staking AVSセットのノードはRestakingに参加し続けたいのであれば、さらにパフォーマンスを向上させるためにエンドロードレベルを上げる方法を見つけなければなりません。つまり、StakingとRestakingは、クライアントレベルでより巻き込まれた競争をもたらすだけで、Gethクライアントの割合はさらに増幅される可能性が高いということです。

つまり、中央集権的なGethクライアントの割合が大きいため、ステーキングとリステーキングは潜在的にリスクが高いという議論は、明らかに成り立たないということです。

Gethクライアントの中央集権性は確かに問題であり、特に分散化された世界では大きな割合を占めることは常に懸念されます。これはステーキングとリステーキングの爆発的な普及とは直接関係ありません。もし関係あるとすれば、ステーキングとリステーキングの普及がGethクライアントのさらなる中央集権化を悪化させる可能性があるとしか言えません。ただ、Gethクライアントの中央集権化のリスクについて文句を言うのは、ちょっと本末転倒です。

注：Gethクライアントの中央集権化とステーキングの潜在的なリスクを計量するイニシアチブは、実際にはLidoのような大規模なノード団体の手にあり、Lidoがクライアントノードの多様性を高め、幅広いクライアント開発者を後援するよう意識的に努力すれば、問題はそれに応じて改善されるでしょう。