著者 | ヴィタリック・ブテリン編纂 | GaryMa ウーはブロックチェーンについて語った原文リンク：概要イーサリアムはグローバル台帳を目指しており、スケーラビリティとレジリエンスが必要です。 このホワイトペーパーでは、プロトコルのシンプルさの重要性に焦点を当て、コンセンサスレイヤー(3スロットファイナリティ、STARKアグリゲーション)と実行レイヤー(EVMをRISC-Vまたは同様の仮想マシンに置き換える)を簡素化することで、複雑さ、開発コスト、エラーリスク、および攻撃対象領域を劇的に削減することを提案しています。 オンチェーンEVMインタープリターなどの下位互換性戦略への移行をスムーズにし、イレイジャーコーディング、シリアル化形式(SSZ)、ツリー構造を統一してさらに簡素化することをお勧めします。 目標は、イーサリアムコンセンサスの主要なコードをビットコインのシンプルさに近づけ、レジリエンスとエンゲージメントを向上させ、シンプルさとコードゴールの最大行数に文化的な焦点を当てることです。イーサリアムの目標は、グローバルな台帳となることです：人類文明の資産と記録を保存するプラットフォームであり、金融、ガバナンス、高価値データ認証などの分野にサービスを提供します。これには2つの側面のサポートが必要です：スケーラビリティとレジリエンス。Fusaka ハードフォーク計画は、L2 データの利用可能なスペースを 10 倍に増加させ、現在提案されている 2026 年のロードマップも L1 レイヤーに類似の大幅な向上をもたらすことを計画しています。同時に、イーサリアムはステーク証明（PoS）への移行を完了し、クライアントの多様性が急速に向上し、ゼロ知識（ZK）検証や量子耐性研究も着実に進展しており、アプリケーションエコシステムはますます堅実になっています。この記事は、同様に重要でありながら過小評価されがちなレジリエンス（さらにはスケーラビリティ）の要素、すなわちプロトコルの単純さに焦点を当てることを目的としています。ビットコインプロトコルの最も驚くべき点は、その優雅なシンプルさです：1. ブロックから構成されるチェーンが存在し、各ブロックはハッシュによって前のブロックに接続されています。2. ブロックの有効性は、プルーフ・オブ・ワーク（PoW）によって検証され、ハッシュ値の最初の数桁がゼロであるかどうかを確認します。3. 各ブロックにはトランザクションが含まれており、トランザクションで使われるコインは、マイニング報酬から来るか、以前のトランザクションの出力から来ます。それだけです！賢い高校生でもビットコインプロトコルの動作を完全に理解でき、プログラマーであれば趣味のプロジェクトとしてクライアントを作成することさえできます。協約のシンプルさは、ビットコイン（およびイーサリアム）が信頼できる中立的なグローバル基盤層になるための多くの重要な利点をもたらしました：1. 理解しやすい：プロトコルの複雑性を減らし、より多くの人々がプロトコルの研究、開発、ガバナンスに参加できるようにし、技術的エリート層による支配のリスクを減少させる。2. 開発コストの削減：プロトコルの簡素化により、新しいインフラストラクチャ（新しいクライアント、証明者、開発者ツールなど）の作成コストを大幅に削減します。3. メンテナンスの負担を軽減する：長期契約の維持コストを削減する。4. エラーのリスクを減少させる：プロトコルの仕様および実装における致命的なエラーの可能性を低下させ、同時にそのようなエラーが存在しないことを検証しやすくする。5. 攻撃面の縮小：プロトコルの複雑なコンポーネントを減少させ、特定の利益団体による攻撃のリスクを低減します。歴史的に、イーサリアムは（私の個人的な決定によることもありますが）しばしばシンプルさを維持できず、その結果、開発コストが高まり、安全リスクが増加し、研究開発文化が閉鎖的になりました。そして、これらの複雑さを追求することで得られる利益は、しばしば幻想であることが証明されています。本稿では、5年後のイーサリアムがビットコインのシンプルさにどのように近づくかを探ります。簡素化されたコンセンサスレイヤ新しいコンセンサスレイヤーの設計（歴史的に「ビーコンサイン」と呼ばれる）は、過去10年間のコンセンサス理論、ZK-SNARKの開発、ステーキングエコノミクスなどの経験を活用して、長期的に最適でよりシンプルなコンセンサスレイヤーを構築することを目的としています。既存のビーコンサインと比較して、新しい設計は大幅に簡素化されています：1. 3スロット最終設計：スロット、エポック、委員会再編成などの概念と、それに関連する効率的な処理メカニズム（例えば、同期委員会）を除去します。3スロット最終性の基本実装は約200行のコードで実現でき、Gasperと比較して安全性はほぼ最適です。2. アクティブなバリデーターの数を減らす：よりシンプルなフォーク選択ルールの実装を許可し、安全性を強化します。3. STARKに基づく集約プロトコル：誰でも集約者になれるが、集約者を信頼したり、重複したビットフィールドに高額な料金を支払う必要はありません。集約暗号学の複雑さは高いですが、その複雑さは高度にカプセル化されており、システムリスクは低いです。4. P2Pアーキテクチャの簡素化：上記の要因は、よりシンプルで堅牢なピアツーピアネットワークアーキテクチャをサポートする可能性があります。5. バリデーター機構の再設計：参加、退出、出金、鍵の変換、非活動リークなどのメカニズムを含み、コード行数を簡素化し、より明確な保証を提供します（例：弱い主観的周期）。コンセンサス層の利点は、EVM実行層と相対的に独立しているため、継続的な改善のための大きなスペースがあることです。より大きな課題は、実行層で類似の簡素化をどのように実現するかです。実行レイヤーの簡素化EVMの複雑性はますます増加しており、多くの複雑性は無駄であることが証明されています（部分的には私の個人的な判断ミスによるものです）：256ビットの仮想マシンは、今や徐々に時代遅れとなっている特定の暗号形式を過剰に最適化しており、プリコンパイルは単一のユースケースに最適化されていますが、ほとんど使用されていません。これらの問題を一つずつ解決することは効果が限られています。例えば、SELFDESTRUCT オペコードを削除するための努力は膨大ですが、得られる利益はわずかです。最近の EOF（EVM オブジェクトフォーマット）に関する議論も同様の課題を示しています。最近、私はより攻撃的な提案をしました：EVMに中規模（しかし依然として破壊的な）変更を加えて1.5倍の利益を得るよりは、より優れた、よりシンプルな仮想マシンに移行して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とは異なり、新しい仮想マシンの利益が開発者に届くまでに時間がかかることです。私たちは、高価値のEVM改善（契約コードサイズ制限の増加、DUP/SWAP17–32のサポートなど）を短期的に実施することで、この問題を緩和できます。これにより、よりシンプルな仮想マシンが実現します。核心的な課題は、既存のEVMをどのように処理するかです。仮想マシンの移行に関する後方互換性ポリシーEVMを簡素化（または複雑さを増さずに改善する）する最大の課題は、目標の達成と既存アプリケーションの後方互換性とのバランスを取ることです。まず明確にする必要があります：イーサリアムのコードベース（単一のクライアント内でも）には、唯一の定義方法はありません。目標は緑の領域をできるだけ縮小することです：ノードがイーサリアムのコンセンサスに参加するために必要なロジックには、現在の状態の計算、証明、検証、FOCIL（フォーク選択ルール）、および「通常」のブロック構築が含まれます。オレンジ色の領域は減少できません：プロトコル仕様が特定の実行レイヤー機能（例えば、バーチャルマシン、プリコンパイルなど）を削除または変更した場合、過去のブロックを処理するクライアントは関連コードを保持する必要があります。しかし、新しいクライアント、ZK-EVM、または形式的証明器はオレンジ色の領域を完全に無視できます。新たに追加された黄色の領域：現在のチェーンの理解やブロック構築の最適化に非常に価値がありますが、合意の論理には含まれません。例えば、Etherscanや一部のブロック構築者はERC-4337ユーザー操作をサポートしています。もし私たちがオンチェーンRISC-V実装で特定のEthereum機能（例えばEOAおよびそのサポートする古いトランザクションタイプ）を置き換えれば、合意コードは大幅に簡素化されますが、専用ノードは依然として元のコードを使用して解析を行うかもしれません。オレンジと黄色の領域の複雑さは、複雑性をカプセル化するものであり、プロトコルを理解している人はこれらの部分をスキップできます。イーサリアムはそれらを無視でき、これらの領域のエラーはコンセンサスリスクを引き起こしません。したがって、オレンジと黄色の領域のコードの複雑さは、緑の領域の複雑さに比べてはるかに危険性が低いです。コードを緑の領域から黄色の領域に移す考え方は、AppleがRosetta翻訳レイヤーを通じて長期的な後方互換性を確保する戦略に似ています。Ipsilon チームの最近の記事に触発されて、以下の仮想マシン変更プロセスを提案します（EVM から RISC-V への例ですが、EVM から Cairo への、または RISC-V からより優れた仮想マシンへの場合にも適用可能です）：1. 新しいプリコンパイルにオンチェーンRISC-Vの実装を要求します：エコシステムがRISC-V仮想マシンに徐々に適応できるようにします。2. 開発者オプションとしてRISC-Vを導入：プロトコルはRISC-VとEVMの両方をサポートし、二つの仮想マシンのコントラクトは自由に相互作用できます。3. 大部分のプリコンパイルを置き換え：楕円曲線操作とKECCAK（極限の速度が必要なため）を除いて、RISC-Vを用いて他のプリコンパイルを置き換えます。ハードフォークを通じてプリコンパイルを削除し、そのアドレスのコード（DAOフォークに似たもの）を空からRISC-V実装に変更します。RISC-V仮想マシンは非常にシンプルであり、ここで止まってもプロトコルは大幅に簡素化されます。4. RISC-V に EVM インタプリタを実装する：スマートコントラクトをオンチェーンに（ZK プルーフが必要なため）。初期リリースから数年後、既存の EVM コントラクトはこのインタプリタを介して実行される。第4ステップが完了した後、多くの「EVM実装」がブロック構築、開発者ツール、チェーン分析の最適化に引き続き使用されるが、もはや重要な合意仕様の一部ではなくなる。イーサリアムの合意は「ネイティブに」RISC-Vのみを理解する。共有プロトコルコンポーネントの簡素化プロトコル全体の複雑さを低減する第三の方法（最も過小評価されがちでもある）は、プロトコルスタックの異なる部分で統一された標準をできるだけ共有することです。異なるプロトコルが異なるシーンで同じことを行うことは通常無益ですが、このようなパターンは依然としてよく見られます。これは主にプロトコルのロードマップの異なる部分がコミュニケーションを欠いているためです。以下は、コンポーネントを共有することでイーサリアムを簡素化する具体的な例です。統合イレイジャーコーディング私たちは3つのシーンでエラー訂正コードが必要です:1. データの可用性サンプリング：クライアントはブロックが公開されたことを検証します。2. より迅速なP2Pブロードキャスト：ノードはn/2のスニペットを受信した後、ブロックを受け入れることができ、遅延と冗長性のバランスを取ります。3. 分散型履歴ストレージ：イーサリアムの履歴データをシャーディングストレージし、各グループのn/2の断片が残りの断片を復元できるため、単一の断片喪失リスクを低減します。同じエラー訂正符号（Reed-Solomonやランダム線形符号など）を3つのシナリオで使用すると、以下の利点が得られます。1. コード量の最小化：総コード行数を減らす。2. 効率の向上：ノードがあるシーンの一部のスニペットをダウンロードする場合、これらのデータは他のシーンで使用できます。3. 検証可能性を確保する：すべてのシーンの断片はルートに基づいて検証可能です。異なる誤り訂正符号を使用する場合、データの可用性サンプリングの水平リード・ソロモン符号と垂直ランダム線形符号が同じ領域で動作することを少なくとも保証する必要があります。統一シリアル化フォーマットイーサリアムのシリアライズ形式は現在部分的に固定化されており、データは任意の形式で再シリアライズおよびブロードキャストできます。例外は取引の署名ハッシュで、規定の形式でハッシュ化する必要があります。将来的には、シリアライズ形式の固定化の程度が以下の理由によりさらに向上するでしょう：1. 完全なアカウント抽象（EIP-7701）：取引の完全な内容が仮想マシンに見える。2. より高いガス制限：実行層データはデータブロック（blob）に入れる必要があります。その時、私たちはイーサリアムの3つのレイヤーのシリアライズ形式を統一する機会があります：実行レイヤー、コンセンサスレイヤー、スマートコントラクト呼び出しABI。SSZの使用を提案します。なぜなら、SSZは：1. デコードが容易：スマートコントラクト内に含まれている（4バイトの設計と少ないエッジケースに基づいているため）。2. コンセンサス層で広く使用されています。3. 既存のABIに非常に似ている：ツールの適応が比較的簡単です。すでにSSZへの完全な移行に向けた努力が行われており、私たちは将来のアップグレードを計画する際にこれらの努力を考慮し、継続すべきです。統一されたツリー構造EVMからRISC-V（または他の選択可能な最小仮想マシン）に移行すると、16進数のMerkle Patriciaツリーがブロック実行の最大ボトルネックとなります。これは平均的なケースでも同様です。より優れたハッシュ関数に基づく二分木への移行は、証明器の効率を大幅に向上させ、ライトクライアントなどのシナリオでのデータコストを削減します。移行する際、コンセンサス層が同じツリー構造を使用していることを確認する必要があります。これにより、Ethereumのコンセンサス層と実行層は同じコードを通じてアクセスおよび解析できるようになります。今から未来へシンプルさは多くの面で分散化に似ており、両者はレジリエンスの目標の上流に位置しています。シンプルさを明確に重視するには、一定の文化的変化が必要です。その利益はしばしば定量化が難しく、追加の努力やいくつかの目を引く機能を放棄するコストは即座に明らかになります。しかし、時間が経つにつれて、利益はますます顕著になります — — ビットコイン自体がその優れた例です。私はtinygradに倣い、Ethereumの長期的な規範のために明確な最大コード行数の目標を設定することを提案します。これにより、Ethereumのコンセンサスの重要なコードがBitcoinのシンプルさに近づくことができます。Ethereumの歴史的ルールを扱うコードは引き続き存在しますが、コンセンサスの重要な経路の外に置かれるべきです。同時に、私たちはよりシンプルな解決策を選ぶ理念を持ち、システム的な複雑性ではなく複雑性のカプセル化を優先し、明確な属性と保証を提供する設計選択を行うべきです。
Vitalik のブログ：5 年後のイーサリアムをビットコインのようにシンプルにする方法
著者 | ヴィタリック・ブテリン
編纂 | GaryMa ウーはブロックチェーンについて語った
原文リンク：
概要
イーサリアムはグローバル台帳を目指しており、スケーラビリティとレジリエンスが必要です。 このホワイトペーパーでは、プロトコルのシンプルさの重要性に焦点を当て、コンセンサスレイヤー(3スロットファイナリティ、STARKアグリゲーション)と実行レイヤー(EVMをRISC-Vまたは同様の仮想マシンに置き換える)を簡素化することで、複雑さ、開発コスト、エラーリスク、および攻撃対象領域を劇的に削減することを提案しています。 オンチェーンEVMインタープリターなどの下位互換性戦略への移行をスムーズにし、イレイジャーコーディング、シリアル化形式(SSZ)、ツリー構造を統一してさらに簡素化することをお勧めします。 目標は、イーサリアムコンセンサスの主要なコードをビットコインのシンプルさに近づけ、レジリエンスとエンゲージメントを向上させ、シンプルさとコードゴールの最大行数に文化的な焦点を当てることです。
イーサリアムの目標は、グローバルな台帳となることです：人類文明の資産と記録を保存するプラットフォームであり、金融、ガバナンス、高価値データ認証などの分野にサービスを提供します。これには2つの側面のサポートが必要です：スケーラビリティとレジリエンス。Fusaka ハードフォーク計画は、L2 データの利用可能なスペースを 10 倍に増加させ、現在提案されている 2026 年のロードマップも L1 レイヤーに類似の大幅な向上をもたらすことを計画しています。同時に、イーサリアムはステーク証明（PoS）への移行を完了し、クライアントの多様性が急速に向上し、ゼロ知識（ZK）検証や量子耐性研究も着実に進展しており、アプリケーションエコシステムはますます堅実になっています。
この記事は、同様に重要でありながら過小評価されがちなレジリエンス（さらにはスケーラビリティ）の要素、すなわちプロトコルの単純さに焦点を当てることを目的としています。
ビットコインプロトコルの最も驚くべき点は、その優雅なシンプルさです：
ブロックから構成されるチェーンが存在し、各ブロックはハッシュによって前のブロックに接続されています。
ブロックの有効性は、プルーフ・オブ・ワーク（PoW）によって検証され、ハッシュ値の最初の数桁がゼロであるかどうかを確認します。
各ブロックにはトランザクションが含まれており、トランザクションで使われるコインは、マイニング報酬から来るか、以前のトランザクションの出力から来ます。
それだけです！賢い高校生でもビットコインプロトコルの動作を完全に理解でき、プログラマーであれば趣味のプロジェクトとしてクライアントを作成することさえできます。
協約のシンプルさは、ビットコイン（およびイーサリアム）が信頼できる中立的なグローバル基盤層になるための多くの重要な利点をもたらしました：
理解しやすい：プロトコルの複雑性を減らし、より多くの人々がプロトコルの研究、開発、ガバナンスに参加できるようにし、技術的エリート層による支配のリスクを減少させる。
開発コストの削減：プロトコルの簡素化により、新しいインフラストラクチャ（新しいクライアント、証明者、開発者ツールなど）の作成コストを大幅に削減します。
メンテナンスの負担を軽減する：長期契約の維持コストを削減する。
エラーのリスクを減少させる：プロトコルの仕様および実装における致命的なエラーの可能性を低下させ、同時にそのようなエラーが存在しないことを検証しやすくする。
攻撃面の縮小：プロトコルの複雑なコンポーネントを減少させ、特定の利益団体による攻撃のリスクを低減します。
歴史的に、イーサリアムは（私の個人的な決定によることもありますが）しばしばシンプルさを維持できず、その結果、開発コストが高まり、安全リスクが増加し、研究開発文化が閉鎖的になりました。そして、これらの複雑さを追求することで得られる利益は、しばしば幻想であることが証明されています。本稿では、5年後のイーサリアムがビットコインのシンプルさにどのように近づくかを探ります。
簡素化されたコンセンサスレイヤ
新しいコンセンサスレイヤーの設計（歴史的に「ビーコンサイン」と呼ばれる）は、過去10年間のコンセンサス理論、ZK-SNARKの開発、ステーキングエコノミクスなどの経験を活用して、長期的に最適でよりシンプルなコンセンサスレイヤーを構築することを目的としています。既存のビーコンサインと比較して、新しい設計は大幅に簡素化されています：
3スロット最終設計：スロット、エポック、委員会再編成などの概念と、それに関連する効率的な処理メカニズム（例えば、同期委員会）を除去します。3スロット最終性の基本実装は約200行のコードで実現でき、Gasperと比較して安全性はほぼ最適です。
アクティブなバリデーターの数を減らす：よりシンプルなフォーク選択ルールの実装を許可し、安全性を強化します。
STARKに基づく集約プロトコル：誰でも集約者になれるが、集約者を信頼したり、重複したビットフィールドに高額な料金を支払う必要はありません。集約暗号学の複雑さは高いですが、その複雑さは高度にカプセル化されており、システムリスクは低いです。
P2Pアーキテクチャの簡素化：上記の要因は、よりシンプルで堅牢なピアツーピアネットワークアーキテクチャをサポートする可能性があります。
バリデーター機構の再設計：参加、退出、出金、鍵の変換、非活動リークなどのメカニズムを含み、コード行数を簡素化し、より明確な保証を提供します（例：弱い主観的周期）。
コンセンサス層の利点は、EVM実行層と相対的に独立しているため、継続的な改善のための大きなスペースがあることです。より大きな課題は、実行層で類似の簡素化をどのように実現するかです。
実行レイヤーの簡素化
EVMの複雑性はますます増加しており、多くの複雑性は無駄であることが証明されています（部分的には私の個人的な判断ミスによるものです）：256ビットの仮想マシンは、今や徐々に時代遅れとなっている特定の暗号形式を過剰に最適化しており、プリコンパイルは単一のユースケースに最適化されていますが、ほとんど使用されていません。
これらの問題を一つずつ解決することは効果が限られています。例えば、SELFDESTRUCT オペコードを削除するための努力は膨大ですが、得られる利益はわずかです。最近の EOF（EVM オブジェクトフォーマット）に関する議論も同様の課題を示しています。
最近、私はより攻撃的な提案をしました：EVMに中規模（しかし依然として破壊的な）変更を加えて1.5倍の利益を得るよりは、より優れた、よりシンプルな仮想マシンに移行して100倍の利益を実現する方が良いです。「合併」（The Merge）に似て、私たちは破壊的な変更の回数を減らしますが、各変更をより意味のあるものにします。具体的には、EVMをRISC-Vに置き換えるか、Ethereum ZKプローバーが使用する別の仮想マシンにすることを提案します。これにより、:
効率が大幅に向上：スマートコントラクトの実行（証明器内）にはインタプリタのオーバーヘッドが不要で、直接実行されます。Succinct のデータは、多くのシナリオで性能が100倍以上向上する可能性があることを示しています。
シンプルさの大幅な改善：RISC-V 規格は EVM と比べて非常にシンプルで、代替案（Cairo など）も同様に簡潔です。
EOFをサポートする動機：コードの分割、より親しみやすい静的分析、より大きなコードサイズの制限など。
さらなる開発者の選択肢：Solidity と Vyper は新しい仮想マシンにコンパイルするためのバックエンドを追加できます。RISC-V を選択すれば、主要なプログラミング言語の開発者も簡単にコードをこの仮想マシンに移植できます。
大部分のプリコンパイルを削除：高度に最適化された楕円曲線操作のみを保持する可能性があります（量子コンピュータが普及した後、これらも消えるでしょう）。
主な欠点は、準備が整ったEOFとは異なり、新しい仮想マシンの利益が開発者に届くまでに時間がかかることです。私たちは、高価値のEVM改善（契約コードサイズ制限の増加、DUP/SWAP17–32のサポートなど）を短期的に実施することで、この問題を緩和できます。
これにより、よりシンプルな仮想マシンが実現します。核心的な課題は、既存のEVMをどのように処理するかです。
仮想マシンの移行に関する後方互換性ポリシー
EVMを簡素化（または複雑さを増さずに改善する）する最大の課題は、目標の達成と既存アプリケーションの後方互換性とのバランスを取ることです。
まず明確にする必要があります：イーサリアムのコードベース（単一のクライアント内でも）には、唯一の定義方法はありません。
目標は緑の領域をできるだけ縮小することです：ノードがイーサリアムのコンセンサスに参加するために必要なロジックには、現在の状態の計算、証明、検証、FOCIL（フォーク選択ルール）、および「通常」のブロック構築が含まれます。
オレンジ色の領域は減少できません：プロトコル仕様が特定の実行レイヤー機能（例えば、バーチャルマシン、プリコンパイルなど）を削除または変更した場合、過去のブロックを処理するクライアントは関連コードを保持する必要があります。しかし、新しいクライアント、ZK-EVM、または形式的証明器はオレンジ色の領域を完全に無視できます。
新たに追加された黄色の領域：現在のチェーンの理解やブロック構築の最適化に非常に価値がありますが、合意の論理には含まれません。例えば、Etherscanや一部のブロック構築者はERC-4337ユーザー操作をサポートしています。もし私たちがオンチェーンRISC-V実装で特定のEthereum機能（例えばEOAおよびそのサポートする古いトランザクションタイプ）を置き換えれば、合意コードは大幅に簡素化されますが、専用ノードは依然として元のコードを使用して解析を行うかもしれません。
オレンジと黄色の領域の複雑さは、複雑性をカプセル化するものであり、プロトコルを理解している人はこれらの部分をスキップできます。イーサリアムはそれらを無視でき、これらの領域のエラーはコンセンサスリスクを引き起こしません。したがって、オレンジと黄色の領域のコードの複雑さは、緑の領域の複雑さに比べてはるかに危険性が低いです。
コードを緑の領域から黄色の領域に移す考え方は、AppleがRosetta翻訳レイヤーを通じて長期的な後方互換性を確保する戦略に似ています。
Ipsilon チームの最近の記事に触発されて、以下の仮想マシン変更プロセスを提案します（EVM から RISC-V への例ですが、EVM から Cairo への、または RISC-V からより優れた仮想マシンへの場合にも適用可能です）：
新しいプリコンパイルにオンチェーンRISC-Vの実装を要求します：エコシステムがRISC-V仮想マシンに徐々に適応できるようにします。
開発者オプションとしてRISC-Vを導入：プロトコルはRISC-VとEVMの両方をサポートし、二つの仮想マシンのコントラクトは自由に相互作用できます。
大部分のプリコンパイルを置き換え：楕円曲線操作とKECCAK（極限の速度が必要なため）を除いて、RISC-Vを用いて他のプリコンパイルを置き換えます。ハードフォークを通じてプリコンパイルを削除し、そのアドレスのコード（DAOフォークに似たもの）を空からRISC-V実装に変更します。RISC-V仮想マシンは非常にシンプルであり、ここで止まってもプロトコルは大幅に簡素化されます。
RISC-V に EVM インタプリタを実装する：スマートコントラクトをオンチェーンに（ZK プルーフが必要なため）。初期リリースから数年後、既存の EVM コントラクトはこのインタプリタを介して実行される。
第4ステップが完了した後、多くの「EVM実装」がブロック構築、開発者ツール、チェーン分析の最適化に引き続き使用されるが、もはや重要な合意仕様の一部ではなくなる。イーサリアムの合意は「ネイティブに」RISC-Vのみを理解する。
共有プロトコルコンポーネントの簡素化
プロトコル全体の複雑さを低減する第三の方法（最も過小評価されがちでもある）は、プロトコルスタックの異なる部分で統一された標準をできるだけ共有することです。異なるプロトコルが異なるシーンで同じことを行うことは通常無益ですが、このようなパターンは依然としてよく見られます。これは主にプロトコルのロードマップの異なる部分がコミュニケーションを欠いているためです。以下は、コンポーネントを共有することでイーサリアムを簡素化する具体的な例です。
統合イレイジャーコーディング
私たちは3つのシーンでエラー訂正コードが必要です:
データの可用性サンプリング：クライアントはブロックが公開されたことを検証します。
より迅速なP2Pブロードキャスト：ノードはn/2のスニペットを受信した後、ブロックを受け入れることができ、遅延と冗長性のバランスを取ります。
分散型履歴ストレージ：イーサリアムの履歴データをシャーディングストレージし、各グループのn/2の断片が残りの断片を復元できるため、単一の断片喪失リスクを低減します。
同じエラー訂正符号（Reed-Solomonやランダム線形符号など）を3つのシナリオで使用すると、以下の利点が得られます。
コード量の最小化：総コード行数を減らす。
効率の向上：ノードがあるシーンの一部のスニペットをダウンロードする場合、これらのデータは他のシーンで使用できます。
検証可能性を確保する：すべてのシーンの断片はルートに基づいて検証可能です。
異なる誤り訂正符号を使用する場合、データの可用性サンプリングの水平リード・ソロモン符号と垂直ランダム線形符号が同じ領域で動作することを少なくとも保証する必要があります。
統一シリアル化フォーマット
イーサリアムのシリアライズ形式は現在部分的に固定化されており、データは任意の形式で再シリアライズおよびブロードキャストできます。例外は取引の署名ハッシュで、規定の形式でハッシュ化する必要があります。将来的には、シリアライズ形式の固定化の程度が以下の理由によりさらに向上するでしょう：
完全なアカウント抽象（EIP-7701）：取引の完全な内容が仮想マシンに見える。
より高いガス制限：実行層データはデータブロック（blob）に入れる必要があります。
その時、私たちはイーサリアムの3つのレイヤーのシリアライズ形式を統一する機会があります：実行レイヤー、コンセンサスレイヤー、スマートコントラクト呼び出しABI。
SSZの使用を提案します。なぜなら、SSZは：
デコードが容易：スマートコントラクト内に含まれている（4バイトの設計と少ないエッジケースに基づいているため）。
コンセンサス層で広く使用されています。
既存のABIに非常に似ている：ツールの適応が比較的簡単です。
すでにSSZへの完全な移行に向けた努力が行われており、私たちは将来のアップグレードを計画する際にこれらの努力を考慮し、継続すべきです。
統一されたツリー構造
EVMからRISC-V（または他の選択可能な最小仮想マシン）に移行すると、16進数のMerkle Patriciaツリーがブロック実行の最大ボトルネックとなります。これは平均的なケースでも同様です。より優れたハッシュ関数に基づく二分木への移行は、証明器の効率を大幅に向上させ、ライトクライアントなどのシナリオでのデータコストを削減します。
移行する際、コンセンサス層が同じツリー構造を使用していることを確認する必要があります。これにより、Ethereumのコンセンサス層と実行層は同じコードを通じてアクセスおよび解析できるようになります。
今から未来へ
シンプルさは多くの面で分散化に似ており、両者はレジリエンスの目標の上流に位置しています。シンプルさを明確に重視するには、一定の文化的変化が必要です。その利益はしばしば定量化が難しく、追加の努力やいくつかの目を引く機能を放棄するコストは即座に明らかになります。しかし、時間が経つにつれて、利益はますます顕著になります — — ビットコイン自体がその優れた例です。
私はtinygradに倣い、Ethereumの長期的な規範のために明確な最大コード行数の目標を設定することを提案します。これにより、Ethereumのコンセンサスの重要なコードがBitcoinのシンプルさに近づくことができます。Ethereumの歴史的ルールを扱うコードは引き続き存在しますが、コンセンサスの重要な経路の外に置かれるべきです。同時に、私たちはよりシンプルな解決策を選ぶ理念を持ち、システム的な複雑性ではなく複雑性のカプセル化を優先し、明確な属性と保証を提供する設計選択を行うべきです。