パラダイムの最新研究記事: イーサリアムの加速

Frank ｜2025-01-26 5:32

私たちは、イーサリアムコアプロトコルをより迅速にアップグレードする必要があると考えています。イーサリアムには、その価値を犠牲にすることなく加速できる重要な改良点が数多くあります。

著者: Georgios Konstantopoulos、Dan Robinson、Matt Huang、Charlie Noyes、パラダイム

編集者: Frank、PANews

イーサリアムは創設以来、暗号通貨分野の先駆者として活躍してきました。イーサリアムは、スマートコントラクト、分散型自律組織 (DAO)、分散型金融 (DeFi) への道を切り開き、ゼロ知識証明 (ZK) や最大抽出可能価値 (MEV) などの最先端の課題で革新を続けています。イーサリアムの研究者とエンジニアのコミュニティは、次世代の分散型アプリケーションのための強固な基盤を構築しました。

歴史を振り返ると、イーサリアムプロトコルのオリジナルバージョンは 2 年足らずで正常に起動されたことを忘れないでください。このスピードにより、私たちの多くはイーサリアムを開発プラットフォームの選択肢として検討するようになりました。

現在、私たちはイーサリアムコアプロトコルをより迅速にアップグレードする必要があると考えています。イーサリアムには、その価値を犠牲にすることなく加速できる重要な改良点が数多くあります。

あなたのビジョンが何であれ、より高速に反復することはイーサリアムにとって良いことです

コミュニティ内では、イーサリアムの将来の中核となるビジョンがどうあるべきかについて、合理的な議論が行われています。しかし、イーサリアムがどこに行こうとも、より早くそこに着くことが常に良いことです。イーサリアムの配信および反復機能への投資は価値があります。

特定のテクノロジーの選択に直面したとき、人々はすぐに価値レベルでの議論に飛びつくことがよくあります。たとえば、L1 と L2、分散化と効率性、あるいは金融ユースケースと非金融ユースケースのどちらを重視するかなどです。これらのトピックは誰でも参加できるため、魅力的です。これらは多くの論争を引き起こし、討論者に大きな影響力をもたらす可能性があります。しかし、問題の根本に到達していないのに、時期尚早にこれらの価値のトレードオフにこだわるのは賢明ではないかもしれません。本当に「技術効率のフロンティア」に到達する前に、イーサリアムは実際には直面していない価値観の対立についての仮説的な議論に従事するのではなく、その限界を可能な限り押し上げることに集中すべきであると私たちは考えています。

開発のスピードを上げることは、イーサリアムがその目標をより早く達成するのに役立ち、また、「Xを最初に行うべきか、それともYを最初に行うべきか?」という質問に答える機会も与えてくれます。

イーサリアムにはリソースが不足していません。私たちには、未来の構築に情熱を注ぐ研究者とエンジニアの素晴らしいチームがいます。彼らに十分な権限と動機を与えて、より速く、より並行して作業できるようにすることで、時期尚早な紛争に巻き込まれることを避け、問題をより迅速に解決することができます。

イーサリアムはどのように反復を高速化しますか?

歴史を振り返ると、イーサリアムは約 1 年に 1 回、主要なプロトコルのアップデートを展開してきました。私たちはそれがもっとできると考えています。

最も重要なことは、イーサリアムコミュニティは、より野心的な目標を持ち、それを達成するために全力を尽くすという精神的な決断を下す必要があるということです。障害の 1 つは慣性であり、もう 1 つはプロトコルが「硬直化」し始めるはずだという一部の人々の信念です。イーサリアムの分散化を維持する最善の方法は、コアプロトコルへの変更を遅らせることです。

私たちは、イーサリアムにとって「ハードニング」のリスクが高すぎると考えています。アプリケーションやユーザーがより集中化された代替手段に移行する可能性があるため、イーサリアムがプラットフォーム競争で優位性を維持することは困難になるだろう。また、「固定化」は地方分権そのものにもリスクをもたらします。コア開発プロセスは、エンジニア、研究者、検証者、さまざまな機関の意見を収集するイーサリアムの「ソーシャル層」のオフチェーンガバナンスの重要な現れです。イーサリアムのコアプロトコルが「固定」され、進化しなくなることは、このガバナンスメカニズムを放棄することと同じであり、イーサリアムがL2やMEVなどの市場構造の変化に対応することが困難になります。

イテレーションを高速化すると決めたら、開発プロセスに大きな違いをもたらす可能性のあるいくつかの改善点があります。

1. クライアントチームは「拒否権」ではなく「提案する権利」を持つべきである

開発スピードを犠牲にしてクライアントの多様性を確保する必要はありません。各アップグレードの前に同時にアップグレードの準備をできるようにするには、少なくとも複数のクライアントが必要ですが、「N-of-N」モデルを採用すべきではなく、最も保守的なクライアントチームにプロトコル全体の反復速度を決定させるべきではありません。私たちが維持する Reth クライアントは、イーサリアムのロードマップのボトルネックにならないことを約束します。

2. AllCoreDevs (すべてのコア開発者) プロセスを改善する

(最近のコンセンサスレイヤーの通話中に Tim Beiko が示唆したように) Pectra のレビューでより具体的な提案を提供するようコミュニティに呼びかけます。

3. DevOps (開発業務) とテストにより多くのリソースを割り当てます。

このようにして、イーサリアムの高い信頼性を維持しながら、より頻繁に大きな改善を提供することができます。

これらの最初の提案以外にも、イーサリアムのイテレーションを高速化する方法は他にもたくさんありますが、最も重要なのは「高速化」の必要性を明確に認識することです。

良いアイデアには事欠きません

私たちは、コミュニティからもっと多くの意見を得ることができたはずの「容易に実現できる成果」 (実装が比較的簡単で価値の高い改善) がたくさんあると考えています。ただし、これらの改善は、納期が遅いことと、「1 年以内にいくつかの変更しか加えられない」というコミュニティ間の一般的な合意により、現在保留されています。イーサリアムは自らを制限すべきではなく、より多くのことをより速く行うよう努めるべきです。

以下に考えられる例をいくつか示します。

1. 容量の拡張とL2セキュリティの確保

ロールアッププロジェクトでは、対応できるユーザー数とトランザクション数を決定するための需要計画を決定する必要があります。これには、EIP-4844 以降のロードマップ ( PeerDASやBlob-Parameter-Onlyハードフォークなど) にさらに多くのリソースを投資する必要があります。

Rollup は、L1 のセキュリティと検閲耐性も継承する必要があります。提案を参照してください: NativeRollups 。

2. ノードの負担を増やすことなく L1 容量を拡張します。

L1 オペコードの価格を変更すると、ブロックガス制限を変更せずにイーサリアムを拡張できるようになります [ 1、2 ]。

L1 実行層のガス制限を増やすことは現在活発な研究分野であり、「履歴の有効期限」や「ステートレス」などのスキームがどのように動作するかを決定するために、履歴と状態の成長を詳細に分析する必要があります。

3. 抽象アカウントを通じて、ウォレットのユーザーエクスペリエンスとセキュリティを向上させます。

EIP-7702 は外部所有アカウント (EOA) と抽象アカウント (AA ウォレット) の間のギャップを埋め始めていますが、次のようなさらなる改善の余地があると考えています。

バッチおよび支払いトランザクションをより便利にし、秘密キーへの過度の依存を排除することで、ユーザーエクスペリエンスを向上させます。

イーサリアムを加速するという使命にどのように貢献できるでしょうか?

私たちは研究者およびエンジニアとして、特に EIP-7862 などの提案に焦点を当てて、EIP、データ分析、およびコードを作成することでこの活動に参加します。これらは比較的議論の余地のない改善につながる可能性があり、既存のロードマップと矛盾することはありません。私たちは、ガスキャップに関してより安全な最適化を行う方法を理解するために、イーサリアムの状態と歴史を深く掘り下げました。

Reth は本番環境で使用する準備ができており、今後のハードフォークをサポートするためにアップグレードプロセスを加速し続けます。 Reth を設計したとき、研究者やエンジニアがさまざまな実験や革新を行うのを容易にするために、Reth を「EVM コア」ノード SDK として使用しました。また、イーサリアムのパフォーマンス、検閲耐性、将来の回復力を向上させるために、Reth で新機能のプロトタイプを作成するために私たちと協力する研究コミュニティを招待します。

最後に、コアプロトコルの更新をエンドユーザーに効率的に配信できるように、Foundry、Alloy、Solar、Revm、Wagmi、Viem などのいくつかの基本ツールの構築とサポートを継続します。