「信頼不足」や「ウォークアウェイテスト合格」「自己主権」の重要で、かつ一貫して過小評価されがちな側面は、プロトコルの単純さです。 たとえプロトコルが数十万ノードの超分散型で、ビザンチンのフォールトトレランス率が49%、ノードが量子安全なピアダスやスタークで完全に検証しているとしても、数十万行のコードと5種類の博士レベルの暗号技術が混在する扱いにくい混沌としていれば、最終的にそのプロトコルは3つのテストすべてに失敗します。 * それは信用できないわけではない。なぜなら、プロトコルの性質を教えてくれる少数の高位司祭たちを信頼しなければならないからだ * 既存のクライアントチームが離れると、新しいチームが同じ品質レベルに到達するのは非常に困難になるため、ウォークアウェイテストには通らない * それは自律的ではありません。なぜなら、最も技術的な人でさえその物を点検し理解できないなら、それは完全にあなたのものではないからです また、プロトコルの各部分、特に複雑な方法で他の部分と相互作用できる場合、プロトコルが破れるリスクがあるため、安全性も低くなります。 Ethereumプロトコル開発に関して私が懸念しているのは、非常に特定のニーズに応えるために新機能を追加しすぎてしまうことです。たとえそれらの機能がプロトコルを肥大化させたり、新しい種類の相互作用コンポーネントや複雑な暗号を重要な依存関係として加えたりしてしまっても。これは短期的な機能向上には良いこともありますが、長期的な自治権の維持や、帝国やイデオロギーの興亡を超える100年にわたる分散型超構造の構築には非常に破壊的です。 核心的な問題は、プロトコルの変更を「既存プロトコルの変更としてどれだけ大きいか」という視点で判断すると、後方互換性を維持したいという欲求が、削除よりも追加がはるかに頻繁に起こり、プロトコルは時間とともに必然的に肥大化してしまうことです。これに対抗するために、イーサリアムの開発プロセスには明確な「簡素化」/「ガベージコレクション」機能が必要です。 「簡素化」には3つの指標があります: * プロトコル内のコード行数を最小化すること。理想的なプロトコルは、1ページ、あるいは少なくとも数ページに収まるものです * 根本的に複雑な技術的コンポーネントへの不必要な依存を避けること。例えば、セキュリティがハッシュのみに依存するプロトコル(さらに良いのは、ちょうど1つのハッシュ関数に依存する)は、ハッシュと格子に依存するプロトコルよりも優れています。何よりもアイソジェニズ(同性)を混ぜ込むのは最悪です。なぜなら(それを理解した本当に優秀で勤勉なオタクたちには申し訳ないですが)誰もアイソジェニズを理解していないからです。 * プロトコルが頼れる_invariants_: コア特性の追加。例えばEIP-6780(自己破壊除去)はスロットごとに最大N個のストレージスロットを変更可能でクライアント開発を大幅に簡素化し、EIP-7825(トランザクションあたりのガスキャップ)は1トランザクション処理コストの上限を設定し、ZK-EVMや並列実行に大いに役立ちました。 ゴミ収集は断片的に行うこともあれば、大規模に行うこともできます。この断片的なアプローチは、既存の機能を取り入れ、よりシンプルで意味のあるものにするために簡略化しようとします。一例としてグラムステルダムのガスコスト改革があり、以前は恣意的だった多くのガスコストが、資源消費に明確に関連する少数のパラメータに依存するようになった。 大規模なゴミ収集の一つがPoWをPoSに置き換えようとしていました。もう一つはリーン・コンセンサスの一環として起こり、同時に多くのミスを修正する場が開かれるでしょう( )。 もう一つのアプローチは「Rosettaスタイルの後方互換性」で、複雑だがあまり使われていない機能は使えるものの、必須プロトコルの一部から「降格」され、代わりにスマートコントラクトコードとして扱われるため、新規クライアント開発者はそれらを使う必要がなくなります。例: * 完全なネイティブアカウント抽象化にアップグレードすれば、すべての旧トランザクションタイプを廃止でき、EOAはすべての取引タイプを処理可能なスマートコントラクトウォレットに変換できます * 既存のプリコンパイル(本当に必要なものを除く)をEVMや後のRISC-Vコードに置き換えることができます * 最終的にはVMをEVMからRISC-V(または他のよりシンプルなVM)に変更できます。EVMは新しいVM上でスマートコントラクトに変換される可能性があります。 ...