原題: Simplifying the L1

原著者: Vitalik Buterin

原訳: GaryMa、Wu Says Blockchain

要約

Ethereum は、スケーラビリティと回復力を必要とするグローバル台帳になることを目指しています。この記事では、プロトコルのシンプルさの重要性に焦点を当て、コンセンサス層（3 スロットのファイナリティ、STARK 集約）と実行層（EVM を RISC-V または同様の仮想マシンに置き換える）を簡素化することで、複雑さ、開発コスト、エラーリスク、攻撃対象領域を大幅に削減することを提案します。下位互換性のある戦略（オンチェーン EVM インタープリターなど）を通じて移行をスムーズにし、消去コード、シリアル化形式（SSZ）、およびツリー構造を統一してさらに簡素化することをお勧めします。目標は、イーサリアムのコンセンサスクリティカルなコードをビットコインのシンプルさに近づけ、回復力と参加性を向上させ、シンプルさを重視してコードの最大行数目標を設定する文化を要求することです。

イーサリアムの目標は、グローバル台帳になることです。つまり、人類の文明の資産と記録を保存し、金融、ガバナンス、高価値データの認証の分野に役立つプラットフォームです。これには、スケーラビリティと回復力という 2 つの側面でのサポートが必要です。 Fusaka ハードフォークは、L2 データに使用できるスペースを 10 倍に増やす予定であり、現在提案されている 2026 年のロードマップでは、L1 レイヤーに同様に大きな増加をもたらす予定です。同時に、イーサリアムはプルーフ・オブ・ステーク（PoS）への移行を完了し、クライアントの多様性が急速に高まり、ゼロ知識（ZK）検証や量子耐性の研究も着実に進歩しており、アプリケーションエコシステムはますます堅牢になっています。

この記事では、回復力（さらにはスケーラビリティ）において同様に重要でありながら過小評価されがちな要素である、プロトコルの単純さに焦点を当てます。

ビットコイン プロトコルの最も素晴らしい点は、その洗練されたシンプルさです。

1.ブロックのチェーンがあり、各ブロックはハッシュを介して前のブロックに接続されています。

2.ブロックの有効性は、ハッシュ値の最初の数桁がゼロであるかどうかを確認する Proof of Work (PoW) によって検証されます。

3.各ブロックにはトランザクションが含まれており、トランザクションで費やされたコインはマイニング報酬または以前のトランザクション出力から得られます。

これで完了です。優秀な高校生でもビットコインのプロトコルがどのように機能するかを完全に理解でき、プログラマーはサイドプロジェクトとしてクライアントを作成することさえできます。プロトコルのシンプルさにより、信頼できる中立的なグローバル ベース レイヤーとしての Bitcoin (および Ethereum) にいくつかの重要な利点がもたらされます。

1.理解しやすい: プロトコルの複雑さを軽減し、より多くの人がプロトコルの研究、開発、ガバナンスに参加できるようにし、技術エリートによって支配されるリスクを軽減します。

2.開発コストの削減: プロトコルを簡素化することで、新しいインフラストラクチャ (新しいクライアント、証明者、開発者ツールなど) を作成するコストが大幅に削減されます。

3.保守負担の軽減:長期契約の保守コストを削減します。

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

5.攻撃対象領域を削減:プロトコルの複雑なコンポーネントを削減し、特別利益団体による攻撃を受けるリスクを軽減します。

歴史的に、Ethereum は (時には私の個人的な決定により) 物事をシンプルに保つことができず、過剰な開発コスト、セキュリティ リスクの増大、閉鎖的な研究開発文化を招き、複雑さを追求することで得られる利益が幻想的であることがしばしば証明されてきました。この記事では、5年後のイーサリアムがビットコインのシンプルさにどのように近づくのかを探ります。

簡素化されたコンセンサス レイヤー

新しいコンセンサス レイヤーの設計 (従来は「ビーコン チェーン」と呼ばれていました) は、コンセンサス理論、ZK-SNARK 開発、ステーキング エコノミクスなどの分野における過去 10 年間の経験を活用して、長期的に最適でよりシンプルなコンセンサス レイヤーを構築することを目的としています。既存のビーコン チェーンと比較して、新しい設計は大幅に簡素化されています。

1. 3 スロットのファイナリティ設計:スロット、エポック、委員会の再編成、および関連する効率的な処理メカニズム (同期委員会など) などの概念を削除します。 3 スロットファイナリティの基本的な実装には約 200 行のコードしかかからず、Gasper と比較してほぼ最適なセキュリティを備えています。

2.アクティブなバリデーターの数を減らす: フォーク選択ルールの実装を簡素化し、セキュリティを強化します。

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

4. P2P アーキテクチャを簡素化:上記の要因により、よりシンプルで堅牢なピアツーピア ネットワーク アーキテクチャがサポートされる可能性があります。

5.検証メカニズムを再設計します。 エントリ、エグジット、ウィズアウト、キー変換、非アクティブリークなどのメカニズムを含め、コード行数を簡素化し、より明確な保証（弱い主観サイクルなど）を提供します。

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

実行層の簡素化

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

これらの問題を一つずつ解決しても、効果は限られます。たとえば、SELFDESTRUCT オペコードを削除するのは、ほとんどメリットがないのに多大な労力を要しました。 EOF (EVM オブジェクト形式) に関する最近の議論でも同様の課題が示されています。

私は最近、より根本的な解決策を提案しました。1.5 倍のメリットと引き換えに EVM に中程度の規模 (ただし依然として混乱を招く) の変更を加える代わりに、より優れたシンプルな VM に移行して 100 倍のメリットを実現するというものです。 The Merge と同様に、破壊的な変更の数を減らしながら、各変更をより意味のあるものにします。具体的には、EVM を RISC-V、または Ethereum ZK 証明器で使用される別の仮想マシンに置き換えることを提案します。これにより、次のことが実現します:

1.大幅な効率性の向上:スマート コントラクトの実行 (証明者内) ではインタープリターのオーバーヘッドが不要になり、直接実行されます。 Succinct のデータによれば、多くのシナリオでパフォーマンスが 100 倍以上向上する可能性があります。

2.大幅に改善されたシンプルさ:RISC-V 仕様は EVM に比べて非常にシンプルであり、代替手段 (Cairo など) も同様にシンプルです。

3. EOF をサポートする理由:コードの分割、より使いやすい静的分析、より大きなコード サイズの制限など。

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

5.プリコンパイルの大部分を削除する: おそらく、高度に最適化された楕円曲線演算のみが保持されます (量子コンピュータが普及すると、これらも消えるでしょう)。

主な欠点は、すぐに使用できる EOF とは異なり、新しい VM の利点が開発者に浸透するまでに時間がかかることです。この問題は、短期的に価値の高い EVM の改善 (コントラクト コードのサイズ制限の増加や DUP/SWAP17～32 のサポートなど) を実装することで軽減できます。

これにより、仮想マシンがよりシンプルになります。主な課題は、既存の EVM をどのように処理するかということです。

仮想マシン移行の下位互換性戦略

EVM を簡素化 (または複雑さを増やさずに改善) する際の最大の課題は、ターゲット実装と既存アプリケーションの下位互換性のバランスをどのように取るかです。

· まず、Ethereum コードベースを定義する方法は 1 つだけではないことを明確にする必要があります (単一のクライアント内でも)。

· 目標は、グリーン エリアを最小限に抑えることです。グリーン エリアとは、現在の状態の計算、証明、検証、FOCIL (フォーク選択ルール)、および「通常の」ブロック構築など、ノードが Ethereum コンセンサスに参加するために必要なロジックです。

· オレンジ色の領域は縮小できません。プロトコル仕様によって実行層の機能 (仮想マシン、プリコンパイルなど) が削除または変更された場合でも、履歴ブロックを処理するクライアントは関連するコードを保持する必要があります。ただし、新しいクライアント、ZK-EVM、または正式な証明者はオレンジ色の領域を完全に無視できます。

· 新しく追加された黄色の領域: 現在のチェーンを理解したり、ブロック構築を最適化したりするのに非常に価値がありますが、コンセンサス ロジックには属しません。たとえば、Etherscan や一部のブロック ビルダーは ERC-4337 ユーザー操作をサポートしています。一部の Ethereum 機能 (EOA やそれがサポートする従来のトランザクション タイプなど) をオンチェーン RISC-V 実装に置き換えると、コンセンサス コードは大幅に簡素化されますが、専用ノードは解析に元のコードを引き続き使用する可能性があります。

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

コードを緑色の領域から黄色の領域に移動するという考え方は、Rosetta 変換レイヤーを通じて長期的な下位互換性を確保するという Apple の戦略に似ています。 Ipsilon チームの最近の記事に触発されて、次の VM 変更プロセスを提案します (例として EVM から RISC-V を使用していますが、EVM から Cairo や RISC-V からより優れた VM への変更にも使用できます)。

1.オンチェーン RISC-V 実装を提供するには、新しいプリコンパイルが必要です。 エコシステムが RISC-V 仮想マシンに徐々に適応できるようにします。

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

3.ほとんどのプリコンパイルを置き換えます:楕円曲線演算と KECCAK (極めて高速な処理が必要なため) を除き、その他のプリコンパイルは RISC-V 実装に置き換えられます。プリコンパイルはハードフォークによって削除され、そのアドレスのコード (DAO フォークと同様) は何もなかった状態から RISC-V 実装に変更されました。 RISC-V 仮想マシンは非常に単純なので、ここで止めてもプロトコルが簡素化されるだけです。

4. RISC-V で EVM インタープリターを実装する: オンチェーンでスマート コントラクトとして (ZK 証明者の要件によりすでに実行済み)。最初のリリースから数年経ち、既存の EVM 契約はこのインタープリターを通じて実行されるようになりました。

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

プロトコル コンポーネントの共有による簡素化

プロトコルの全体的な複雑さを軽減する 3 番目の方法 (最も過小評価されている方法) は、プロトコル スタックのさまざまな部分で統一された標準を可能な限り共有することです。通常、異なるプロトコルが異なるコンテキストで同じことを行うのは役に立ちませんが、このパターンは依然として頻繁に発生します。これは主に、プロトコル ロードマップの異なる部分間のコミュニケーション不足が原因です。ここでは、共有コンポーネントを通じて Ethereum を簡素化する具体的な例をいくつか示します。

統合消去コード

消去コードが必要になるシナリオは次の 3 つです。

1.データ可用性サンプリング:クライアントは、ブロックが公開されていることを確認します。

2.より高速な P2P ブロードキャスト:ノードは n/2 個のフラグメントを受信した後にブロックを受け入れることができるため、レイテンシと冗長性のバランスが取れます。

3.分散履歴ストレージ: Ethereum の履歴データはシャードに保存され、n/2 フラグメントの各グループは残りのフラグメントを復元できるため、単一のフラグメントが失われるリスクが軽減されます。

3 つのシナリオで同じ消失訂正符号 (リード・ソロモン、ランダム線形符号など) を使用すると、次の利点が得られます。

1.コードの量を最小限にする:コードの総行数を減らします。

2.効率を向上:ノードがシーンのフラグメントをダウンロードすると、これらのデータを他のシーンで使用できます。

3.検証可能性の確保:すべてのシーン セグメントはルートに対して検証可能です。

異なる消失訂正符号を使用する場合は、少なくとも互換性を確保する必要があります。たとえば、データ可用性サンプリング用の水平リード・ソロモン符号と垂直ランダム線形符号は同じドメインで動作します。

統一されたシリアル化形式

Ethereum のシリアル化形式は、データを任意の形式で再シリアル化してブロードキャストできるため、現在のところ部分的にしか固まっていません。例外はトランザクション署名ハッシュで、これは標準化された形式でハッシュする必要があります。将来的には、以下の理由によりシリアル化形式の強化がさらに進む予定です。1. アカウントの完全な抽象化 (EIP-7701): トランザクションの完全な内容が仮想マシンに表示されます。

2.より高いガス制限:実行層のデータは、データ ブロック (BLOB) に配置する必要があります。

その頃には、Ethereum の 3 つのレベル（実行層、コンセンサス層、スマート コントラクト呼び出し ABI）のシリアル化形式を統一する機会が得られるでしょう。

SSZ は次の理由から SSZ を使用することを提案します。

1.デコードが簡単:スマート コントラクトに含まれています (4 バイト ベースの設計とエッジ ケースの少なさのため)。

2.コンセンサス層で広く使用されています。

3.既存の ABI と非常に類似: ツールの適応は比較的簡単です。

SSZ への完全な移行に向けた取り組みが行われており、将来のアップグレードを計画する際には、これらの取り組みを検討し、継続する必要があります。

統合ツリー構造

EVM から RISC-V (またはその他のオプションの最小限の仮想マシン) に移行する場合、平均的な場合でも、16 進数の Merkle Patricia ツリーが証明ブロック実行の最大のボトルネックになります。より優れたハッシュ関数に基づくバイナリ ツリーに移行すると、証明者の効率が大幅に向上し、軽量クライアントなどのシナリオでデータ コストが削減されます。移行するときは、コンセンサス レイヤーが同じツリー構造を使用していることを確認する必要があります。これにより、Ethereum のコンセンサス層と実行層が同じコードを通じてアクセスおよび解析可能になります。

現在から未来へ

シンプルさは多くの点で分散化に似ており、どちらも回復力という目標の上流にあります。シンプルさを明確に評価するには、ある種の文化的変化が必要です。メリットを定量化することは難しい場合が多く、一方で余分な労力と優れた機能の一部を放棄することによるコストはすぐに発生します。しかし、時間が経つにつれて、そのメリットはますます大きくなります。ビットコイン自体がその完璧な例です。

私は tinygrad の例に倣い、Ethereum の長期的な仕様に対して明示的な最大コード行数目標を設定し、Ethereum のコンセンサスが重要なコードを Bitcoin のシンプルさに近づけることを提案します。 Ethereum の従来のルールを処理するコードは引き続き存在しますが、コンセンサス クリティカル パスの外側に配置する必要があります。同時に、よりシンプルなソリューションを選択するという哲学を堅持し、システムの複雑さよりもカプセル化の複雑さを優先し、明確なプロパティと保証を提供する設計上の選択を行う必要があります。

元のリンク