要点Vitalik Buterinは、イーサリアムの長期的な信頼性と自己主権はプロトコルのシンプルさに依存していると述べ、明示的な簡素化と「ガベージコレクション」を呼びかけて、膨張を抑え、インバリアントを強化し、時間とともにコアの変更を遅らせる必要性を強調した。最近のX（旧Twitter）上の投稿で、Vitalik Buterinは、プロトコル内の複雑さの増加がその基本原則を損なうと主張し、コードの膨張を減らし、コアのインバリアントを強化し、重要な変更のペースを遅らせるために、意図的な簡素化と「ガベージコレクション」のプロセスを求めた。彼は、ノードの参加が広範でビザンチン耐性が強い高度に分散されたプロトコルでさえ、その構造が過度に複雑になると根本的な失敗を招く可能性があることを指摘した。さらに、何十万行ものコードと複数層の高度な暗号技術を備えたプロトコルは、信頼性の欠如、耐障害性、自己主権の重要な指標に失敗する可能性があると説明した。そのような場合、ユーザーは少数の専門家に依存してプロトコルの性質を解釈しなければならず、新しいチームはシステムの品質を維持または再現するのに苦労し、技術的に高度な参加者でさえもプロトコルを完全に検査または制御することが不可能になることもある。イーサリアムの共同創設者はまた、複雑さがセキュリティリスクを高めると指摘した。プロトコルのコンポーネント間の複雑な相互作用は、潜在的な故障点を生み出す可能性があるためだ。彼は、短期的なニーズに応じて機能を追加することに反対し、たとえ有益な追加でも、新たな暗号依存や相互作用を導入し、長期的な自己主権を損なう可能性があると警告した。Vitalik Buterinはこれを、イーサリアムが数十年、ひいては数世紀にわたって持続可能な分散型インフラとしての潜在能力に対する脅威と位置付けた。## Vitalik Buterin、複雑さを減らし長期的な信頼性を維持するためのイーサリアム簡素化フレームワークを概説彼によると、現在の開発アプローチは、後方互換性を維持するために削除よりも付加的な変更を優先しがちであり、これが時間とともに避けられないプロトコルの膨張に寄与している。これに対処するために、イーサリアムの開発プロセス内に「簡素化」または「ガベージコレクション」の正式な機能を確立し、不必要な複雑さを削減し、長期的な信頼性と自己主権を維持することを提案した。Vitalik Buterinは、イーサリアムプロトコル内の「簡素化」フレームワークを概説し、主に3つの目的を強調した。第一は、全体のコード行数を最小限に抑えることで、理想的には1ページに収まるか、少なくともコンパクトで理解しやすい状態を保つこと。第二は、複雑な技術的コンポーネントへの依存を制限し、セキュリティが単一のハッシュ関数などのシンプルな仕組みに依存する設計を優先すること。第三は、コアのインバリアントの数を増やすことで、予測可能な動作を保証できるプロトコルの性質を強化すること。例として、EIP-6780はストレージスロットの変更を制限し、クライアント開発を簡素化し、EIP-7825はトランザクション処理コストの上限を設け、並列処理の効率化やZK-EVMのサポートを促進している。Vitalik Buterinは、「ガベージコレクション」を、部分的または大規模に行えるプロセスと表現した。段階的な改善は、既存の機能を合理化して複雑さを減らし、明確さを向上させることを含む。例として、Glamsterdamで実施されたガスコスト改革があり、以前の任意のコストを明確で測定可能なリソース消費に基づくシステムに置き換えた。大規模な変革には、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行や、今後のLeanコンセンサスアップグレードなどがあり、これらは複数のプロトコルの非効率性を同時に修正できるようになる見込みだ。もう一つのアプローチは、「ロゼッタスタイルの後方互換性」と呼ばれ、複雑だが稀に使われる機能をデモoteした形で保存し、それらを必須のプロトコル要素ではなくスマートコントラクトコードとして実装することを意味する。これにより、新しいクライアント開発者は古いまたは稀に使われるコンポーネントの取り扱いを避けられる。例えば、ネイティブアカウント抽象化の完全実装後、レガシートランザクションタイプは廃止され、外部所有アカウントはスマートコントラクトウォレットに変換されてこれらのトランザクションを処理できるようになる。同様に、既存のプリコンパイルはEVMやRISC-Vコードに置き換えられ、最終的には仮想マシン自体もEVMからよりシンプルなアーキテクチャに移行し、元のEVMは新しい環境内のスマートコントラクトとして維持される可能性がある。開発者は、クライアント開発者の負担を軽減する重要性を強調し、古いプロトコルバージョンは孤立したコンテナ内で引き続き動作させることができ、互換性を維持しながら継続的な開発を複雑にしないと提案した。彼の見解では、イーサリアムの最初の15年間は、思春期に例えられる探索段階であり、多くのアイデアを試しながら、何が効果的で持続可能かを見極めてきた。長期的な目標は、プロトコルの変更速度を遅らせ、もはや役に立たない要素を排除し、不必要な複雑さがイーサリアムの進化を永続的に妨げることを防ぐことである。
Vitalik Buterinは、イーサリアムの複雑さを軽減し、自己主権を強化するために「ガベージコレクション」を提唱
要点
Vitalik Buterinは、イーサリアムの長期的な信頼性と自己主権はプロトコルのシンプルさに依存していると述べ、明示的な簡素化と「ガベージコレクション」を呼びかけて、膨張を抑え、インバリアントを強化し、時間とともにコアの変更を遅らせる必要性を強調した。
最近のX（旧Twitter）上の投稿で、Vitalik Buterinは、プロトコル内の複雑さの増加がその基本原則を損なうと主張し、コードの膨張を減らし、コアのインバリアントを強化し、重要な変更のペースを遅らせるために、意図的な簡素化と「ガベージコレクション」のプロセスを求めた。
彼は、ノードの参加が広範でビザンチン耐性が強い高度に分散されたプロトコルでさえ、その構造が過度に複雑になると根本的な失敗を招く可能性があることを指摘した。さらに、何十万行ものコードと複数層の高度な暗号技術を備えたプロトコルは、信頼性の欠如、耐障害性、自己主権の重要な指標に失敗する可能性があると説明した。そのような場合、ユーザーは少数の専門家に依存してプロトコルの性質を解釈しなければならず、新しいチームはシステムの品質を維持または再現するのに苦労し、技術的に高度な参加者でさえもプロトコルを完全に検査または制御することが不可能になることもある。
イーサリアムの共同創設者はまた、複雑さがセキュリティリスクを高めると指摘した。プロトコルのコンポーネント間の複雑な相互作用は、潜在的な故障点を生み出す可能性があるためだ。彼は、短期的なニーズに応じて機能を追加することに反対し、たとえ有益な追加でも、新たな暗号依存や相互作用を導入し、長期的な自己主権を損なう可能性があると警告した。Vitalik Buterinはこれを、イーサリアムが数十年、ひいては数世紀にわたって持続可能な分散型インフラとしての潜在能力に対する脅威と位置付けた。
Vitalik Buterin、複雑さを減らし長期的な信頼性を維持するためのイーサリアム簡素化フレームワークを概説
彼によると、現在の開発アプローチは、後方互換性を維持するために削除よりも付加的な変更を優先しがちであり、これが時間とともに避けられないプロトコルの膨張に寄与している。これに対処するために、イーサリアムの開発プロセス内に「簡素化」または「ガベージコレクション」の正式な機能を確立し、不必要な複雑さを削減し、長期的な信頼性と自己主権を維持することを提案した。
Vitalik Buterinは、イーサリアムプロトコル内の「簡素化」フレームワークを概説し、主に3つの目的を強調した。
第一は、全体のコード行数を最小限に抑えることで、理想的には1ページに収まるか、少なくともコンパクトで理解しやすい状態を保つこと。第二は、複雑な技術的コンポーネントへの依存を制限し、セキュリティが単一のハッシュ関数などのシンプルな仕組みに依存する設計を優先すること。第三は、コアのインバリアントの数を増やすことで、予測可能な動作を保証できるプロトコルの性質を強化すること。例として、EIP-6780はストレージスロットの変更を制限し、クライアント開発を簡素化し、EIP-7825はトランザクション処理コストの上限を設け、並列処理の効率化やZK-EVMのサポートを促進している。
Vitalik Buterinは、「ガベージコレクション」を、部分的または大規模に行えるプロセスと表現した。段階的な改善は、既存の機能を合理化して複雑さを減らし、明確さを向上させることを含む。例として、Glamsterdamで実施されたガスコスト改革があり、以前の任意のコストを明確で測定可能なリソース消費に基づくシステムに置き換えた。大規模な変革には、プルーフ・オブ・ワークからプルーフ・オブ・ステークへの移行や、今後のLeanコンセンサスアップグレードなどがあり、これらは複数のプロトコルの非効率性を同時に修正できるようになる見込みだ。
もう一つのアプローチは、「ロゼッタスタイルの後方互換性」と呼ばれ、複雑だが稀に使われる機能をデモoteした形で保存し、それらを必須のプロトコル要素ではなくスマートコントラクトコードとして実装することを意味する。これにより、新しいクライアント開発者は古いまたは稀に使われるコンポーネントの取り扱いを避けられる。例えば、ネイティブアカウント抽象化の完全実装後、レガシートランザクションタイプは廃止され、外部所有アカウントはスマートコントラクトウォレットに変換されてこれらのトランザクションを処理できるようになる。同様に、既存のプリコンパイルはEVMやRISC-Vコードに置き換えられ、最終的には仮想マシン自体もEVMからよりシンプルなアーキテクチャに移行し、元のEVMは新しい環境内のスマートコントラクトとして維持される可能性がある。
開発者は、クライアント開発者の負担を軽減する重要性を強調し、古いプロトコルバージョンは孤立したコンテナ内で引き続き動作させることができ、互換性を維持しながら継続的な開発を複雑にしないと提案した。彼の見解では、イーサリアムの最初の15年間は、思春期に例えられる探索段階であり、多くのアイデアを試しながら、何が効果的で持続可能かを見極めてきた。長期的な目標は、プロトコルの変更速度を遅らせ、もはや役に立たない要素を排除し、不必要な複雑さがイーサリアムの進化を永続的に妨げることを防ぐことである。