スクロールの共創:イーサリアムのエコロジカル開発における「鶏と卵」の問題

著者:Ye Zhang 出典:X、@yezhang1998翻訳:Shanoba、Golden Finance

イーサリアムにとって、ゆっくりとした成長は欠陥ではなく特性です。数兆ドルの資産を保護する決済層にとって、急速な発展は危険です。

クライアントの多様性は重要ですが、実際にはクライアントチームは少なくても十分です。また、新機能の開発においてクライアントチームの調整が主要なボトルネックではないと考えています。特に後方互換性を考慮する必要がある他の多くの要素があります。

ここで別の3つのポイントを提出したいと思います。

1. インフラストラクチャはLayer 2の変化により迅速に適応する必要があります。それ以外の場合、Ethereumエコシステム全体に魅力を失うリスクがあります。

人々は一般的に、Layer 2の解決策の開発がより速く進むことを期待しています。しかし、これは多くのインフラストラクチャの適応速度が遅いため、困難です。Scrollは完全なEVM互換性を持っていても、MetaMaskの問題に直面しています:

Scroll（または他のLayer 2）の取引手数料には、データ可用性（DA）手数料と実行手数料が含まれていますが、MetaMaskはデフォルトで実行手数料のみをサポートしており、数ヶ月間、手数料の計算が正しくありませんでした。

これは難しい先鶏問題を引き起こしています：

もしLayer 1が変わらなければ、インフラプロバイダーは更新する動機がありません。更新されていないインフラがあれば、Layer 2のソリューションはより速く発展することができず、それによってイノベーションが阻害されます。これはイーサリアムにとって特別な挑戦です。なぜならほとんどの他のチェーンには、チェーンのアップグレードに密接に関連したネイティブウォレットがあるからです。それに対して、EVM標準はイーサリアムに従っているため、適合が複雑になります。

2. 規格は非常に重要ですが、現在すべてのLayer 2ソリューションには規格が欠けています

クライアントの多様性を実現するには、より完全な規格が必要です。しかし、多くのチームが複数のクライアント実装を持っていると主張していますが、実際にはこの概念を根本的に誤解しています。

正しいやり方は、

1. 高度な規格を定義します。

2. どのチームも、他のクライアントの実装を参照することなく、仕様書を読むことで機能を実装できることを確認してください。

つまり、複数のクライアントに実装された唯一の真のソースは、規格そのものでなければならない。 しかし、現在、ほとんどの実装は既存の実装を参考にしており、これは複数のクライアントアーキテクチャの真の潜在能力に反しています。

3. イーサリアムとビットコインの違いに注意することも同様に重要です

ビットコインは、単一の実装に依存しており、その真の出所として、コアのコードベースが唯一の真理であるため、誤りがあってはなりません。

しかし、イーサリアムの真の出所は仕様そのものであり、特定の実装であるGethのようなものではありません。 テキストが空です この方法により、イーサリアムに対する規格がより実質的な意味を持つようになります。エラーが発生した場合、ある具体的な実装に依存するのではなく、社会的合意に基づいて規格を修正する必要があります。