Vitalikの新しい記事：イーサリアムはどのようにビットコインに対してシンプルなアーキテクチャを実現するのか？

ChainCatcher セレクション

2025-05-03 18:10:55

コレクション

ヴィタリックは、イーサリアム L1 を簡素化し、RISC-V と SSZ を採用し、歴史的ルールを隔離し、TinyGrad のシンプルなコードスタイルを継続することを提案しました。

共有する

WeChatでQRコードをスキャン

原文：Simplifying the L1

著者：Vitalik

編訳：lenaxin，ChainCatcher

イーサリアムは、文明の資産と記録を保存するためのプラットフォームとして、世界的な台帳になることを目指しています。これは、金融、ガバナンス、高価値データの認証などの基盤層です。これには、2つの条件が必要です：スケーラビリティとレジリエンス。Fusakaハードフォークは、レイヤー2（L2）のデータの利用可能なスペースを10倍に増やすことを目指しており、現在提案されている2026年のロードマップでも、レイヤー1（L1）の大幅な拡張が提案されています。同時に、イーサリアムは、プルーフ・オブ・ステーク（Proof of Stake）メカニズムへのマージアップグレードを完了し、クライアントの多様性が急速に向上し、ゼロ知識証明（ZK Verifiability）の検証可能性や量子コンピュータに対する耐性の向上に向けた作業も進行中で、さまざまなアプリケーションもますます堅牢になっています。

この記事は、レジリエンス（最終的にはスケーラビリティにも影響を与える）の一側面に焦点を当てることを目的としています。この側面は同様に重要ですが、過小評価されがちです。それは、プロトコルのシンプルさです。

ビットコインの大きな利点は、そのプロトコルが非常にシンプルで美しいことです。

ブロックチェーンは、一連のブロックで構成されており、各ブロックはハッシュ値によって前のブロックと接続されています。ブロックの有効性は、プルーフ・オブ・ワークメカニズムによって検証され、ハッシュ値の最初の数桁がゼロであるかどうかが確認されます。各ブロックにはいくつかのトランザクションが含まれており、これらのトランザクションで消費されるコインは、マイニングによって生成されるか、以前のトランザクションの出力から来ます。ビットコインプロトコルの核心メカニズムはここにあります。賢い中学生でもこのプロトコルを完全に理解できますし、プログラマーは趣味のプロジェクトとしてクライアントを作成することさえできます。

プロトコルのシンプルさを維持することは、ビットコインやイーサリアムが世界的に認められた中立的な基盤層になるための重要な利点を提供します：

シンプルなプロトコルは分析が容易であり、より多くの参加者がプロトコルの研究、開発、ガバナンスに参加しやすく、技術的な独占リスクを低減します。
プロトコル構造の簡素化は、新しいインフラ（クライアント、証明器、ログツール、その他の開発ツール）との統合にかかる開発コストを大幅に削減します。
プロトコルのシンプルな設計は、長期的なメンテナンスコストを効果的に削減します。
プロトコル仕様およびその実装における重大な脆弱性のリスクが大幅に減少し、システムの安全性を検証しやすくなります。
社会的攻撃面の削減：コンポーネントの簡素化により、システムは特定の利益の浸透からの防御が容易になり、全体的な安全性が向上します。

歴史的に、イーサリアムはプロトコル設計においてシンプルさの原則を貫徹できていないことが多く（その一因は私自身の決定に起因します）、これが直接的に研究開発コストの高止まりや安全性のリスク、研究開発文化の閉鎖性を引き起こしています。これらの問題の根源は、実践によって無効であることが証明された短期的な利益を追求することにあります。この記事では、今後5年間でイーサリアムがビットコインに近いプロトコルのシンプルさを実現する方法を説明します。

コンセンサス層の簡素化

3sf - mini（イーサリアムテストネットのコード名）での3スロット最終性のシミュレーション

新しいコンセンサス層の提案（以前は「ビームチェーン」と呼ばれていました）は、過去10年間のコンセンサス理論、ゼロ知識証明（ZK-SNARK）、ステーキング経済学などの研究成果を統合し、イーサリアムに向けた長期的な最適なコンセンサスメカニズムを構築することを目指しています。既存のビーコンサインと比較して、この提案は以下の点で著しく簡素化されています：

3スロット最終性（3-slot finality）アーキテクチャの革新：独立したスロットとエポックの概念を排除し、委員会のローテーションメカニズムや同期委員会などの複雑なコンポーネントを廃止し、プロトコル仕様を大幅に簡素化しました。コア実装は約200行のコードで済み、Gasperプロトコルに対してほぼ最適な安全性を達成しています。
検証ノード管理の最適化：アクティブな検証ノードの数を制限することで、フォーク選択ルール（fork choice rule）をより簡素化された実装にすることができ、システムの安全性を確保します。
集約プロトコルのアップグレード：STARKに基づく集約メカニズムにより、任意のノードが集約役割を担うことができ、集約者への信頼依存やビットフィールドのリソース浪費の問題を回避します。集約暗号学自体は複雑ですが、その高度なカプセル化特性により、システムリスクが大幅に低減されます。
P2Pネットワークアーキテクチャの改善：上記の2つの最適化により、よりシンプルで効率的なピアツーピアネットワークアーキテクチャの構築が可能になります。
検証プロセスの再構築：検証ノードの参加、退出、引き出し、キー移行、怠惰な罰則などのメカニズムを再設計し、コード量を削減しつつ、コアパラメータ（弱主観周期など）の保障メカニズムを明確にします。
技術的利点：コンセンサス層とEVM実行層の相対的なデカップリング特性により、継続的な最適化のための技術的な余地が広がります。それに対して、実行層の同様の改善はより大きな課題に直面しています。

実行層の簡素化

イーサリアム仮想マシン（EVM）の複雑性は増大し続けており、その多くの複雑な設計は不必要であることが証明されています（多くの場合、私の決定ミスによるものです）：特定の暗号アルゴリズムに過度に最適化された256ビットの仮想マシンであり、これらのアルゴリズムは現在重要性を失いつつあります。また、単一の使用シーンに過度に設計されたプリコンパイルコントラクトも、実際の使用率は非常に低いです。

既存の問題を断片的に修正しようとする試みはもはや不可能です。SELFDESTRUCTオペコードの削除には膨大な努力が必要ですが、得られる利益は限られています。最近のEOFに関する議論は、仮想マシンに対する漸進的な修正の困難さをさらに浮き彫りにしています。

代替案として、私は最近、より過激な転換経路を提案しました：EVMに中規模（しかし依然として破壊的な）変更を加えて1.5倍の性能向上を図るよりも、全く新しく、著しく優れた仮想マシンアーキテクチャに直接移行して、100倍の性能向上を実現する方が良いということです。合併（The Merge）と同様に、破壊的な変更の回数を減らしつつ、各変更の戦略的価値を高めます。具体的には、RISC-VアーキテクチャまたはイーサリアムZK証明プログラムで使用される仮想マシンを現行のEVMの代わりに採用することを提案します。この転換は以下の利点をもたらします：

効率の革命的向上：ZK証明環境では、スマートコントラクトがターゲットアーキテクチャ上で直接実行され、インタプリタのオーバーヘッドが不要になります。Succinctのデータによれば、ほとんどのシーンで性能が100倍以上向上します。
アーキテクチャの極限の簡素化：RISC-V仕様はEVMに比べて非常に簡素であり、他の候補（Cairoなど）も同様にシンプルな特性を持っています。
EOFの核心的利点の継承：コードのセグメント管理、より友好的な静的分析サポート、より大きなコード容量制限を含みます。
開発者ツールチェーンの拡張：SolidityとVyperは、新しいアーキテクチャへのバックエンドコンパイルを追加することでサポートできます。RISC-Vを選択すれば、主流の言語開発者は既存のコードを直接移植できます。
プリコンパイルコントラクトの最適化：ほとんどのプリコンパイル機能はもはや必要なくなり、高度に最適化された楕円曲線演算のみが残ります（量子コンピュータの進展により淘汰される可能性があります）。

主な課題は、即座に実施可能なEOFソリューションとは異なり、新しい仮想マシンは開発者に利益をもたらすまでにより長い時間がかかることです。契約コードのサイズ制限を引き上げる、DUP/SWAP命令セットを最適化するなどの高価値のEVM改善を部分的に同時に実施することで、短期的な移行の手段とすることができます。

この転換は、仮想マシンアーキテクチャを大幅に簡素化します。核心的な問題は、既存のEVMエコシステムをどのように適切に処理するかです。

仮想マシン移行の後方互換性戦略

EVMの任意の部分を簡素化（または複雑さを増さずに最適化）する最大の課題は、期待される目標を達成することと、既存のアプリケーションの後方互換性を維持することのバランスを取ることです。

まず明確にする必要があるのは、単一のクライアントに対しても、「イーサリアムコードベース」とは何かを定義する唯一の基準は存在しないということです。

目標は緑の領域を最小化することです：これは、ノードがイーサリアムのコンセンサスに参加するために必要なロジックであり、現在の状態の計算、証明の生成と検証、FOCIL（注：専門用語の略称か確認が必要）および「基礎」ブロック構築プロセスを含みます。

オレンジの領域は削減できません：実行層の機能（仮想マシン、プリコンパイルコントラクト、または他のメカニズム）がプロトコル仕様から削除されるか、その機能が変更される場合、過去のブロックを処理するクライアントはその機能を保持する必要があります。しかし、新しいクライアント（ZK-EVMや形式的検証ツールを含む）は、この部分を完全に無視できます。

新たに黄色の領域が追加されます：これは、現在のチェーン上のデータ解析や最適なブロック構築に非常に価値がありますが、コンセンサスメカニズムには属しないコードです。典型的な例は、Etherscanや一部のブロックビルダーがERC-4337ユーザー操作をサポートすることです。イーサリアムのコア機能（外部アカウントEOAおよびそのサポートするさまざまな旧式トランザクションタイプ）をチェーン上のRISC-V実装に置き換えると、コンセンサスコードは大幅に簡素化されますが、専用ノードは依然として元のコードを使用して解析処理を行う必要があるかもしれません。

オレンジと黄色の領域の複雑性はカプセル化の複雑性に属し、プロトコルを理解しようとする人はこれらの部分をスキップできます。Ethereumの実装も自由に無視できます。さらに、これらの領域のコードの欠陥はコンセンサスリスクを引き起こすことはありません。これは、緑の領域のコードの複雑性に比べて、オレンジと黄色の領域の複雑性がシステム全体に与える負の影響が著しく低いことを意味します。

コードを緑の領域から黄色の領域に移行する考え方は、AppleがRosetta翻訳レイヤーを通じて長期的な後方互換性を実現する技術的なアプローチに似ています。

すべての新しく開発されたプリコンパイルコントラクトには、仕様に準拠したチェーン上のRISC-V実装を含める必要があります。このステップは、エコシステムがRISC-V仮想マシン環境に徐々に適応することを促進することを目的としています（EVMからRISC-Vへの移行の例として、このアプローチはEVMからCairoまたは他のより優れた仮想マシンへの移行にも適用されます）：

二重仮想マシンの並行サポート：プロトコルレベルでRISC-VとEVMの2つの仮想マシンをネイティブにサポートします。開発者は自由に開発言語を選択でき、異なる仮想マシンで書かれたコントラクトはシームレスに相互作用できます。
プリコンパイルコントラクトの段階的置き換え：楕円曲線演算とKECCAKハッシュアルゴリズム（その性能要求が極めて高いため）を除き、すべてのプリコンパイルコントラクトはハードフォークを通じてRISC-V実装に置き換えられます。
具体的な操作：元のプリコンパイルコントラクトを削除する際に、そのアドレスのコード（DAOフォークモードを使用）を空の状態から対応するRISC-V実装に変更します。RISC-Vアーキテクチャの高度な簡素性により、このステップを完了するだけでも、システム全体の複雑性は低下します。
EVMインタプリタのチェーン上展開：RISC-Vに基づいてEVMインタプリタを実装し（ZK証明ツールチェーンがこのような開発を促進しています）、それをスマートコントラクトとしてチェーン上に展開します。初期バージョンがリリースされてから数年後、既存のEVMコントラクトはこのインタプリタを通じて実行され、新しい仮想マシンへのスムーズな移行を完了します。

プロトコルコンポーネントを共有することで簡素化を実現

ステップ4が完了すると、多くの「EVM実装ソリューション」は依然として保持され、ブロック構築、開発者ツール、チェーン上データ分析などのシーンで最適化に使用されますが、これらの実装はもはやコアコンセンサス仕様の一部とは見なされません。その時点で、イーサリアムのコンセンサスメカニズムは「ネイティブ」にRISC-Vアーキテクチャのみをサポートします。

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

プロトコル全体の複雑性を減少させる第3の方法（最も過小評価されがちな方法でもあります）は、異なるプロトコルスタックレベル間で統一基準を共有することです。一般的に、異なるモジュールで同じ機能を実現するために異なるプロトコルを採用することは必要なく、利益もありませんが、このような設計パターンは依然として広く存在しています。その主な理由は、プロトコルのロードマップの各部分間に効果的な協調が欠けているからです。以下は、コンポーネントのクロスレイヤー再利用を強化することでイーサリアムを簡素化できる具体的なシーンの例です。

統一共有エラーハンドリングコード

エラーハンドリングの3つの適用シーン：

データ可用性サンプリング：クライアントがブロックが公開されたかどうかを検証する際にエラーハンドリングを使用し、データの完全性を確保します。
効率的なP2Pブロードキャスト：ノードがn個のシャードのうちn/2個を受信した時点でブロックを確認でき、遅延と冗長性の最適なバランスを実現します。
分散型履歴ストレージ：イーサリアムの履歴データは複数のデータブロックに分割され、以下の条件を満たします：

各データブロックは独立して検証可能
任意のグループ内でn/2個のデータブロックがあれば、残りのn/2個のデータブロックを復元可能

この設計は、単一障害点のデータ損失リスクを大幅に削減します。

以下の3つのシーンで同じエラーハンドリングを使用することで、著しい利点が得られます：

コードの簡素化；
効率の向上：ノードが特定のシーンでシャードデータをダウンロードする必要がある場合（完全なブロックではなく）、そのデータは他のシーンでも直接使用でき、再送信を避けます；
すべてのシーンでデータブロックはルートハッシュを通じて統一検証されます。

異なるエラーハンドリングを使用する場合は、互換性要件を満たす必要があります：たとえば、データ可用性サンプリング（DAS）シャード内で横方向のリード・ソロモン符号と縦方向のランダム線形符号を同時に使用することができますが、両方の符号は同じ有限体で計算する必要があります。

統一シリアル化フォーマット

現在のイーサリアムのシリアル化フォーマットは半規格化された状態にあり、データは任意のフォーマットに再シリアル化されて伝播されることができます。唯一の例外はトランザクション署名ハッシュであり、このシーンではハッシュの一貫性を確保するために規格化されたフォーマットを使用する必要があります。しかし、将来的には、シリアル化フォーマットの規格化の程度がさらに強化されるでしょう。その主な理由は以下の通りです：

アカウントの抽象化（EIP-7701）：完全なトランザクション内容が仮想マシン（VM）に完全に見えるようになります。
高Gas制限シーン：ブロックのGas上限が引き上げられるにつれて、実行層のデータはblob構造に保存される必要があります。

これらの変化が起こると、イーサリアムの3つの重要なレベルのシリアル化基準を統一する機会が得られます：（i）実行層（ii）コンセンサス層（iii）スマートコントラクト呼び出しABI

SSZシリアル化フォーマットの採用を提案します。SSZには以下の利点があります：

デコードが効率的で、スマートコントラクトを含むシーンで迅速にデコードでき、4バイトに基づく設計と少ない境界条件処理の恩恵を受けています。
コンセンサス層での広範な適用があり、すでにコンセンサス層に深く統合されています。
既存のABIに非常に似ているため、ツールチェーンの適応とアップグレードが容易です。

現在、関連技術チームがSSZの全面的な移行作業を進めています。今後のアップグレード計画において、この技術的な路線を継続し、既存の成果に基づいて拡張することを提案します。

統一共有ツリー構造

EVMからRISC-V（または他の簡素な仮想マシンアーキテクチャ）に移行すると、六叉Merkle Patriciaツリーがブロック実行証明の最大の性能ボトルネックになります（通常のシーンでも同様です）。より優れたハッシュ関数に基づく二叉木構造に移行することで、証明効率が大幅に向上し、軽ノードや他のアプリケーションシーンのデータストレージコストが削減されます。

この移行を実施する際には、コンセンサス層と実行層の統一を実現するために、同じツリー構造を採用する必要があります。この措置により、イーサリアム全体（コンセンサス層と実行層を含む）が同一のコードロジックを用いてデータアクセスと解析を行うことが保証されます。

現状から目標への進化の道筋

シンプルさは多くの面で分散化と類似しており、両者はシステムのレジリエンスを実現するための基本的な前提条件です。シンプルさを核心的な価値として明確にするには、文化的な変化が必要です：その利益は即座には現れにくく、複雑な機能を追求することによる短期的な利益は明らかです。しかし、時間が経つにつれて、シンプルさの利点はますます顕著になります------ビットコインの発展の歴史はこの見解の強力な証拠です。

私は、イーサリアムプロトコル設計がTinyGradプロジェクトの実践経験を参考にし、長期的なイーサリアム規範のために明確なコード行数の上限目標を設定し、イーサリアムのコンセンサスの重要なコードのシンプルさをビットコインのレベルに近づけることを提案します。具体的には、イーサリアムの歴史的ルールを処理する関連コードは引き続き保持できますが、必ずコンセンサスの重要なパスから厳格に隔離し、その影響をコアコンセンサスロジックに与えないようにします。また、技術的なソリューションの選択においては、「よりシンプルなソリューションを優先する」という設計理念を貫徹し、複雑性をカプセル化することを優先し、システム全体の複雑性を拡散させないようにし、すべての設計決定が明確で検証可能な特性と保証を提供できるようにし、全体としてシンプルさを重視した技術文化を形成することを目指します。