ヴィタリック：5年以内にイーサをビットコイン並みに簡単にする方法

Author: Vitalik Buterin; Compiled by GaryMa Wu Speaks Blockchain

概要

イーサリアムはグローバルな台帳を意図している。

イーサリアムはグローバルな台帳となることを意図しており、スケーラブルで弾力的である必要があります。プロトコルの簡素化の重要性に焦点を当て、本稿では、コンセンサス層（3スロットのファイナリティ、STARKアグリゲーション）と実行層（EVMをRISC-Vまたは同様のVMに置き換える）を簡素化することで、複雑さを劇的に軽減し、開発コスト、エラーのリスク、攻撃対象領域を削減することを提案する。後方互換性のある戦略（例：オンチェーンEVMインタプリタ）によって移行をスムーズにし、修正コード、シリアライゼーションフォーマット（SSZ）、ツリー構造を調和させ、さらにシンプルにすることが推奨される。目標は、イーサネットのコンセンサス・キー・コードをビットコインのシンプルさに近づけることであり、レジリエンスとエンゲージメントを高め、シンプルさに文化的な焦点を当て、コードの最大行数の目標を設定する必要がある。

イーサのゴールは、グローバルな元帳になることです。人類の文明の資産や記録を保存するプラットフォームであり、金融、ガバナンス、高価値データの認証などの分野に役立ちます。スケーラビリティとレジリエンスです。Fusakaのハードフォークでは、L2データに利用可能なスペースが10倍に増加することが計画されており、現在提案されている2026年のロードマップでは、L1レイヤーにも同様に大きな増加をもたらすことが計画されています。一方、イーサネットはプルーフ・オブ・ステーク（PoS）への移行を完了し、クライアントの多様性は急速に増加し、ゼロ・ナレッジ（ZK）の検証、量子抵抗の研究は着実に進み、アプリケーションのエコシステムはますます強固になっている。

この記事では、同様に重要でありながら過小評価されやすい、レジリエンス（そして実際にスケーラビリティ）の要素であるプロトコルのシンプルさにスポットライトを当てることを目的としています。

ビットコインプロトコルの最も称賛される側面の1つは、そのエレガントなシンプルさです:

1.ブロックの連鎖が存在する。ブロックの連鎖が存在し、それぞれがハッシュによって前のブロックに接続されている。

2.ブロックの有効性は、ハッシュの最初の数桁がゼロであることをチェックするプルーフ・オブ・ワーク（PoW）によって検証される。

3.各ブロックには、採掘報酬または以前のトランザクションの出力からコインをコストとするトランザクションが含まれます。

以上です！聡明な高校生でさえ、ビットコインのプロトコルがどのように動作するかを完全に理解することができ、プログラマーは趣味のプロジェクトとしてそのクライアントを書くことさえできます。

プロトコルのシンプルさは、ビットコイン（とイーサリアム）を信頼できる中立的でグローバルな基盤レイヤーにする多くの重要な利点をもたらします：

1.わかりやすさ：プロトコルの複雑さを減らすことで、より多くの人がその研究、開発、統治に参加できるようになり、技術的エリートによる支配のリスクを減らすことができます。

2.開発コストを削減する：プロトコルを単純化することで、新しいインフラを作る必要性が劇的に減ります（例えば、新しいクライアント、プロバー、開発者ツールなど）、プローバ、開発者ツールなど)。

3.メンテナンス負担の軽減：長期的なプロトコルのメンテナンスコストを削減します。

4.エラーのリスクを減らす：プロトコルの仕様と実装における壊滅的なエラーの可能性を減らします。また、そのようなエラーが存在しないことの検証も容易になります。

5.攻撃対象の絞り込み：プロトコルのコンポーネントの複雑さを減らすことで、特別な利益集団による攻撃のリスクを減らすことができます。リスクを減らすことができます。

歴史的に、Etherは（時には私自身の個人的な決定によって）物事をシンプルに保つことに失敗することが多く、高い開発コスト、セキュリティリスクの増加、そして複雑さによって求められる利益がしばしば幻であることが証明される閉鎖的な研究開発文化につながりました。複雑さによって得られるものは、しばしば幻であることが証明されてきた。この記事では、今から5年後のイーサがビットコインのシンプルさにどのように近づくかを探っていく。

新しいコンセンサスレイヤーの設計（歴史的に「ビーコンチェーン」として知られている）は、過去10年間のコンセンサスレイヤーの設計を活用することを目的としている。"）は、コンセンサス理論、ZK-SNARK開発、プレッジエコノミーにおける過去10年間の経験を活用し、長期的に最適でシンプルなコンセンサスレイヤーを構築することを目的としている。

1.3スロット最終設計：スロット、エポック、委員会の再編成、関連する効率的な処理メカニズム（委員会の同期など）といった概念の削除。 3スロットファイナリティの基本的な実装は約200行のコードしか必要とせず、Gasperと比較してほぼ最適なセキュリティを持つ。

2.アクティブな検証者の数を減らす：フォーク選択ルールをよりシンプルに実装できるようになり、セキュリティが強化されます。セキュリティが向上します。

3.STARKベースのアグリゲーションプロトコル：アグリゲーターを信頼したり、重複したアグリゲーターに対して高い料金を支払うことなく、誰でもアグリゲーターになることができます。アグリゲーターを信頼したり、ビットフィールドの重複に高い手数料を支払うことなく、誰でもアグリゲーターになれる。アグリゲート暗号はより複雑ですが、その複雑さは高度にカプセル化されており、システムリスクは低くなっています。

4.単純化されたP2Pアーキテクチャ：上記の要因は、より単純で堅牢なピアツーピアネットワークアーキテクチャをサポートするかもしれません。アーキテクチャをサポートするかもしれない。

5.認証メカニズムを再設計する：これには、入室、退室、引き出し、鍵変換のメカニズムが含まれます、inactivityリーク、およびコード行を簡略化し、より明確な保証を提供するための他のメカニズムが含まれます(例えば、弱い主観性サイクル)。

コンセンサス層の利点は、EVM実装層から比較的独立しているため、継続的な改善の余地が大きいことです。より大きな課題は、実行層で同様の単純化を達成することです。

実行層の簡素化

EVMはますます複雑になっており、その複雑さの多くは不必要であることが判明しています (私自身の意思決定が不十分だったせいもあります)。256ビットのVMは、現在では時代遅れになりつつある特定の形式の暗号化用に最適化されすぎており、単一のユースケース用に最適化されたプリコンパイルはほとんど使用されていません。

これらの問題に1つずつ対処しても、影響は限定的です。例えば、SELFDESTRUCTオペコードを削除することは、少しの利益のために多くの労力を要します。EOF（EVMオブジェクト・フォーマット）をめぐる最近の議論は、同様の課題を示しています。

私は最近、より急進的なシナリオを提案しました。1.5 倍の利益と引き換えに EVM に中規模の (それでも破壊的な) 変更を加える代わりに、100 倍の利益を達成するために、より優れたシンプルな VM に移行することができます。100倍の利益を達成する。合併と同様に、破壊的な変更の数を減らし、それぞれの変更をより意味のあるものにする。具体的には、EVMをRISC-VやEther ZKプローバーが使用する別のVMに置き換えることを提案する。その結果、次のことが可能になります:

1.劇的な効率性の向上：（プロヴァーでの）スマート・コントラクトの実行は、Ether ZKプロヴァーで使用されるVMを必要としません。Succinctのデータは、多くのシナリオで100倍以上のパフォーマンス向上を示しています。

2.シンプルさの劇的な向上：RISC-V仕様はEVMと比べて非常にシンプルで、Cairoなどの代替案も同様にシンプルです。Cairo などのソリューションも同様にシンプルです。

3.EOFをサポートする動機：たとえば、コードの分割、より使いやすい静的解析、より大きなコードサイズ制限など。サイズ制限など。

4.開発者のためのより多くのオプション：SolidityとVyperは、新しいVMにコンパイルするためのバックエンドを追加できます。新しいVMにコンパイルすることができます。RISC-V を選択した場合、主流の言語開発者もコードを仮想マシンに簡単に移植できます。

5.プリコンパイルのほとんどを削除する：おそらく、高度に最適化された楕円曲線演算だけが保持されるでしょう（量子コンピューターが一般的になれば、これらもなくなるでしょう）。量子コンピュータが普及すれば、これらも姿を消すでしょう）。

主な欠点は、すぐに使えるEOFとは異なり、新しいVMの利点が開発者に届くまでに時間がかかることです。短期的には、価値の高い EVM の改善 (たとえば、コントラクト コードのサイズ制限を増やす、DUP/SWAP17-32 をサポートする) を実装することで、これを緩和できます。

これは、よりシンプルなVMにつながります。中核となる課題は、既存のEVMをどうするかということです。"text-align: left;">EVMを簡素化する (または複雑さを追加せずに改善する) 最大の課題は、ターゲット実装と既存のアプリケーションとの後方互換性のバランスをとることです。

最初にはっきりさせておくべきことは、Ethernet コードベースを定義する方法は (たとえ単一のクライアント内であっても) 1 つだけではないということです。

イーサネットのコードベースを定義する方法は1つだけではありません。align: left;">目標は、グリーンゾーンを最小化することです：ノードがイーサのコンセンサスに参加するために必要なロジックです。(フォーク選択ルール）、および「通常の」ブロック構築を含む。

オレンジ色の領域削減できない：プロトコル仕様が特定の実行レイヤーの機能を削除または変更する場合（例：仮想マシン、例えば、仮想マシン、プリコンパイルなど）、履歴ブロックを処理するクライアントは、関連するコードを保持する必要があります。しかし、新しいクライアント、ZK-EVM、または形式的証明者は、オレンジ色の領域を完全に無視することができます。

追加イエローゾーン：現在のチェーンを理解したり、ブロック構築を最適化するために非常に重要です。現在のチェーンやブロック構築の最適化を行うが、コンセンサスロジックの一部ではない。例えば、EtherscanといくつかのブロックビルダーはERC-4337のユーザー操作をサポートしています。EtherChannelsの一部の機能（EOAやサポートしている古いトランザクションタイプなど）をオンチェーンRISC-V実装に置き換えると、コンセンサスコードは大幅に簡素化されますが、専用ノードは元のコードを使用して解析を続けることができます。

オレンジと黄色の部分の複雑さはカプセル化の複雑さであり、プロトコルを理解している人はこれらの部分をスキップでき、イーサネットの実装は無視でき、これらの領域でのエラーはコンセンサスリスクを上げません。その結果、オレンジと黄色の領域のコードの複雑さは、緑の領域の複雑さよりもはるかに害が少なくなります。

緑色の領域から黄色の領域にコードを移動させるという考え方は、Rosetta翻訳レイヤーを通して長期的な後方互換性を確保するというAppleの戦略に似ています。

Ipsilonチームによる最近の記事に触発されて、私は以下のVM変更プロセスを提案します (EVMからRISC-Vの場合ですが、EVMからCairoまたはRISC-Vからより良いVMへの変更にも使用できます)。

1.新しいプリコンパイル・プロバイダー・チェーンにRISC-V実装を要求する：エコシステムをRISC-V VMに適応させる。エコシステムをRISC-V VMに順応させます。

2.開発者オプションとしてRISC-Vを導入する：プロトコルはRISC-VとEVMの両方をサポートします。EVM、および両方のVMのコントラクトは自由に相互作用できます。

3.ほとんどのプリコンパイルの置き換え：RISC-Vは、楕円曲線操作とKECCAK（極端な速度が必要）を除くすべてのコントラクトに使用されます。楕円曲線操作とKECCAK（極端な速度が要求される）を除き、プリコンパイルをRISC-V実装に置き換える。そのアドレスのコード（DAOフォークに似ている）をnullからRISC-V実装に変更しながら、ハードフォークによってプリコンパイルを削除する。RISC-V VMは非常にシンプルであり、ここで停止しても、単純化されたプロトコルを得ることができた。

4.RISC-VでEVMインタプリタを実装する：スマートコントラクトとしてオンチェーン（ZKプルーファで必要）。プローバーのニーズは実行済み)。既存のEVMコントラクトは、最初のリリースから数年後にこのインタプリタを通して実行されます。

ステップ4を完了した後も、「EVM実装」の多くは、ブロック構築、開発者ツール、チェーン分析の最適化に使用されますが、主要なコンセンサス仕様の一部ではなくなります。イーサネット・コンセンサスは、RISC-Vのみを「ネイティブに」理解するようになります。

プロトコルの全体的な複雑さを減らす3つ目の (そして最も過小評価されている) 方法は、スタックのできるだけ多くの部分で統一された標準を共有することです。異なるプロトコルが異なるシナリオで同じことをするのは、多くの場合有益ではありませんが、このようなパターンがいまだによく発生するのは、主にプロトコルのロードマップの異なる部分間のコミュニケーション不足が原因です。ここでは、コンポーネントを共有することでイーサネットを簡素化する具体例をいくつか紹介します。

統一訂正符号

3つのシナリオで削除コードを修正する必要があります: