共有する

Vitalikの長文レビュー：あのイーサリアム「歩まなかった道」

ヴィタリック

2022-03-30 13:14:36

コレクション

イーサリアムの最大の課題は、セキュリティとシンプルさを重視した純粋なブロックチェーンと、高度なアプリケーションを構築するための高性能で機能的なプラットフォームという二つのビジョンの間のバランスを取ることです。

著者：Vitalik、イーサリアム創設者

原題：《The roads not taken》

翻訳：Mary Ma、吴说区块链

イーサリアム開発コミュニティは、イーサリアムの初期段階で多くの決定を下しました。これらの決定はプロジェクトの発展の軌跡に大きな影響を与えました。場合によっては、イーサリアムの開発者は意識的に決定を下し、私たちがビットコインに問題があると考える場所で改善を行いました。他の場所では、私たちは全く新しいものを創造しており、空白を埋めるために何かを考え出さなければならず、選択肢はたくさんあります。また、より複雑なものとよりシンプルなものの間でトレードオフを行う必要がある場所もあります。時には、私たちは比較的シンプルなものを選びますが、時には、より複雑なものを選ぶこともあります。

この記事では、私の記憶に残るイーサリアムのこれらの分岐点に焦点を当てます。これらの機能の多くはコア開発サークル内で真剣に議論されましたが、ほとんど考慮されなかったものもあり、実際には考慮されるべきかもしれません。それでも、異なるイーサリアムがどのようなものになるか、そして私たちがそこから何を学べるかを見てみる必要があります。

よりシンプルな PoS メカニズムを採用すべきか？

イーサリアムが間もなく統合するGasper PoS メカニズムは、複雑なシステムですが、非常に強力なシステムでもあります。そのいくつかの特性には以下が含まれます：

非常に強力な単一ブロック確認：一度取引がブロックに組み込まれると、通常数秒以内にそのブロックは最終確認され、ノードの大部分が不誠実でない限り、または極端なネットワーク遅延がない限り、逆転することはできません。

経済的最終性：一度ブロックが最終確認されると、それは逆転することはできません。攻撃者が数百万ETHを失うことに耐えられる場合を除いて。
非常に予測可能な報酬：検証者は各エポック（6.4分）ごとに信頼性のある報酬を得ることができます。
非常に高い検証者数のサポート：上記の特性を持つ他のほとんどのチェーンとは異なり、イーサリアムのビーコンサインは数十万の検証者をサポートしています（例：Tendermintはイーサリアムよりも速い最終性を提供しますが、数百の検証者しかサポートしていません）。

しかし、これらの特性を持つシステムを作成することは困難です。数年の研究、数年の失敗した実験が必要であり、通常は多大な努力を要し、最終的な出力はかなり複雑です。

もし私たちの研究者がそれほど多くのコンセンサスを心配する必要がなく、もっと自由に考える時間があれば、もしかしたら、rollupsは2016年に発明されていたかもしれません。これが私たちに考えさせるのは、私たちは本当にPoSに対してそんなに高い基準を要求すべきなのでしょうか？なぜなら、よりシンプルで弱いPoSでさえ、PoWの現状よりも大きな改善をもたらすからです。

多くの人々は、PoS自体が非常に複雑であるという誤解を持っていますが、実際には多くのPoSアルゴリズムは中本聡のPoWコンセンサスとほぼ同じくらいシンプルです。NXTのPoSは2013年から存在しており、実際には既存の候補でした；いくつかの問題はありますが、それらは簡単に修正でき、2017年、さらには最初から合理的に実行可能なPoSを持つことができました。Gasperがこれらのアルゴリズムよりも複雑なのは、単にそれが達成しようとしているタスクがはるかに多いからです。しかし、最初から高望みをしなければ、より限られた目標を達成することに集中することができます。

私の見解では、最初からPoSを実装することは間違いでした；PoWは初期発行量の分配を拡大し、イーサリアムをよりアクセスしやすくするのに役立ち、愛好者コミュニティを奨励することができました。しかし、2017年、さらには2020年に、よりシンプルなPoSに切り替えることは、環境破壊を減少させ（環境破壊による反暗号通貨の心情も含む）、より多くの研究者が拡張問題について自由に考えることができるようになる可能性がありました。私たちは最終的に、より良いPoSを作るために多大なリソースを費やさなければならないのでしょうか？私はそうなると思いますが、今のところ、いずれにせよ、私たちは最終的にそうすることになるでしょう。

シャーディングの簡素化

イーサリアムのシャーディングは2014年から研究が始まり、ますます簡素化の方向に進んでいます。最初は、内蔵実行とクロスシャード取引の複雑なシャーディングがありました；次に、ユーザーにより多くの責任を移すことでプロトコルを簡素化し、クロスシャード取引では、ユーザーはそれぞれのシャードに対してガス料金を支払わなければなりませんでした；その後、私たちはRollup中心のロードマップに切り替え、プロトコルの観点から見ると、シャーディングは単なるデータシャーディングに過ぎません。最後に、dankshardingを通じて、シャーディング料金市場が統合され、最終的な設計は非シャーディングチェーンのように見えますが、ここではデータ可用性サンプリングがシャーディング検証を実現します。

しかし、もし私たちが逆の道を進んでいたらどうなっていたでしょうか？実際には、イーサリアムの研究者の中には、より複雑なシャーディングシステムを深く探求している人々もいます：シャーディングはチェーンとして機能し、分岐選択ルールがあり、サブチェーンは親チェーンに依存し、クロスシャードメッセージはプロトコルによってルーティングされ、検証者はシャード間でローテーションし、さらにはDAppがシャード間で自動的に負荷分散されるというものです。

このアプローチの問題は、これらの形式のシャーディングは大部分がアイデアと数学モデルに過ぎず、Dankshardingは完全でほぼ実装可能な仕様であるということです。したがって、イーサリアムの状況と制約を考慮すると、シャーディングの簡素化と曖昧さの除去は絶対に正しい選択です。つまり、より野心的な研究も非常に重要な役割を果たします：それは有望な研究方向を特定し、非常に複雑なアイデアでさえ「合理的にシンプル」なバージョンを持ち、これらのアイデアは多くの利点を提供し、今後数年間でイーサリアムの発展（さらにはレイヤー2プロトコル）に大きな影響を与える可能性が高いです。

EVMにおける機能の選択

実際には、セキュリティ監査を除けば、EVMの仕様は基本的に2014年中頃にリリース可能でした。しかし、その後の数ヶ月間、私たちは去中心化ブロックチェーンにとって本当に重要であると考えられる新機能を積極的に探求し続けました。いくつかの機能はEVMに追加され、いくつかは追加されませんでした。

私たちはPOSTオペコードを追加することを検討しましたが、決定しませんでした。POSTオペコードは非同期呼び出しを行い、取引が完了した後に実行されます。

私たちはALARMオペコードを追加することを検討しましたが、決定しませんでした。ALARMの機能はPOSTに似ており、将来のブロックで非同期呼び出しを実行し、契約が操作をスケジュールできるようにします。

私たちはログ（logs）を追加しました。これにより、契約は状態に触れずに記録を出力でき、DAppインターフェースやウォレットによって解釈されることができます。注目すべきは、ETHの転送がログを発行することを許可することも検討しましたが、「人々はすぐにスマートコントラクトウォレットに移行するだろう」という理由で決定しませんでした。

私たちはSSTOREを拡張してバイト配列をサポートすることを検討しましたが、複雑性とセキュリティの懸念から決定しませんでした。
私たちはプレコンパイル（precompiles）を追加しました。これは、ネイティブ実装を使用して専用の暗号操作を実行する契約であり、EVM内で実行するよりもはるかに安価です。
ローンチ後の数ヶ月間、私たちは状態レンタル（state rent）を繰り返し検討しましたが、決して含めませんでした。これはあまりにも複雑でした。今日、人々はより良い状態の期限切れ（state expiry）ソリューションを積極的に探求していますが、無状態検証と提案者/構築者の分離（PBS）により、現在ははるかに優先度が低くなっています。

今振り返ると、機能を追加しないという決定のほとんどは非常に良い決定であったことが証明されています。POSTオペコードを追加する明確な理由はありません。ALARMオペコードは実際には安全に実装するのが非常に難しいです：もし1…9999ブロックのすべての人がALARMを設定した場合、100000ブロックで大量のコードが実行されるとどうなりますか？そのブロックは処理に数時間かかるのでしょうか？いくつかの予定された操作は後のブロックに押しやられるのでしょうか？しかし、もしそのようなことが起こった場合、ALARMは何の保証を保持できるのでしょうか？バイト配列のSSTOREは安全に行うのが難しく、最悪の場合の証人サイズを大幅に拡大します。

状態レンタルの問題はさらに挑戦的です：もし私たちが初日から本当に何らかの状態レンタルを実装していたなら、イーサリアムは常に持続可能な状態の正規化仮定の周りで発展する必要はなかったでしょう。イーサリアムは構築が難しくなるかもしれませんが、より拡張性と持続可能性を持つ可能性があります。同時に、当時の私たちの状態期限切れの計画は、現在のものよりもはるかに劣っていました。時には、良いアイデアは数年の時間を要するものであり、他に良い方法はありません。

LOGの代替案

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

ETHの転送が自動的にLOGを発行するようにすることができます。これにより、取引所や多くの他のユーザーは膨大な労力とソフトウェアエラーの問題を節約でき、全員がLOGに依存する速度が加速され、スマートコントラクトウォレットの採用に役立ちます。
LOGオペコードを完全に必要とせず、ERCに変えることができます：標準契約があり、submitLogという関数を持ち、イーサリアムのデポジット契約の技術を使用して、そのブロック内のすべてのログのMerkleルートを計算します。EIP-2929やブロック範囲のストレージ（TSTOREに相当しますが、ブロック後にクリアされる）により、これが安価になります。

私たちは第一の方法を強く検討しましたが、拒否しました。主な理由は、ログはLOGオペコードからのみ発生するため、より簡単だからです。また、私たちは非常に誤って、ほとんどのユーザーがすぐにスマートコントラクトウォレットに移行するだろうと予測しました。これにより、オペコードを使用して転送を記録することが明確にできます。

私たちは第二の方法を考慮しませんでしたが、振り返ってみると、実際には選択肢でもありました。第二の方法の主な欠点は、迅速にログをスキャンするためのブルームフィルターメカニズム（Bloom filter）が欠如していることです。しかし、ブルームフィルターメカニズムは非常に遅く、DAppにとっては使いにくいことが判明したため、現在ではますます多くの人々がTheGraphを使用してクエリを行っています。

全体として、これらの方法のいずれかは現状よりも優れている可能性があります。LOGを含めないことは物事を簡素化しますが、LOGを含めることで、すべてのETHの移転を自動的に記録することは、より有用にします。

今日、私は最終的にEVMのLOGオペコードを廃止することに賛成するかもしれません。

もし現在のEVMが全く異なる道を選んでいたらどうなっていたか？

当初、EVMには非常に異なる2つの道がありました：

EVMを変数、if文、ループなどの組み込み構造を持つより高級な言語にする。
EVMを既存の仮想マシン（LLVM、WASMなど）のコピーにする。

最初の道は本当に考慮されたことはありませんでした。この道の魅力は、コンパイラをよりシンプルにし、より多くの開発者が直接EVMでコーディングできるようにすることです。また、ZK-EVMの構造をよりシンプルにすることもできます。この道の弱点は、EVMコードが構造的により複雑になることです：それはもはや単純なオペコードのリストではなく、何らかの方法で保存しなければならないより複雑なデータ構造になります。つまり、私たちは両方の利点を持つ機会を逃しました：EVMのいくつかの変更は、基本的なEVM構造を維持しながら多くの利益をもたらすことができます：動的ジャンプを禁止し、サブルーチンをサポートすることを目的としたいくつかのオペコードを追加する（別の参照：EIP-2315）、32バイトのワード境界でのみメモリにアクセスを許可するなど。

第二の道は何度も提案され、何度も拒否されました。それを支持する議論は通常、既存の言語（C、Rustなど）からプログラムをEVMにコンパイルできるようにするというものでした。反対の意見は、イーサリアムの独特の制約を考慮すると、実際には何の利益ももたらさないというものでした：

既存の高級言語のコンパイラは、全体のコードサイズを気にしないことが多く、ブロックチェーンコードは各バイトのコードサイズを減らすために大幅に最適化する必要があります。

私たちは仮想マシンの多様な実装が必要であり、厳密に2つの実装が同じコードを異なる方法で処理しないように要求します。私たちが書いていないコードに対してセキュリティ監査と検証を行うのはより難しくなります。

もし仮想マシンの仕様が変更されると、イーサリアムは常にそれに合わせて更新しなければならず、ますます非同期になってしまいます。

したがって、EVMは私たちが今日持っているものとは全く異なる実行可能な道を持たないかもしれませんが、ジャンプ、64ビット対256ビットなどの多くの小さな詳細が異なる方法で行われれば、より良い結果をもたらすでしょう。

ETH供給は異なる方法で配分されるべきか？

現在のETH供給量は、Etherscanのこの図で大まかに示すことができます：

現在、約半分のETHはイーサリアムの公募で販売されており、誰でもBTCをビットコインアドレスに送信できます。最初のETH供給配分はオープンソーススクリプトによって計算されました。残りの大部分は基本的にマイニングによって生産されました。黒い部分の1200万ETHは「other」としてマークされていますが、実際にはプレマイニング部分であり、イーサリアム財団と約100人のイーサリアムプロトコルの初期貢献者の間で配分された額です。

このプロセスには2つの主要な批判があります：

プレマイニングとイーサリアム財団が公募資金を管理することは、信頼できる中立性を持っていません。一部の受取人アドレスは、閉じられたプロセスを通じて人工的に選ばれ、イーサリアム財団は信頼されなければならず、公募の収益をさらに利用してより多くのETHを得るために貸し出すことはできません（私たちはそうしていませんし、誰もそうしているとは主張していませんが、信頼される要求でさえも一部の人々を冒犯しました）。
プレマイニングは非常に初期の貢献者に過剰に報酬を与え、後の貢献者にはあまりにも少ないです。75％のプレマイニングは、ローンチ前の貢献者の仕事を報いるために使用され、ローンチ後にはイーサリアム財団に300万ETHしか残っていませんでした。6ヶ月の間に、生存のために販売された需要は供給を約100万ETHに減少させました。

ある意味で、これらの問題は関連しています：中心化の見方をできるだけ減らすことが、小さなプレマイニングを促進しましたが、小さなプレマイニングはより早く枯渇します。

これは唯一の解決策ではありません。Zcashは異なるアプローチを採用しました：ブロック報酬の20％が、プロトコルにハードコーディングされた受取人のグループに固定配分され、このグループは4年ごとに再交渉されます（これまでにこの状況は1回発生しました）。これはより持続可能ですが、過度に中心化されているため、より厳しい批判を受けることになります（Zcashコミュニティはイーサリアムコミュニティよりも多くの技術専門家のリーダーシップをより公然と受け入れているようです）。

可能な代替経路は、今日のいくつかのDeFiプロジェクトで人気のある「DAO from day 1」ルートのようなものです。ここに可能なストローマン提案があります：

私たちは、2年間にわたって、各ブロック報酬から2ETHを開発基金に分配することに同意します。
イーサリアム公募でETHを購入した人は、彼らが好きな開発基金に投票を割り当てることができます（例：「各ブロック報酬の1ETHをイーサリアム財団に、0.4ETHをConsensys研究チームに、0.2ETHをVlad Zamfirに…」）。
投票で支持された受取人が得る開発基金のシェアは、各人の投票の中央値に等しく、比例配分され、合計は各ブロック2ETHに等しくなります（中央値は自己取引を防ぐためです：自分に投票すると、他の購入者の中で少なくとも半数があなたに言及しない限り、何も得られません）。

公募は法的実体によって運営され、ETH開発基金の相同比率で公募プロセスで受け取ったビットコインを配分することを約束します（または、焼却します。もし本当にビットコインプレイヤーを喜ばせたいのであれば）。これにより、イーサリアム財団は大量の資金を得ることができ、イーサリアム財団以外の団体も大量の資金を得ることができ（これによりエコシステムがより去中心化されます）、すべてが信頼できる中立性を一切損なうことはありません。もちろん、主な欠点は、トークン投票が本当にひどいことですが、現実的に言えば、2014年はまだ初期で理想的な時期であり、トークン投票の最も深刻な欠点は公募が終了した後に長い時間が経ってから現れることになります。

これを行うことは、より良いアイデアであり、より良い前例を確立することになるのでしょうか？おそらく！現実的な観点から見ると、たとえ開発基金が完全に信頼できる中立的なものであっても、今日イーサリアムのマイナーに対して叫んでいる人々は、DAOのフォークが始まるときに逆に叫び始める可能性が高いです。

私たちはこれらすべてから何を学べるか？

全体として、時にはイーサリアムの最大の課題は、2つのビジョンの間のバランスにあると感じます：安全性とシンプルさを重視するブロックチェーンと、高度なアプリケーションを構築するための高性能で機能的なプラットフォーム。上記の多くの例はその一側面に過ぎません：私たちは機能が少ないビットコインのようなものを持つべきか、それともより多くの機能を持ち開発者に適したものを持つべきか？私たちは開発資金をより中立にすることを心配すべきか、それともまず開発者が十分な報酬を得てイーサリアムをより良くすることを確保することを心配すべきか？

私個人の夢は、これら2つのビジョンを同時に実現しようとすることです。毎年仕様が前の年よりも小さくなる基盤層と、レイヤー2プロトコルを中心にした強力で開発者に優しい高度なアプリケーションエコシステム。つまり、こうした理想的な世界に到達するには長い時間がかかりますが、これに時間がかかることをより明確に認識し、段階的にルート計画を考えることができれば、私たちにとって大きな助けになるかもしれません。

今日、私たちが変えられないことはたくさんありますが、私たちがまだ変えられることもたくさんあり、機能とシンプルさを改善するための堅実な道があります。時にはこの道は曲がりくねっています：私たちはまずシャーディングを実現するためにいくつかの複雑さを追加する必要があり、シャーディングはその上に大量のレイヤー2の拡張性を実現します。つまり、複雑さを減少させることは可能であり、イーサリアムの歴史はこれを証明しています。