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