Vitalik の長文記事レビュー: Ethereum が「選ばなかった道」

Ethereum プロトコル開発コミュニティは、Ethereum の初期段階でプロジェクトの軌道に大きな影響を与える多くの決定を下しました。場合によっては、イーサリアムの開発者は、ビットコインが失敗したと考えられる部分を改善するという意識的な決断を下しています。他の場所では、私たちはまったく新しいものを作っており、そのギャップを埋めるために何かを考え出さなければなりませんが、選択肢はたくさんあります。より複雑なものとより単純なものの間でトレードオフを行った箇所は他にもあります。時には、より単純なものを選択することもありますが、時には、より複雑なものを選択することもあります。

この投稿では、私の記憶にあるフォークのいくつかを見ていきます。これらの機能の多くは、コア開発サークル内で真剣に議論されてきました。他のものはほとんど考慮されていませんが、おそらく考慮されるべきでした。しかし、そうであっても、さまざまなイーサリアムがどのようなものになるのか、そしてそこから何を学べるのかを検討することは価値があります。

PoS のよりシンプルなバージョンを使用すべきでしょうか?

イーサリアムに間もなく導入される Gasper PoS は複雑なシステムですが、非常に強力なシステムでもあります。その機能の一部は次のとおりです:

非常に強力な単一ブロック確認- トランザクションがブロックに含まれると、大部分のノードが不正であるか、極端なネットワーク遅延が発生しない限り、ブロックは通常、数秒以内に元に戻せないレベルまで固まります。
経済的最終性— ブロックが確定すると、攻撃者が罰せられ、数百万 ETH を失うことなく、ブロックを元に戻すことはできません。
非常に予測可能な報酬- バリデータはエポック（6.4 分）ごとに確実に報酬を受け取るため、プールのインセンティブが減少します。
非常に多くのバリデーター数のサポート— 上記の機能を備えた他のほとんどのブロックチェーンとは異なり、Ethereum ビーコンチェーンは数十万のバリデーターをサポートします (たとえば、Tendermint は Ethereum よりも高速なファイナリティを提供しますが、サポートするバリデーターは数百のみです)。

しかし、これらの特性を備えたシステムを作るのは困難です。何年もの研究、何年もの失敗した実験、そして一般的に多大な努力が必要です。最終結果は非常に複雑です。

もし私たち研究者がコンセンサスについてそれほど心配する必要がなく、もっと頭を働かせる余裕があったら、おそらく、ロールアップは 2016 年に発明されていたかもしれません。ここで疑問が湧いてきます。私たちは本当にこれほど高い基準を持つべきなのでしょうか?私たちの PoS は、PoS のよりシンプルで弱いバージョンであっても、PoW の現状よりも大幅に改善されるでしょうか?

PoS は本質的に複雑であると多くの人が信じていますが、実際には Satoshi PoW とほぼ同じくらい単純な PoS アルゴリズムが存在します。 NXT PoS は 2013 年から存在しており、当然の候補だったでしょう。問題はありましたが、簡単に修正でき、2017 年、あるいは最初から正常に機能する PoS を実現できたはずです。 Gasper がこれらのアルゴリズムよりも複雑な理由は、単に Gasper がこれらのアルゴリズムよりも多くのことを達成しようとしているからです。しかし、控えめに始めれば、より限定された一連の目標を達成することに集中することができます。

私の意見では、PoS は最初から間違いでした。 PoW は、初期の配布を拡大し、Ethereum をアクセスしやすくするとともに、愛好家のコミュニティを奨励するのに役立ちます。しかし、2017年、あるいは2020年によりシンプルなPoSに切り替えれば、環境へのダメージ（および環境へのダメージが引き起こす反暗号通貨の考え方）は大幅に軽減される可能性があり、より多くの研究者がスケーリングについて自由に検討できるようになるでしょう。より良い PoS を作るために多くのリソースを費やす必要があるのでしょうか?はい。しかし、最終的にはそうなるようです。

シャーディングの複雑さの軽減

イーサリアムのシャーディングは、2014 年にアイデアの作業が開始されて以来、複雑さが軽減されてきました。まず、組み込みの実行機能とシャード間トランザクションを備えた複雑なシャーディングがあります。次に、より多くの責任をユーザーに移すことでプロトコルを簡素化します (たとえば、クロスシャードトランザクションでは、ユーザーは両方のシャードに対して個別にガスを支払う必要があります)。その後、プロトコルの観点から見るとシャードは単なるデータのチャンクである、ロールアップ中心のロードマップに切り替えました。最後に、danksharding を通じて、シャード料金市場が 1 つに統合され、最終的な設計はシャード化されていないチェーンとまったく同じように見えますが、シャード検証のために舞台裏でデータ可用性サンプリングの魔法が実行されます。

しかし、逆の方向に進むとどうなるでしょうか?実際、Ethereum の研究者は、より複雑なシャーディングシステムを詳細に調査しました。シャードはチェーンを生成し、親チェーンのフォーク選択ルールに依存する子チェーンが存在し、シャード間のメッセージはプロトコルによってルーティングされ、バリデータはシャード間でローテーションされ、アプリケーションはシャード間で自動的に負荷分散されます。

このアプローチの問題は、これらの形式のシャーディングが主に単なるアイデアと数学モデルであるのに対し、Danksharding は完全でほぼ実装された仕様であるということです。したがって、イーサリアムのコンテキストと制限を考慮すると、シャーディングの簡素化と野心の緩和は、私の意見では絶対に正しい動きです。とはいえ、より野心的な研究にも非常に重要な役割があります。それは、有望な研究の方向性を特定することであり、非常に複雑なアイデアであっても、通常、そのアイデアの「かなり単純な」バージョンがあり、それでも多くの利点があり、今後数年間で Ethereum プロトコルの開発 (レイヤー 2 プロトコルも含む) に大きな影響を与える可能性が高いということです。

EVM の機能は増えましたか、それとも減りましたか?

実際、セキュリティ監査を除けば、EVM 仕様は 2014 年半ばまでに準備できる可能性があります。しかし、その後数か月間、私たちは分散型アプリケーションにとって重要になると思われる新機能を積極的に探求し続けました。追加されなかったものもあれば、追加されたものもありました。

「POST」オペコードを追加することを検討しましたが、追加しないことにしました。 POST オペコードは、トランザクションの残りの部分が完了した後に実行される非同期呼び出しを行います。
「ALARM」オペコードを追加することを検討しましたが、追加しないことにしました。 ALARM は POST と同様に機能しますが、将来のブロックで非同期呼び出しを実行する点が異なります。
ログ機能を追加し、契約が状態を伴わないが、dapp インターフェースとウォレットによって解釈できるレコードを出力できるようにしました。なお、ETH 転送時にログを出力することも検討しましたが、最終的には「人々はすぐにスマートコントラクトウォレットに移行するだろう」という理由で、ログ出力を行わないことに決定しました。
SSTORE を拡張してバイト配列をサポートすることを検討しましたが、複雑さとセキュリティに関する懸念から、それを断念しました。
プリコンパイルを追加しました。これは、EVM よりもはるかに低いガスコストでネイティブ実装を使用して特殊な暗号化操作を実行するコントラクトです。
導入後の数か月間、州の家賃は何度も検討されたが、決して考慮されることはなかった。これは複雑すぎます。現在、より優れた状態有効期限スキームが積極的に検討されていますが、ステートレス検証と提案者/ビルダーの分離により、現時点では優先順位ははるかに低くなっています。

今日では、機能を追加しないという決定のほとんどは、非常に良い決定であることが証明されています。「POST」オペコードを追加する明確な理由はありません。「ALARM」オペコードを安全に実装するのは実際には非常に困難です。ブロック 1…99999 の全員がブロック 100000 で大量のコードを実行するために「ALARM」を設定するとどうなるでしょうか。ブロックの処理には数時間かかりますか?予定されている一部の操作は後のブロックに延期されますか?しかし、もしこれが起こった場合、「ALARM」が維持されるという保証はあるのでしょうか? SSTORE はバイト配列に対して安全に実行するのが難しく、最悪の場合の監視サイズが大幅に拡大します。

状態レントの問題はさらに困難です。実際に初日から何らかの状態レントを実装した場合、永続的な状態という標準的な仮定に基づいてスマートコントラクトエコシステムが進化することはないでしょう。イーサリアムは構築するのがより困難だっただろうが、よりスケーラブルで持続可能だっただろう。同時に、当時の州の賃貸プログラムは、確かに現在のものよりはるかに劣悪なものでした。時には、良いアイデアが思いつくまでに何年もかかることもあり、それを実現するより良い方法はありません。

「LOG」への代替パス

LOG は 2 つの異なる方法で実行できます。

1. ETH 転送時に自動的に「LOG」を発行することができます。これにより、取引所や他の多くのユーザーの労力とソフトウェアのバグの問題が大幅に軽減され、ログへの依存が加速し、皮肉なことにスマートコントラクトウォレットの採用が促進されます。

2. 「LOG」オペコードの使用を完全に回避し、ERC に変換できます。関数 submitLog を備えた標準コントラクトがあり、Ethereum デポジットコントラクトのテクノロジを使用して、ブロック内のすべてのログの Merkle ルートを計算します。 EIP-2929 またはブロック全体のストレージ (「TSTORE」と同等ですが、ブロック後にクリアされます) を使用すると、コストが削減されます。

私たちは（１）を強く検討したが却下した。主な理由は単純さです。ログ記録は「LOG」オペコードから行われる可能性が高くなります。

また、ほとんどのユーザーが、すでにオペコードを使用して転送を明示的に記録している可能性のあるスマートコントラクトウォレットにすぐに移行することを（非常に間違って！）予想していました。

（２）私はそれを考慮していなかったが、振り返ってみると、それは常に選択肢であった。（2）の主な欠点は、高速ログスキャンのためのブルームフィルタ機構が欠如していることである。しかし、ブルームフィルターのメカニズムは dapp がユーザーフレンドリーになるには遅すぎることが判明したため、現在ではクエリに TheGraph を使用する人が増えています。

全体的には、どちらのアプローチも現状よりも優れている可能性が高いです。 LOG をプロトコルの外部に保持すると物事は簡単になりますが、プロトコル内のすべての ETH 転送を自動的にログに記録するとより便利です。

今日、私はおそらく、EVM から「LOG」オペコードを最終的に削除することに賛成するでしょう。

EVM が完全に異なる場合はどうなるでしょうか?

EVM が取ることができる自然なパスは 2 つあります。

1. EVM を組み込み変数、if 文、ループ、その他の構造を備えた高水準言語にします。

2. EVM を既存の VM (LLVM、WASM など) のコピーにします。

最初の道は実際には考慮されていませんでした。このパスの魅力は、コンパイラーをよりシンプルにし、より多くの開発者が EVM で直接コードを記述できるようになることです。また、ZK-EVM 構造も簡素化されます。このパスの弱点は、EVM コードの構造がより複雑になることです。これは、連続するオペコードの単純なリストではなく、何らかの方法で保存する必要があるより複雑なデータ構造です。つまり、両方の長所を活かす機会を逃したことになります。EVM の変更によって、基本的な EVM 構造をほぼそのまま維持しながら、動的ジャンプを禁止し、サブルーチンをサポートするように設計されたオペコードを追加し (EIP-2315 も参照)、32 バイトワード境界でのメモリアクセスのみを許可するなど、多くの利点が得られていた可能性があります。

2 番目の方法は何度も提案され、何度も拒否されてきました。通常の議論では、既存の言語 (C、Rust など) からプログラムを EVM にコンパイルできるようになるとされています。これに対する反論は、イーサリアムの独自の制限を考慮すると、実際には何のメリットももたらさないだろうというものでした。

高級言語の既存のコンパイラはコード全体のサイズを気にしない傾向がありますが、ブロックチェーンコードはコードサイズを 1 バイトでも削減するために徹底的に最適化する必要があります。
VM の複数の実装が必要であり、2 つの実装が同じコードを異なる方法で処理しないという厳しい要件があります。自分たちが書いていないコードに対してセキュリティ監査と検証を実行するのは、はるかに困難です。
仮想マシンの仕様が変更されると、Ethereum は常にそれに合わせて更新するか、同期がますます失われることになります。

したがって、EVM を現在のものと根本的に異なるものにするための実行可能な道筋はおそらくなかったでしょう。ただし、異なる方法で実行すればより良い結果につながる可能性のある細かい点 (ジャンプ、64 ビット対 256 ビットなど) は多数あります。

ETH の供給は別の方法で分配されるべきでしょうか?

Etherscan のこのチャートは、現在の ETH 供給量を大まかに表しています。

現在存在するすべての ETH のおよそ半分は、公開 Ethereum セールで販売されました。誰でも標準化されたビットコインアドレスに BTC を送信でき、初期の ETH 供給割り当ては、そのアドレスへのトランザクションをビットコインブロックチェーンでスキャンするオープンソーススクリプトによって計算されます。残りのほとんどは採掘済みです。黒い部分（「その他」とマークされた 1,200 万 ETH）は事前にマイニングされ、Ethereum Foundation と Ethereum プロトコルの初期貢献者約 100 人に割り当てられます。

このプロセスに対しては主に 2 つの批判があります。

プレマインとイーサリアム財団が売却から資金を受け取ったという事実は、信頼できるほど中立的ではありません。受取人アドレスの一部はクローズドプロセスを通じて厳選されており、イーサリアム財団が借り入れをして受け取った資金を再利用し、売却に再投資して ETH をさらに増やすようなことはしないと信頼する必要があります (私たちはそうしませんし、そうしていると真剣に主張する人もいませんが、完全な信頼を要求すること自体が一部の人々を不快にさせるでしょう)。
プレマイニングでは、初期の貢献者に過剰な報酬が与えられ、後からの貢献者にはあまり報酬が残されません。プレマイニングの 75% は、ローンチ前の貢献者への報酬として使用され、ローンチ後には、Ethereum Foundation に 300 万 ETH しか残りませんでした。 6 か月で、経済的存続のために売却する必要のある ETH は約 100 万 ETH に減少しました。

ある程度、これらの問題は関連しています。中央集権化の認識を最小限に抑えたいという願望は、より小さなプレマインの出現につながり、より小さなプレマインはより早く使い果たされます。

これが物事を成し遂げる唯一の方法ではありません。 Zcash は異なるアプローチを採用しています。ブロック報酬の固定 20% がプロトコルにハードコードされた受信者のセットに割り当てられ、受信者のセットは 4 年ごとに再交渉されます (これはこれまでに 1 回だけ発生しています)。この方が持続可能だったでしょうが、中央集権的であるという理由でより厳しく批判されたでしょう (Zcash コミュニティは、Ethereum コミュニティよりも技術的なリーダーシップに対してオープンであるように思われます)。

考えられる代替パスの 1 つは、現在一部の DeFi プロジェクトで人気のある「初日から DAO」ルートに似ています。ここに脆弱性の可能性がある提案があります:

2年間にわたり、各ブロック報酬から2 ETHが開発者基金に投入されることに同意します。
イーサリアムセールでETHを購入した人は誰でも、開発者基金の優先割り当て投票を指定できます（例：「ブロックあたり1 ETHはイーサリアム財団に、0.4 ETHはコンセンシス研究チームに、0.2 ETHはヴラド・ザムファーに…」）
投票の受取人は、全員の投票の中央値に等しい開発基金のシェアを、比例計算してブロックあたり合計 2 ETH で受け取ります(中央値は自己取引を防ぐためのものです。自分に投票した場合、あなたに言及した他の購入者の少なくとも半数を獲得しない限り、シェアを受け取ります)

セールは、セール中に受け取ったビットコインを ETH 開発基金と同じ割合で分配することを約束する法人によって実施される可能性があります (または、ビットコイン保有者を本当に満足させたいのであれば、それを燃やすこともできます)。これにより、信頼できる中立性を損なうことなく、イーサリアム財団や、同様にイーサリアム以外の財団（より分散化されたエコシステムの構築）に多額の資金が提供される可能性がある。主な欠点は、もちろんトークン投票が本当にひどいということだが、現実的に考えれば、2014 年はまだ初期かつ理想的な時期であり、トークン投票の最悪の欠点はセールが終わってからずっと後に初めて現れるということに気づくことができたはずだ。

これはより良いアイデアであり、より良い前例となるでしょうか?多分！実際には、開発基金が完全に信頼できる中立であったとしても、今日イーサリアムのプレマインについて叫んでいる人々は、DAOフォークに対してさらに大きな声を上げ始めているだけかもしれません。

このすべてから私たちは何を学ぶことができるでしょうか?

全体的に、イーサリアムの最大の課題は、セキュリティとシンプルさを重視する純粋でシンプルなブロックチェーンと、高度なアプリケーションを構築するための高性能で機能的なプラットフォームという 2 つのビジョンのバランスから生じていると感じることがあります。上記の例の多くは、このことのほんの一側面にすぎません。つまり、機能は少ないがビットコインに似ているのか、それとも機能は豊富だが開発者に優しいのか、ということです。私たちは開発基金を信頼できる中立的なものにしてビットコインに近づけることを非常に心配しているのでしょうか、それとも、何よりもまず、開発者がイーサリアムをより良くするために十分な報酬を得られることを心配しているのでしょうか?

私の個人的な夢は、毎年仕様が小さくなるベースレイヤーと、レイヤー 2 プロトコルを中心とした高度なアプリケーションの堅牢で開発者に優しいエコシステムという、両方のビジョンを同時に実現することです。とはいえ、そのような理想的な世界に到達するには長い時間がかかるため、時間がかかること、そしてロードマップを段階的に考える必要があることを明確に認識することが、私たちにとって大きな助けとなるかもしれません。

現在、変えられないものも数多くありますが、変えられるものも多く、機能性とシンプルさを大幅に向上させる道もまだ残っています。時には道のりは曲がりくねっていました。シャーディングを有効にするために最初に複雑さを追加する必要があり、その結果、レイヤー 2 のスケーラビリティが大幅に向上しました。とはいえ、イーサリアムの歴史が証明しているように、複雑さを軽減することは可能です。