原文タイトル：L1の簡素化
文:ヴィタリック
コンパイル:lenaxin、ChainCatcher
イーサリアムは、文明の資産や記録を保管するためのプラットフォームであり、金融、ガバナンス、高価値データの認証などの基礎レイヤーとして、世界の台帳となることを目指しています。 これには、スケーラビリティとレジリエンスという 2 つの条件が必要です。 フサカハードフォークは、レイヤー2(L2)データの利用可能なスペースを10倍に増やすことを目指しており、現在の2026年のロードマップでは、レイヤー1(L1)の大幅な拡張が求められています。 同時に、イーサリアムは合併を完了し、プルーフオブステークにアップグレードされ、クライアントの多様性が急速に増加し、ZK検証可能性の検証可能性と反量子コンピューティング機能に関する作業も進んでおり、さまざまなアプリケーションがより堅牢になりました。
本稿は、レジリエンス（最終的にはスケーラビリティにも影響を与える）に関する一つの側面、すなわちプロトコルのシンプルさに焦点を当てることを目的としています。この側面は同様に重要ですが、過小評価されがちです。
ビットコインの大きな利点は、そのプロトコルが非常にシンプルで美しいことです。
ブロックチェーンは一連のブロックで構成されており、各ブロックはハッシュによって前のブロックに接続されています。 ブロックの有効性は、プルーフ・オブ・ワーク・メカニズム、つまりハッシュ値の最初の数桁がゼロであることを検証するメカニズムによって検証されます。 各ブロックには、マイニングされたコインまたは以前のトランザクションの出力から派生したコインを消費する多数のトランザクションが含まれています。 これがビットコインプロトコルのコアメカニズムがあるところです。 聡明な中学生でもこのプロトコルを完全に理解でき、プログラマーはアマチュアプロジェクトとしてクライアントを書くことさえできます。
プロトコルの簡潔さは、ビットコインやイーサリアムが世界的に認識された中立的な基盤層となるための重要な利点を提供します：
シンプルなプロトコルは分析しやすく、より多くの参加者がプロトコルの研究、開発、ガバナンスに参加することを促進し、技術的な独占リスクを低減します。
簡略化されたプロトコル構造は、新しいインフラストラクチャ（クライアント、証明者、ログツール、およびその他の開発ツール）との統合に要する開発投資を大幅に削減します。
協定のシンプルなデザインは、長期的な維持コストを効果的に削減します。
プロトコルの仕様とその実装における重大な脆弱性リスクが大幅に減少し、システムの安全性を検証しやすくなります。
攻撃面の削減：コンポーネントの簡素化により、特定の利益の浸透に対する防御が容易になり、全体的なセキュリティが向上します。
歴史的に見て、イーサリアムはプロトコル設計においてしばしばシンプルさの原則を貫けませんでした（その一因は私自身の決定に起因します）。これが直接的に開発コストの高止まり、安全上のリスクの頻発、そして開発文化の閉鎖性を引き起こしています。これらの問題の根本的な原因は、実践で無効が証明されている短期的利益を追求することにあります。本稿では、今後5年間でイーサリアムがビットコインに近いプロトコルのシンプルさを実現する方法について説明します。
簡略化コンセンサス層
3sf - mini（イーサリアムテストネットのコードネーム）における3つのタイムスロットの最終性をシミュレーションする
新しいコンセンサスレイヤーの提案（以前は「光束チェーン」と呼ばれていた）は、過去10年間のコンセンサス理論、ゼロ知識証明（ZK-SNARK）、ステーキング経済学などの研究成果を融合させ、イーサリアムのために長期的な発展を見据えた最適なコンセンサスメカニズムを構築することを目的としています。既存のビーコンサインチェーンと比較して、この提案は著しく簡素化された特性を有しており、具体的には以下の点において表れています：
3スロット最終性（3-slot finality）アーキテクチャの革新：独立したスロット（slot）とエポック（epoch）の概念区分を排除し、委員会のローテーションメカニズムや同期委員会などの複雑なコンポーネントを廃止し、プロトコル仕様を大幅に簡素化しました。コア実装は約200行のコードで、Gasperプロトコルに対してセキュリティ面でほぼ最適なレベルに達しています。
検証ノード管理の最適化：アクティブな検証ノードの数を制限することにより、分岐選択ルール（fork choice rule）のより簡素な実装を採用できるようになり、システムの安全性を確保します。
アグリゲーションプロトコルのアップグレード：STARKに基づくアグリゲーションメカニズムは、任意のノードがアグリゲーターの役割を担うことを許可し、アグリゲーターへの信頼依存とビットフィールドのリソース浪費の問題を回避します。アグリゲーション暗号学自体は複雑ですが、その高度にカプセル化された特性は、システミックリスクを著しく低下させます。
P2Pネットワークアーキテクチャの改善：上記の2つの最適化は、よりシンプルで効率的なピアツーピアネットワークアーキテクチャの構築を可能にしました。
検証プロセスの再構築：検証ノードの参加、退出、引き出し、キー移行、怠惰な罰則などのメカニズムを再設計し、コード量を減らしつつ、コアパラメータ（弱い主観的周期など）の保証メカニズムを明確にする。
技術的な利点：コンセンサス層とEVM実行層の相対的なデカップリング特性は、継続的な最適化により大きな技術的スペースを提供します。それに対して、実行層の同様の改善はより大きな課題に直面しています。
実行レイヤーの簡素化
イーサリアム仮想マシン(EVM)の複雑さは増大し続けており、これらの複雑な設計の多くは不必要であることが証明されています(そして多くの場合、私の間違いでもあります)。 また、実際の使用量が極端に少ない単一のユースケース向けに過剰に設計されたプリコンパイル済みコントラクト。
既存の問題を零細な修正で解決しようとする試みはもはや機能しない。SELFDESTRUCTオペコードを削除するのに巨額の労力を費やしたが、得られた利益は限られている。最近のEOFに関する議論は、仮想マシンに対する段階的な変更の困難さをさらに浮き彫りにしている。
代替案として、私は最近、より攻撃的な転換パスを提案しました：中程度の規模（しかし依然として破壊的な）な変更を行って1.5倍の性能向上を得るくらいなら、全く新しく、著しく優れた仮想マシンアーキテクチャに直接移行し、100倍の性能飛躍を実現する方が良いでしょう。合併（The Merge）と同様に、私たちは破壊的な変更の回数を減らしつつ、各変更の戦略的価値を高めます。具体的には、RISC-VアーキテクチャまたはイーサリアムのZK証明プログラムで使用される仮想マシンを既存のEVMの代わりに採用することを提案します。この転換により、
効率革命的な向上：ZK証明環境では、スマートコントラクトがターゲットアーキテクチャ上で直接実行でき、インタプリタのオーバーヘッドが不要です。簡潔なデータは、ほとんどのシナリオで性能が100倍以上向上することを示しています。
アーキテクチャの極限の簡素化：RISC-V 規格は EVM に比べて非常に簡素であり、他の候補ソリューション（Cairo など）も同様にシンプルな特性を持っています。
EOFのコアの利点を引き継ぐ：コードセグメント管理、よりフレンドリーな静的分析サポート、そしてより大きなコード容量制限が含まれます。
開発者ツールチェーンの拡張：SolidityとVyperは新しいアーキテクチャへのバックエンドコンパイルサポートを追加することで可能になります。RISC-Vを選択した場合、主流言語の開発者は既存のコードを直接移植できます。
プリコンパイル契約の最適化：ほとんどのプリコンパイル機能は不要となり、高度に最適化された楕円曲線演算のみが保持されます（量子コンピュータの進展により淘汰される可能性があります）。
主な課題は、即座に実施可能なEOFソリューションとは異なり、新しい仮想マシンは開発者に利益をもたらすまでにより長い時間が必要であるということです。一部の高価値なEVMの改善（契約コードサイズ制限の引き上げ、DUP/SWAP命令セットの最適化など）を同期して実施することで、短期的な移行策として利用可能です。
この移行は、仮想マシンアーキテクチャを大幅に簡素化します。核心の問題は、既存のEVMエコシステムをどのように適切に扱うかです。
仮想マシンの移行における後方互換性の戦略
EVMの任意の部分を簡素化（または最適化して複雑さを増加させない）する最大の課題は、期待される目標を達成することと、既存のアプリケーションの後方互換性を維持することのバランスを取る方法です。
まず明確にする必要があるのは、単一のクライアントに対しても「イーサリアムコードベース」を定義する唯一の基準は存在しないということです。
目標は緑の領域を最小化することです：すなわち、ノードはEthereumコンセンサスに参加するために必要なロジックを実行し、現在の状態を計算し、証明を生成・検証し、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つのアプリケーションシーン：
データ可用性サンプリング：クライアントがブロックが公開されたかどうかを検証する際に、エラーチェックコードを使用してデータの完全性を確保する必要があります。
効率的なP2Pブロードキャスト：ノードはn個のシャードのうちn/2個を受信した時点でブロックを確認でき、遅延低下と冗長性の最適なバランスを実現します。
分散型履歴ストレージ：イーサリアムの履歴データは複数のデータブロックに分割され、次の条件を満たします：
各データブロックは独立して検証できます
任意のグループで n/2 のデータブロックを使用すれば、残りの n/2 のデータブロックを復元できます。
この設計は、単一のデータ損失リスクを大幅に低減します。
以下の3つのシナリオで同じ誤り訂正符号（リード・ソロモン符号、ランダム線形符号など）を使用すると、顕著な利点が得られます：
コードの簡素化；
効率の向上：ノードが特定のシナリオのためにシャーディングデータ（完全なブロックではなく）をダウンロードする必要がある場合、そのデータは他のシナリオで直接使用でき、重複した転送を避けることができます；
すべてのシーンのデータブロックは、ルートハッシュを使用して一元的に検証できます。
異なるエラー訂正符号を使用する場合、互換性の要件を満たす必要があります：例えば、データ可用性サンプリング（DAS）シャーディングでは、横方向のリード・ソロモン符号と縦方向のランダム線形符号を同時に使用できますが、両方の符号は同じ有限体に基づいて計算する必要があります。
統一シリアル化フォーマット
現在のイーサリアムのシリアライズ形式は、まだ半準拠の状態にあります——データは任意の形式に再シリアライズされ、伝播されることができます。唯一の例外は、トランザクション署名ハッシュであり、このシナリオではハッシュの一貫性を確保するために標準形式を採用する必要があります。しかし、将来的には、シリアライズ形式の準拠度がさらに強化されるでしょう。その主な理由は以下の通りです：
アカウントの抽象化（EIP-7701）：完全な取引内容は仮想マシン（VM）に完全に可視化されます
高 Gas 制限シナリオ：ブロック Gas 上限が引き上げられるにつれて、実行層データは blob 構造に保存する必要があります。
上記の変化が発生したとき、私たちはこの機会を利用して、Ethereumの3つの重要なレイヤーのシリアライズ標準を統一することができます：（i）実行レイヤー（ii）コンセンサスレイヤー（iii）スマートコントラクト呼び出しABI
SSZ シリアライズ形式の採用をお勧めします。SSZ は以下の利点があります：
効率的なデコードが可能であり、スマートコントラクトを含むシナリオはすべて、4バイトの設計と少ない境界条件処理のおかげで迅速にデコードできます。
コンセンサス層は広く応用されており、コンセンサス層で深い統合を実現しています。
既存のABIに非常に似ており、ツールチェーンの適応とアップグレードが容易です。
現在、関連技術チームがSSZの全面移行作業を進めています。今後のアップグレード計画において、この技術路線を継続し、既存の成果に基づいて拡張することを提案します。
統一された共有ツリー構造
EVMからRISC-V（または他の簡素な仮想マシンアーキテクチャ）に移行すると、六叉Merkle Patriciaツリーがブロック実行証明の最大のパフォーマンスボトルネックとなります（通常のシナリオでもそうです）。より優れたハッシュ関数に基づく二分木構造に移行することで、証明の効率が大幅に向上し、軽ノードや他のアプリケーションシナリオのデータストレージコストが削減されます。
移行を実施する際には、コンセンサス層と実行層の統一を実現するために、同じツリー構造を同期して採用する必要があります。この措置により、Ethereumのフルスタック（コンセンサス層と実行層を含む）が同一のコードロジックを使用してデータアクセスと解析を行うことが保証されます。
現状から目標への進化の道筋
シンプルさは多くの面で分散化と類似性を持ち、両者はシステムの弾力性を実現するための基本的な前提条件です。シンプルさを核心的な価値として明確に位置づけるには、文化的な変化が必要です。その利益はしばしば即座には現れず、複雑な機能を追求することによる短期的な利益は明らかです。しかし、時間が経つにつれて、シンプルさの利点はますます顕著になります。ビットコインの発展の歴史はこの見解を強く裏付けています。
私は、Ethereumプロトコルの設計に関してTinyGradプロジェクトの実践経験を参考にし、長期的なEthereumの規範に明確なコード行数上限目標を設定することを提案します。これにより、Ethereumのコンセンサスにおける重要なコードの簡潔さをBitcoinレベルに近づけることを目指します。具体的には、Ethereumの歴史的ルールに関連するコードは引き続き保持できますが、必ずコンセンサスの重要なパスから厳格に隔離され、コアコンセンサスロジックに影響を与えないようにしなければなりません。また、技術的な選択肢においては「よりシンプルなソリューションを優先する」という設計理念を貫くべきであり、複雑さを封じ込めることを優先し、システム的な複雑さを広げないようにしなければなりません。そして、すべての設計上の決定が明確で検証可能な特性と保証を提供できるようにし、全体として簡潔性を重視した技術文化を形成することが求められます。
229k 投稿
197k 投稿
146k 投稿
79k 投稿
66k 投稿
63k 投稿
61k 投稿
58k 投稿
52k 投稿
51k 投稿
Vitalik の新しい文：イーサリアムはどのようにビットコインに対して簡素化されたアーキテクチャを実現するのか？
原文タイトル：L1の簡素化
文:ヴィタリック
コンパイル:lenaxin、ChainCatcher
イーサリアムは、文明の資産や記録を保管するためのプラットフォームであり、金融、ガバナンス、高価値データの認証などの基礎レイヤーとして、世界の台帳となることを目指しています。 これには、スケーラビリティとレジリエンスという 2 つの条件が必要です。 フサカハードフォークは、レイヤー2(L2)データの利用可能なスペースを10倍に増やすことを目指しており、現在の2026年のロードマップでは、レイヤー1(L1)の大幅な拡張が求められています。 同時に、イーサリアムは合併を完了し、プルーフオブステークにアップグレードされ、クライアントの多様性が急速に増加し、ZK検証可能性の検証可能性と反量子コンピューティング機能に関する作業も進んでおり、さまざまなアプリケーションがより堅牢になりました。
本稿は、レジリエンス（最終的にはスケーラビリティにも影響を与える）に関する一つの側面、すなわちプロトコルのシンプルさに焦点を当てることを目的としています。この側面は同様に重要ですが、過小評価されがちです。
ビットコインの大きな利点は、そのプロトコルが非常にシンプルで美しいことです。
ブロックチェーンは一連のブロックで構成されており、各ブロックはハッシュによって前のブロックに接続されています。 ブロックの有効性は、プルーフ・オブ・ワーク・メカニズム、つまりハッシュ値の最初の数桁がゼロであることを検証するメカニズムによって検証されます。 各ブロックには、マイニングされたコインまたは以前のトランザクションの出力から派生したコインを消費する多数のトランザクションが含まれています。 これがビットコインプロトコルのコアメカニズムがあるところです。 聡明な中学生でもこのプロトコルを完全に理解でき、プログラマーはアマチュアプロジェクトとしてクライアントを書くことさえできます。
プロトコルの簡潔さは、ビットコインやイーサリアムが世界的に認識された中立的な基盤層となるための重要な利点を提供します：
シンプルなプロトコルは分析しやすく、より多くの参加者がプロトコルの研究、開発、ガバナンスに参加することを促進し、技術的な独占リスクを低減します。
簡略化されたプロトコル構造は、新しいインフラストラクチャ（クライアント、証明者、ログツール、およびその他の開発ツール）との統合に要する開発投資を大幅に削減します。
協定のシンプルなデザインは、長期的な維持コストを効果的に削減します。
プロトコルの仕様とその実装における重大な脆弱性リスクが大幅に減少し、システムの安全性を検証しやすくなります。
攻撃面の削減：コンポーネントの簡素化により、特定の利益の浸透に対する防御が容易になり、全体的なセキュリティが向上します。
歴史的に見て、イーサリアムはプロトコル設計においてしばしばシンプルさの原則を貫けませんでした（その一因は私自身の決定に起因します）。これが直接的に開発コストの高止まり、安全上のリスクの頻発、そして開発文化の閉鎖性を引き起こしています。これらの問題の根本的な原因は、実践で無効が証明されている短期的利益を追求することにあります。本稿では、今後5年間でイーサリアムがビットコインに近いプロトコルのシンプルさを実現する方法について説明します。
簡略化コンセンサス層
3sf - mini（イーサリアムテストネットのコードネーム）における3つのタイムスロットの最終性をシミュレーションする
新しいコンセンサスレイヤーの提案（以前は「光束チェーン」と呼ばれていた）は、過去10年間のコンセンサス理論、ゼロ知識証明（ZK-SNARK）、ステーキング経済学などの研究成果を融合させ、イーサリアムのために長期的な発展を見据えた最適なコンセンサスメカニズムを構築することを目的としています。既存のビーコンサインチェーンと比較して、この提案は著しく簡素化された特性を有しており、具体的には以下の点において表れています：
3スロット最終性（3-slot finality）アーキテクチャの革新：独立したスロット（slot）とエポック（epoch）の概念区分を排除し、委員会のローテーションメカニズムや同期委員会などの複雑なコンポーネントを廃止し、プロトコル仕様を大幅に簡素化しました。コア実装は約200行のコードで、Gasperプロトコルに対してセキュリティ面でほぼ最適なレベルに達しています。
検証ノード管理の最適化：アクティブな検証ノードの数を制限することにより、分岐選択ルール（fork choice rule）のより簡素な実装を採用できるようになり、システムの安全性を確保します。
アグリゲーションプロトコルのアップグレード：STARKに基づくアグリゲーションメカニズムは、任意のノードがアグリゲーターの役割を担うことを許可し、アグリゲーターへの信頼依存とビットフィールドのリソース浪費の問題を回避します。アグリゲーション暗号学自体は複雑ですが、その高度にカプセル化された特性は、システミックリスクを著しく低下させます。
P2Pネットワークアーキテクチャの改善：上記の2つの最適化は、よりシンプルで効率的なピアツーピアネットワークアーキテクチャの構築を可能にしました。
検証プロセスの再構築：検証ノードの参加、退出、引き出し、キー移行、怠惰な罰則などのメカニズムを再設計し、コード量を減らしつつ、コアパラメータ（弱い主観的周期など）の保証メカニズムを明確にする。
技術的な利点：コンセンサス層とEVM実行層の相対的なデカップリング特性は、継続的な最適化により大きな技術的スペースを提供します。それに対して、実行層の同様の改善はより大きな課題に直面しています。
実行レイヤーの簡素化
イーサリアム仮想マシン(EVM)の複雑さは増大し続けており、これらの複雑な設計の多くは不必要であることが証明されています(そして多くの場合、私の間違いでもあります)。 また、実際の使用量が極端に少ない単一のユースケース向けに過剰に設計されたプリコンパイル済みコントラクト。
既存の問題を零細な修正で解決しようとする試みはもはや機能しない。SELFDESTRUCTオペコードを削除するのに巨額の労力を費やしたが、得られた利益は限られている。最近のEOFに関する議論は、仮想マシンに対する段階的な変更の困難さをさらに浮き彫りにしている。
代替案として、私は最近、より攻撃的な転換パスを提案しました：中程度の規模（しかし依然として破壊的な）な変更を行って1.5倍の性能向上を得るくらいなら、全く新しく、著しく優れた仮想マシンアーキテクチャに直接移行し、100倍の性能飛躍を実現する方が良いでしょう。合併（The Merge）と同様に、私たちは破壊的な変更の回数を減らしつつ、各変更の戦略的価値を高めます。具体的には、RISC-VアーキテクチャまたはイーサリアムのZK証明プログラムで使用される仮想マシンを既存のEVMの代わりに採用することを提案します。この転換により、
効率革命的な向上：ZK証明環境では、スマートコントラクトがターゲットアーキテクチャ上で直接実行でき、インタプリタのオーバーヘッドが不要です。簡潔なデータは、ほとんどのシナリオで性能が100倍以上向上することを示しています。
アーキテクチャの極限の簡素化：RISC-V 規格は EVM に比べて非常に簡素であり、他の候補ソリューション（Cairo など）も同様にシンプルな特性を持っています。
EOFのコアの利点を引き継ぐ：コードセグメント管理、よりフレンドリーな静的分析サポート、そしてより大きなコード容量制限が含まれます。
開発者ツールチェーンの拡張：SolidityとVyperは新しいアーキテクチャへのバックエンドコンパイルサポートを追加することで可能になります。RISC-Vを選択した場合、主流言語の開発者は既存のコードを直接移植できます。
プリコンパイル契約の最適化：ほとんどのプリコンパイル機能は不要となり、高度に最適化された楕円曲線演算のみが保持されます（量子コンピュータの進展により淘汰される可能性があります）。
主な課題は、即座に実施可能なEOFソリューションとは異なり、新しい仮想マシンは開発者に利益をもたらすまでにより長い時間が必要であるということです。一部の高価値なEVMの改善（契約コードサイズ制限の引き上げ、DUP/SWAP命令セットの最適化など）を同期して実施することで、短期的な移行策として利用可能です。
この移行は、仮想マシンアーキテクチャを大幅に簡素化します。核心の問題は、既存のEVMエコシステムをどのように適切に扱うかです。
仮想マシンの移行における後方互換性の戦略
EVMの任意の部分を簡素化（または最適化して複雑さを増加させない）する最大の課題は、期待される目標を達成することと、既存のアプリケーションの後方互換性を維持することのバランスを取る方法です。
まず明確にする必要があるのは、単一のクライアントに対しても「イーサリアムコードベース」を定義する唯一の基準は存在しないということです。
目標は緑の領域を最小化することです：すなわち、ノードはEthereumコンセンサスに参加するために必要なロジックを実行し、現在の状態を計算し、証明を生成・検証し、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つのアプリケーションシーン：
データ可用性サンプリング：クライアントがブロックが公開されたかどうかを検証する際に、エラーチェックコードを使用してデータの完全性を確保する必要があります。
効率的なP2Pブロードキャスト：ノードはn個のシャードのうちn/2個を受信した時点でブロックを確認でき、遅延低下と冗長性の最適なバランスを実現します。
分散型履歴ストレージ：イーサリアムの履歴データは複数のデータブロックに分割され、次の条件を満たします：
各データブロックは独立して検証できます
任意のグループで n/2 のデータブロックを使用すれば、残りの n/2 のデータブロックを復元できます。
この設計は、単一のデータ損失リスクを大幅に低減します。
以下の3つのシナリオで同じ誤り訂正符号（リード・ソロモン符号、ランダム線形符号など）を使用すると、顕著な利点が得られます：
コードの簡素化；
効率の向上：ノードが特定のシナリオのためにシャーディングデータ（完全なブロックではなく）をダウンロードする必要がある場合、そのデータは他のシナリオで直接使用でき、重複した転送を避けることができます；
すべてのシーンのデータブロックは、ルートハッシュを使用して一元的に検証できます。
異なるエラー訂正符号を使用する場合、互換性の要件を満たす必要があります：例えば、データ可用性サンプリング（DAS）シャーディングでは、横方向のリード・ソロモン符号と縦方向のランダム線形符号を同時に使用できますが、両方の符号は同じ有限体に基づいて計算する必要があります。
統一シリアル化フォーマット
現在のイーサリアムのシリアライズ形式は、まだ半準拠の状態にあります——データは任意の形式に再シリアライズされ、伝播されることができます。唯一の例外は、トランザクション署名ハッシュであり、このシナリオではハッシュの一貫性を確保するために標準形式を採用する必要があります。しかし、将来的には、シリアライズ形式の準拠度がさらに強化されるでしょう。その主な理由は以下の通りです：
アカウントの抽象化（EIP-7701）：完全な取引内容は仮想マシン（VM）に完全に可視化されます
高 Gas 制限シナリオ：ブロック Gas 上限が引き上げられるにつれて、実行層データは blob 構造に保存する必要があります。
上記の変化が発生したとき、私たちはこの機会を利用して、Ethereumの3つの重要なレイヤーのシリアライズ標準を統一することができます：（i）実行レイヤー（ii）コンセンサスレイヤー（iii）スマートコントラクト呼び出しABI
SSZ シリアライズ形式の採用をお勧めします。SSZ は以下の利点があります：
効率的なデコードが可能であり、スマートコントラクトを含むシナリオはすべて、4バイトの設計と少ない境界条件処理のおかげで迅速にデコードできます。
コンセンサス層は広く応用されており、コンセンサス層で深い統合を実現しています。
既存のABIに非常に似ており、ツールチェーンの適応とアップグレードが容易です。
現在、関連技術チームがSSZの全面移行作業を進めています。今後のアップグレード計画において、この技術路線を継続し、既存の成果に基づいて拡張することを提案します。
統一された共有ツリー構造
EVMからRISC-V（または他の簡素な仮想マシンアーキテクチャ）に移行すると、六叉Merkle Patriciaツリーがブロック実行証明の最大のパフォーマンスボトルネックとなります（通常のシナリオでもそうです）。より優れたハッシュ関数に基づく二分木構造に移行することで、証明の効率が大幅に向上し、軽ノードや他のアプリケーションシナリオのデータストレージコストが削減されます。
移行を実施する際には、コンセンサス層と実行層の統一を実現するために、同じツリー構造を同期して採用する必要があります。この措置により、Ethereumのフルスタック（コンセンサス層と実行層を含む）が同一のコードロジックを使用してデータアクセスと解析を行うことが保証されます。
現状から目標への進化の道筋
シンプルさは多くの面で分散化と類似性を持ち、両者はシステムの弾力性を実現するための基本的な前提条件です。シンプルさを核心的な価値として明確に位置づけるには、文化的な変化が必要です。その利益はしばしば即座には現れず、複雑な機能を追求することによる短期的な利益は明らかです。しかし、時間が経つにつれて、シンプルさの利点はますます顕著になります。ビットコインの発展の歴史はこの見解を強く裏付けています。
私は、Ethereumプロトコルの設計に関してTinyGradプロジェクトの実践経験を参考にし、長期的なEthereumの規範に明確なコード行数上限目標を設定することを提案します。これにより、Ethereumのコンセンサスにおける重要なコードの簡潔さをBitcoinレベルに近づけることを目指します。具体的には、Ethereumの歴史的ルールに関連するコードは引き続き保持できますが、必ずコンセンサスの重要なパスから厳格に隔離され、コアコンセンサスロジックに影響を与えないようにしなければなりません。また、技術的な選択肢においては「よりシンプルなソリューションを優先する」という設計理念を貫くべきであり、複雑さを封じ込めることを優先し、システム的な複雑さを広げないようにしなければなりません。そして、すべての設計上の決定が明確で検証可能な特性と保証を提供できるようにし、全体として簡潔性を重視した技術文化を形成することが求められます。