Fede、Danno Ferrin、Justin Drake、Ladislaus、Tim Beiko へのご意見とご確認に感謝します。

Ethereumの目標は、グローバル台帳になることです - 人間の資産や記録を運ぶプラットフォームであり、ファイナンス、ガバナンス、高付加価値データの検証などのアプリケーションの基盤となります。この目標を達成するためには、拡張性と耐久性の両方が必要です。Fusakaハードフォーク計画では、L2データの利用可能なスペースを10倍に増やします。提案された2026年のロードマップまた、類似のスケールのL1データ拡張も含まれています。一方、「ザ・マージ」はイーサリアムをステーク（PoS）コンセンサスメカニズムにアップグレードしました。クライアントの多様性が急速に増加しています, ZK（ゼロ知識証明）の検証可能性と量子攻撃への耐性も着実に進化しており、アプリケーションエコシステムもますます拡大しています成熟而強固.

この記事の目標は、同様に重要だがしばしば過小評価される点を強調することです弾力性（そして最終的にスケーラビリティ）要素:
プロトコルのシンプリシティ。

Bitcoinの最も称賛されている側面の1つは、そのプロトコル設計であり、これは非常に優雅でシンプルです。

システムは、一連のブロックから成るブロックチェーンです。各ブロックは、ハッシュを介して前のブロックにリンクされています。各ブロックの有効性は、Proof of Work（PoW）によって検証されます。つまり、そのハッシュの先頭の数字がゼロかどうかをチェックするだけです。各ブロックには取引が含まれており、それらは採掘によって得られたコインを使うか、前の取引から出力されたコインを使います。基本的にはこれです。
さえも賢い高校生は、ビットコインプロトコルの動作原理を完全に理解する能力を持っています。そしてプログラマーは趣味のプロジェクトとしてビットコインクライアントを開発することさえできます。

プロトコルをシンプルに保つことは、ビットコインとイーサリアムを可能性を秘めた主な利点をもたらします信頼される中立性グローバル信頼の基盤層:

• プロトコルのロジックを理解しやすくし、プロトコルの研究、開発、およびガバナンスに参加できるグループを拡大し、技術的な障壁を下げ、プロトコル内の「技術官僚階級」の支配を避ける。
• プロトコルに統合された新しいインフラストラクチャ（新しいクライアント、新しい検証者、新しいログツールなど）の開発コストを大幅に削減します。
• プロトコルの長期間のメンテナンスコストを削減します。
• 致命的な脆弱性のリスクを低減するために、プロトコル仕様または実装コードのいずれかにある場合でも、そのプロトコルにそのような脆弱性が含まれていないことを検証することも容易になります。
• ソーシャル攻撃面を減らす：コンポーネントが少なければ少ないほど、特定の利害関係者によって悪用および制御される場所が少ない。

過去、イーサリアムはこの点でうまく機能していませんでした（時には私の個人的な決定のためでさえあります）、これが私たちの過剰な開発費用につながっています、@vbuterin/selfdestruct”>Various security risks and the closed nature of R&D culture, and these efforts often only bring illusory returns.
この記事では、イーサリアムが5年後にビットコインに近いシンプルさを実現する方法について説明します。

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

3-slot finality（3槽終了性）シミュレーション図 — 3sf-mini

新しいコンセンサスレイヤーデザイン（以前は 'beam chain' として知られていました）は、過去10年間にわたるコンセンサス理論、ZK-SNARKの開発、ステーキング経済などで蓄積した経験を統合し、長期的に最適なEthereumコンセンサスレイヤーを作成することを目指しています。この新しいコンセンサスレイヤーは、既存のビーコンチェーンと比較して、より高い単純さを実現することが期待されています。これは特に次の点で明らかです。

• 3スロット最終性再構築
  このデザインは、'スロット'と'エポック'、委員会の入れ替え、およびこれらのメカニズムに関連するその他のプロトコル仕様の詳細（同期委員会など）の区別をなくし、3つのスロットの最終性の基本バージョンを提供しています。わずか200行のコードしか必要ありませんそれは達成できます。 現在のGasperプロトコルと比較して、3つのスロットの最終性はほぼ最適なセキュリティを持っています。
• アクティブな検証者の数が減少しました
  より安全でシンプルなフォーク選択ルールを採用することがより実現可能になります。
• STARKに基づく集約プロトコル
  どなたでもアグリゲータになることができ、アグリゲータを信頼する必要がなく、繰り返しのビットフィールドに対する過剰な手数料などを心配する必要がありません。アグリゲーション暗号自体にはある程度の複雑さがありますが、高度にカプセル化された複雑さプロトコルの全体的なシステムリスクははるかに低いです。
• 上記の2つのポイントは、よりシンプルで堅牢なピア・ツー・ピア（P2P）アーキテクチャをサポートする可能性もあります。
• 私たちは、バリデータの参加、退出、引き出し、キースイッチング、慣性ペナルティなどのメカニズムを再考する機会があり、それらを単純化することができます。コード行数（LoC）を減らすだけでなく、より明確なメカニズム保証を提供します。たとえば、より明示的な '弱い主観性' の締め切りを設定します。

コンセンサス層の利点は、EVMの実行と比較して比較的切り離されているため、これらの改善を引き続き推進する余地がたくさんあるということです。
同じ簡略化を実行レイヤーでどのように達成するかがさらに難しい。

実行レイヤーを簡素化する

Ethereum Virtual Machine (EVM)の複雑さは継続的に増加しており、その多くは不必要であることが証明されています（しばしば私の個人的な決定に関連しています）：非常に特定の暗号形式に過剰に最適化された256ビットの仮想マシンを持っており、これらは徐々に周縁化されつつあります。また、一部の事前コンパイル済み契約は非常に少数のユースケースに過剰に焦点を当てています。

これらの実際の問題を徐々に修正しようとすることは不可能です。削除@vbuterinSELFDESTRUCT命令は膨大なエネルギーを消費しますが、その結果は限定されています。最近のEOF（EVMオブジェクト形式）に関する議論は、同様の変更を仮想マシンに加える難しさをさらに示しています。

したがって、代替手段として、最近、より過激なアイデアを提案しました。1.5倍の改善のための漸進的（しかし依然として破壊的な）変更を行う代わりに、100倍のリターンを目指し、遥かに優れた、よりシンプルな仮想マシンに直接移行する方が良いと考えています。まるで「マージ」のように、変換の数を減らしますが、それぞれが重要です。具体的には、既存のEVMをRISC-V（またはEthereumのZKプルーバーで使用される他の仮想マシン）で置き換えることを提案しています。この方法で、次のような成果を上げることができます:

• 重要な効率改善：スマートコントラクトはインタプリターのオーバーヘッドなしにプルーバー内で直接実行できるため。簡潔なデータによると、多くのシナリオでパフォーマンスを100倍以上向上させることができるという指標が示されています。
• 究極のシンプリシティ：EVMと比較して、RISC-V仕様非常にシンプル他の代替ソリューション（カイロなど）も同様に簡潔です。
• EOFの期待される利点を継承する：コードのセグメンテーション、より友好的な静的解析、より大きなコード容量制限など。
• 開発者はより多くの選択肢を持つ：SolidityとVyperは新しい仮想マシンバックエンドにコンパイルできます。RISC-Vが選択された場合、主要な言語の開発者も簡単にコードを移植できます。
• 事前コンパイルの必要性を大幅に削減し、おそらくいくつかの高度に最適化された楕円曲線演算のみを保持することができます（ただし、量子コンピューティングが一般的になるとこれらは存在しなくなります）。

このアプローチの主な欠点は、EOF（直ちに展開可能）とは異なり、新しい仮想マシンを開発者に恩恵をもたらすのに時間がかかることです。これを緩和するために、短期間にいくつかの小さなが高い価値を持つEVMの改善を導入することができます。契約コードサイズ制限を増やす、DUP/SWAP17-32命令などを増やします。

最終的に、これにより大幅に簡略化された仮想マシンが得られます。しかし、最大の問題は、既存のEVMに関してどうするかですか？

VM transitional backward compatibility strategy

意味のある簡素化（複雑さを追加せずに改善することさえ）を行う際、Ethereum Virtual Machine（EVM）の任意の部分で最も大きな課題は、既存のアプリケーションとの後方互換性を維持しながら目標を達成する方法です。

まず、明確にすべきことは、「Ethereumコードベース」の範囲を定義する単一の方法はないことです（同じクライアント内でも）。

緑地域の範囲をできるだけ最小限に抑えることが目標です。つまり、Ethereumのコンセンサスに参加するためにノードが実行する必要があるロジック、現在の状態、証明、検証、FOCIL（ファーストオーダーコンセンサスインテグリティレイヤー）、基本的なブロック構築などを含みます。

オレンジエリアは縮小できません:ある実行レイヤーの機能(仮想マシン、事前コンパイル、または他のメカニズムであるかどうか)がプロトコル仕様から削除された場合、またはその機能が変更された場合、歴史的なブロックを処理する関連するクライアントはそれを依然として保持する必要がありますが、重要なことは、新しいクライアント(ZK-EVMや形式的な検証者など)は完全にオレンジエリアを無視することができます。

新しいカテゴリは黄色のエリアです: この種のコードは現在のチェーン状態を理解し解析するために非常に重要であり、最良のブロックを構築するためにも重要ですが、合意の一部ではありません。 例えば、Etherscan(そしていくつかブロックビルダー) ERC-4337ユーザー操作のサポート。イーサリアムの一部の大規模な機能（例：EOAアカウントおよびさまざまな古いトランザクションタイプへのサポート）を置き換えるためにオンチェーンのRISC-V実装を使用する場合、コンセンサスコードが大幅に簡素化されたとしても、一部のプロフェッショナルノードは引き続きこれらの機能を解析するために元のコードを使用する可能性があります。

オレンジと黄色のエリアが「Gate」に属していることが重要ですカプセル化の複雑さプロトコルを理解したいと思う人は、それらをスキップすることができます。Ethereumクライアントも実装しないことを選択することができ、これらの領域のバグはコンセンサスリスクを引き起こしません。これは、オレンジ色と黄色の領域が緑の領域よりもコードの複雑さとネガティブな影響がはるかに小さいことを意味します。

緑ゾーンから黄色ゾーンへコードを移動し、このアプローチはApple Inc.と類似しています。Rosetta翻訳レイヤーを介して翻訳する長期的な互換性を確保するために。

私は提案しました（借用元@ipsilon/eof-ethereums-gateway-to-risc-v”> Ipsilon team’s recent views) The following virtual machine migration process (using EVM migration to RISC-V as an example, but also applicable to EVM migration to Cairo, and even future migration to a more optimal VM):

1. すべての新しい事前コンパイルは、エコシステムがRISC-Vを仮想マシンとして使用して慣れ親しむことができるように、標準のオンチェーンRISC-V実装で記述する必要があります。
2. EVMに並行して契約開発のオプションとしてRISC-Vを導入します。このプロトコルは、RISC-VとEVMの両方をネイティブサポートしており、両言語で書かれた契約が自由に相互作用することができます。
3. 楕円曲線演算とKECCAKを除くすべてのプリコンパイルをRISC-V実装に置き換えます。これらのプリコンパイルをハードフォークを介して削除し、同時に対応するアドレスのコード（DAOフォークスタイル）をRISC-V実装に変更します。RISC-V VMは非常に簡潔であるため、これだけでも全体構造が簡素化されます。
4. RISC-Vで書かれたEVMインタープリターを実装し、スマートコントラクトとしてチェーンに展開します。初期リリース後数年、既存のEVMコントラクトはこのインタープリターを介して処理されます。

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

プロトコルコンポーネントを共有することでシンプルにする

第三に、おそらく最も過小評価されている簡略化方法は、プロトコルスタックのさまざまな部分で可能な限り統一された標準を共有することです。通常、異なるシナリオで同じ目的のために異なるプロトコルを使用する理由はないのですが、プロトコルロードマップの異なる部分間のコミュニケーション不足によるところが大きいため、このような状況が実際には頻繁に発生しています。ここに、イーサリアムを「コンポーネント共有の最大化」を通じて簡略化する具体的な例がいくつかあります。

統一イレイジャーコード

私たちは3つのシナリオで削除コードを修正する必要があります。

• データ可用性サンプリング - クライアントは、ブロックが公開されたかどうかを検証します
• より高速なP2Pブロードキャスト - ノードはn個のブロックのうちn/2個を受信した後にブロックを受け入れることができるため、遅延と冗長性の削減の間で最適なバランスを確立します。
• 分散履歴ストレージ - Ethereumのすべての履歴は多くのブロックに保存されていますので、(i) これらのブロックは独立して検証でき、(ii) 各グループのブロックの半分が残りの半分を回復できるため、単一のブロック損失のリスクが大幅に低減されます。

同じ消去符号（Reed-Solomon、ランダム線形符号、その他）を3つのユースケースで使用すると、いくつかの重要な利点を得ることができます。

1. 合計行数を最小限に抑える
2. 各ノードが1つのユースケースのためにブロックのさまざまな部分をダウンロードする必要がある場合（ブロック全体ではなく）、データを別のユースケースに使用できるため、効率を向上させる
3. 検証可能性を確保します：コンテキスト内のすべての3つのブロックは、ルートに基づいて検証できます

異なる誤り訂正コードが実際に必要な場合、「互換性」は少なくとも確保されるべきです：たとえば、DASシナリオでは、Reed-Solomonが水平に使用され、ランダム線形コードが垂直に使用されますが、両方とも同じ数学的なフィールドに基づいています。

統一された直列化形式

現在、Ethereumのシリアル化形式は厳密に言うと「半標準化」されています。データは任意の形式で再シリアル化およびブロードキャストされる可能性があるため、唯一の例外はトランザクション署名ハッシュであり、ハッシュ計算に標準化された形式が必要です。
しかし、将来のシリアル化形式の標準化は、2つの理由からさらに改善されるでしょう：

• 包括的なアカウント抽象化（EIP-7701）：仮想マシンは完全なトランザクションコンテンツを見ることができるようになります
• ガスリミットの増加：実行ブロックデータをブロブにパッケージ化する必要があります

その時、私たちは現在の3つの側面に必要なシリアル化ソリューションを統一する機会があります：1）実行レイヤー；2）合意レイヤー；3）スマートコントラクト呼び出しABI。

私は採用を提案しますSSZ(Simple Serialize), because SSZ has the following advantages:

• Easy to decode: including inside smart contracts (based on 4-byte design, few boundary cases)
• コンセンサスで広く使用されています
• 既存のABIに非常に類似しています：ツールチェーンの移行コストが低い

現在、より多くのコンポーネントがあります移行SSZへ仕事将来のアップグレードを計画する際には、これらの進展を十分に考慮し、活用する必要があります。

統一されたツリー構造

EVMからRISC-V（または他のミニマリストVM）に移行すると、16進数のMerkle Patriciaツリーは、平均的なシナリオでもブロック実行の証明において最大のボトルネックとなります。ハッシュ関数に移行することで、バイナリツリー,検証者の効率を大幅に向上させ、軽量ノードなど他のシナリオのデータコストを削減します。

ツリー構造の移行を完了する際には、コンセンサスレイヤーが同じツリー構造を使用するようにして、Ethereum全体（コンセンサスレイヤーと実行レイヤーの両方）を同じコードセットを使用してアクセスおよび解析できるようにも確認する必要があります。

未来への未来

簡略化と分散化には多くの類似点があります。両方とも、システムの回復力というより高い目標を達成するために必要な上流要件です。簡略化を明示的に強調するには、文化の変革が必要です。簡略化の利点は初期段階では見えにくいことが多いですが、それらの「新しい輝く機能」を拒否することの機会費用と追加の作業負荷はすぐに明らかになります。しかし、時間の経過とともに、簡略化の長期的な価値がますます明らかになります。ビットコイン自体がその優れた例です。

私たちは提案しますtinygradのアプローチから学ぶEthereumの長期仕様に明確なコード行制限目標を設定するには、EthereumのコンセンサスクリティカルなコードをBitcoinのミニマリストスタイルにできるだけ近づけることを目指します。 Ethereumの歴史的な規則に関するコードは引き続き存在しますが、コンセンサスクリティカルなパスから分離されるべきです。同時に、可能な限りシンプルな解決策を選択し、システム全体の複雑さよりもカプセル化された複雑さを優先し、明確な検証可能なプロパティと保証を提供する設計上の決定に傾斜する普遍的な設計原則を形成する必要があります。

免責事項:

1. この記事は[vitalik]から転載されました。すべての著作権は元の著者に帰属します[vitalikすべて。この転載に異議がある場合は、お問い合わせくださいGate Learnチームは適切なタイミングで対応します。
2. 免責事項：本文に表現された見解や意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. Gate Learnチームは、記事を他の言語に翻訳します。特に指定されていない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。