Vitalik の長い記事のレビュー: イーサリアムの「これまでに踏まれなかった道」

吴说

特邀专栏作者

2022-03-30 10:34

この記事は約5838文字で、全文を読むには約9分かかります

イーサリアムにとっての最大の課題は、2 つのビジョンのバランスを取ることにあります。

AI要約

展開

イーサリアムにとっての最大の課題は、2 つのビジョンのバランスを取ることにあります。

原題：「

原題：「The roads not taken》

ウー氏はブロックチェーンについてウー氏はブロックチェーンについて

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

副題

よりシンプルな PoS メカニズムを使用する必要がありますか?

イーサリアムが導入しようとしているGasper PoSメカニズムは複雑なシステムですが、非常に強力なシステムでもあります。そのプロパティには次のようなものがあります。

非常に強力な単一ブロックの確認: トランザクションがブロックに含まれると、通常は数秒以内に、大部分のノードが不正であるか、極端なネットワーク遅延がない限り、ブロックは完了します。これを元に戻すことはできません。
経済的な最終性: ブロックが完了すると、攻撃者が数百万 ETH の損失に耐えて罰金を科せられない限り、ブロックを元に戻すことはできません。
非常に予測可能な報酬: バリデーターはエポック (6.4 分) ごとに確実に報酬を受け取ります。
非常に多くのバリデーター数をサポート: 上記のプロパティを持つ他のほとんどのチェーンとは異なり、イーサリアムビーコンチェーンは数十万のバリデーターをサポートします (例: Tendermint はイーサリアムよりも高速なファイナリティを提供しますが、サポートされるのは数百のバリデーターのみです)

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

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

多くの人は、PoS 自体が複雑であるという誤解を持っていますが、実際には、Satoshi PoW コンセンサスとほぼ同じくらい単純な PoS アルゴリズムがたくさんあります。 NXT の PoS は 2013 年から存在しており、すぐに候補となるはずでした。いくつかの問題はありますが、それらの問題は簡単に修正できるため、2017 年から、あるいは最初から十分に実行可能な PoS を実現できる可能性があります。 Gasper がこれらのアルゴリズムよりも複雑なのは、単純に、これらのアルゴリズムよりもはるかに多くのことを実行しようとしているためです。しかし、最初から目標が高すぎなければ、より限定された目標を達成することに集中することから始めることができます。

副題

シャードの分解

イーサリアムのシャーディングは、2014 年に研究が始まって以来、ますます複雑ではない方向に進んでいます。まず、実行機能とシャード間トランザクションが組み込まれた複雑なシャードがあります。次に、責任の多くをユーザーに移すことでプロトコルを簡素化し、ユーザーは両方のシャードのガス料金を個別に支払う必要があります。その後、次のように切り替えます。ロールアップ中心のロードマップ。プロトコルの観点から見ると、シャードは単なるデータのシャードです。最後に、ダンクシャーディングを通じてシャード料金市場が全体に統合され、最終的な設計は非シャードチェーンのように見えますが、ここではデータ可用性のサンプリングによりシャードの検証が可能になります。

しかし、逆の道を選んだ場合はどうなるでしょうか?実際、より複雑なシャーディングシステムを詳しく調査したイーサリアム研究者もいます。シャードはチェーンとして機能し、子チェーンが親チェーンに依存するフォーク選択ルールがあり、シャード間のメッセージはプロトコル、バリデーターによってルーティングされます。シャード間でローテーションされ、DApp もシャード間で自動的に負荷分散されます。

このアプローチの問題は、これらの形式のシャーディングが主にアイデアと数学モデルであるのに対し、Danksharding は完全でほぼ実装可能な仕様であることです。したがって、イーサリアムの状況と制限を考慮すると、私の意見では、シャーディングの簡素化と曖昧さの解消は間違いなく正しいことです。そうは言っても、より野心的な研究も非常に重要な役割を果たします。それは、有望な研究の方向性を特定し、非常に複雑なアイデアでさえ、しばしば問題を引き起こす可能性があります。"適度にシンプル"副題

EVM での機能の選択

実際、セキュリティ監査を除いて、EVM 仕様は基本的に 2014 年半ばに発表される可能性があります。しかし、その後数か月間、当時私たちは、分散型ブロックチェーンにとって本当に重要であると考えられる新機能を積極的に探索し続けました。 EVM に追加される機能もあれば、追加されない機能もあります。

POST オペコードの追加を検討しましたが、追加しないことにしました。 POST オペコードは非同期呼び出しを行い、トランザクションの完了後に実行されます。
ALARM オペコードの追加を検討しましたが、追加しないことにしました。 ALARM は POST と同様に機能しますが、将来のブロックで非同期呼び出しを実行し、コントラクトが操作をスケジュールできるようにする点が異なります。
ログを追加しました。これにより、コントラクトは状態には影響しないが、DApp インターフェイスとウォレットによって解釈できるレコードを出力できるようになります。 ETH送金でログを出力することも検討しましたが、次の点を理由に見送りました。"いずれにせよ、人々はすぐにスマートコントラクトウォレットに切り替えるでしょう"。
バイト配列をサポートするために SSTORE を拡張することを検討しましたが、複雑さとセキュリティ上の懸念から中止しました。
プリコンパイルを追加しました。これは、ネイティブ実装を使用して特殊な暗号化操作を実行するコントラクトであり、EVM で実行するよりもはるかに安価です。
運用開始後の数か月間、私たちは州の家賃について検討しましたが、それは含まれませんでした。複雑すぎます。現在、より優れた状態有効期限スキームが積極的に検討されていますが、ステートレス検証と提案者/構築者の分離 (PBS) により、現在は優先順位がはるかに低くなります。

現在、機能を追加しないという決定のほとんどは、非常に良い決定であることが判明しています。 POST オペコードを追加する明確な理由はありません。 ALARM オペコードを安全に実装するのは実際には困難です。ブロック 1 ～ 9999 の全員が ALARM を設定し、ブロック 100,000 で大量のコードを実行したらどうなるでしょうか?そのブロックの処理には何時間もかかりますか?スケジュールされた操作の一部は後のブロックにプッシュされますか?しかし、そうなった場合、ALARM はどのような保証を保持するのでしょうか?バイト配列の SSTORE は安全に実行することが難しく、最悪の場合の監視サイズが大幅に拡大します。

副題

LOGの代替手段

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

ETH送金時にLOGを自動送信することができます。これにより、取引所や他の多くのユーザーの多大な労力とソフトウェアのバグの問題が軽減され、全員のLOGへの依存が加速し、スマートコントラクトウォレットの導入が促進されます。
LOG オペコードを完全に省略して、それを ERC に変えることができます。標準コントラクトがあり、これには関数 submitLog があり、イーサリアムデポジットコントラクトの手法を使用して、ブロック内のすべてのログのマークルルートを計算します。 EIP-2929 またはブロック全体のストレージ (TSTORE に相当しますが、ブロック後にクリアされます) を使用すると、これが安くなります。

私たちは最初の選択肢を強く検討しましたが、それを拒否しました。主な理由は、ロギングが LOG オペコードからのみ行われ、その方が簡単であるためです。また、ほとんどのユーザーはオペコードを明示的に使用して転送を記録できるスマートコントラクトウォレットにすぐに移行するだろうと、私たちは非常に誤った予想をしていました。

2 番目のオプションは考慮していませんでしたが、振り返ってみると、それは実際にはオプションでした。 2 番目の方法の主な欠点は、ログを迅速にスキャンするためのブルームフィルターメカニズム (ブルームフィルター) が欠如していることです。しかし、Bloom フィルターメカニズムは遅すぎて DApps には不向きであることが判明したため、現在ではクエリに TheGraph を使用する人が増えています。

全体として、これらのアプローチはいずれも現状よりも優れている可能性があります。 LOG に残さないと作業が簡単になりますが、LOG にあればすべての ETH 送金を自動的に記録するほうが便利です。

副題

現在の EVM がまったく異なる道をたどったらどうなるでしょうか?

当初、EVM には 2 つのまったく異なるパスから選択する必要がありました。

EVM を、変数、if ステートメント、ループなどの組み込み構造を備えた高レベル言語にします。
EVM を既存の仮想マシン (LLVM、WASM など) のコピーにします。

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

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

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

仮想マシンの複数の実装が必要であり、2 つの実装が同じコードを異なる方法で処理しないことが厳密に要求されます。自分が書いていないコードに対してセキュリティ監査や検証を行うのはより困難です。

VM の仕様が変更されると、イーサリアムは常にそれに合わせて更新する必要があり、そうしないと、ますます同期が失われます。

副題

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

ETH の現在の供給量は、Etherscan の次のグラフで大まかに表すことができます。

現在、全 ETH の約半分がイーサリアムパブリックセールで販売されており、誰でもビットコインアドレスに BTC を送信でき、最初の ETH 供給割り当てはオープンソーススクリプトを通じて計算されます。残りのほとんども基本的に同様に採掘されています。黒で「その他」とマークされた 1,200 万 ETH は、実際にはプレマイニングされた部分であり、イーサリアム財団とイーサリアムプロトコルへの初期貢献者約 100 人の間で分配された量です。

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

プレマイニングも公募を担当するイーサリアムファンドも信頼できる中立性を持っていません。一部の受信者アドレスは非公開のプロセスを通じて手動で選択されます。イーサリアム財団は、より多くの ETH を取得するためにローンを通じて公的販売収益をさらに利用しないと信頼されなければなりません (私たちはそうではありませんし、誰も持っているとは主張しませんが、信頼されるという要件さえ侵害されます)一部の人々）。
Premine は非常に初期の貢献者に多大な報酬を与え、後の貢献者にはあまりにも少ないものを残します。プレマイニングの 75% は、オンラインになる前の貢献者の仕事に報酬を与えるために使用され、オンラインになった後、イーサリアム財団には 300 万 ETH しか残っていません。 6 か月間で、生き残るために売却する必要があり、在庫は約 100 万 ETH まで減りました。

ある意味、これらの問題は関連しています。集中化の認識を最小限に抑えたいという願望がプレマインの小型化に貢献しましたが、プレマインが小さくなると排水が早くなります。

これが唯一の解決策ではありません。 Zcash は別のアプローチをとります。ブロック報酬の固定 20% が、4 年ごとに再交渉されるプロトコルでハードコーディングされた受信者のセットに割り当てられます (これまでのところ、これは 1 回発生しています)。これはより持続可能ですが、中央集権的すぎるということでより厳しく批判されるでしょう（Zcashコミュニティは、イーサリアムコミュニティよりも多くの技術者のリーダーシップをよりオープンに受け入れているようです）。

考えられる代替パスは、今日の一部の DeFi プロジェクトで人気のあるものと似ています。"DAO from day 1"ルート。考えられるストローマンの提案は次のとおりです。

各ブロック報酬から 2 ETH を 2 年間開発基金に割り当てることに同意します。
イーサリアムの一般販売で ETH を購入する人は誰でも、好みの開発資金の割り当てに投票できます (例:"各ブロックの報酬では、1ETHがイーサリアム財団に、0.4ETHがConsensys研究チームに、0.2ETHがVlad Zamfirに与えられます..."）
投票された受信者は、各人の投票の中央値に等しい開発基金のシェアを受け取り、ブロックごとに合計 2ETH に相当する日割り計算されます (中央値は自己取引を防ぐためのものです。自分に投票した場合、それ以下のものは何も得られません。他の購入者の少なくとも半数があなたに言及します）。

一般販売は、一般販売中に受け取ったビットコインをETH開発基金と同じ割合で分配する（あるいは、本当にビットコイナーを満足させたい場合は燃やす）ことを約束する法人によって運営される可能性があります。これは、信頼できる中立性を少しも損なうことなく、イーサリアム財団への多額の資金提供、およびイーサリアム財団以外のグループへの多額の資金提供（エコシステムのさらなる分散化につながる）につながる可能性があります。もちろん、主な欠点は、トークン投票が本当に最悪であるということですが、実際的には、2014 年はまだ初期で理想的な時期であり、トークン投票の最悪のマイナス面は一般販売が終了してからずっと後に来ることがわかります。

副題

このすべてから何を学べるでしょうか?

一般に、イーサリアムの最大の課題は、セキュリティとシンプルさを重視するブロックチェーンと、高度なアプリケーションを構築するための高性能で機能的なプラットフォームという 2 つのビジョンのバランスをとることにあると感じることがあります。上記の例の多くは 1 つの側面にすぎません。機能が少なくてもビットコインに似ているのでしょうか、それとも機能が増えて開発者に優しいのでしょうか?私たちは開発資金をより中立的に、ビットコインのようにすることを心配しているのでしょうか、それともそもそもイーサリアムを改善するのに十分な報酬を開発者に確実に与えることを心配しているのでしょうか?

私の個人的な夢は、両方のビジョンを同時に達成することです。仕様が毎年前年よりも小さくなる基本レイヤーと、レイヤー 2 プロトコルを中心とした高度なアプリケーションの開発者に優しい堅牢なエコシステム。つまり、そのような理想的な世界に到達するには長い時間がかかるので、これには時間がかかる、段階的にルート計画を検討する必要があるということをより明確に認識できると、非常に役立つかもしれません。

現在、変更できないことはたくさんありますが、まだ変更できることも多く、機能性とシンプルさの向上への確かな道はまだあります。場合によっては、その道は曲がりくねっています。シャーディングを有効にするには、まず複雑さを追加する必要があります。これにより、その上に多くのレイヤー 2 スケーラビリティが有効になります。とはいえ、複雑さを軽減することは可能であり、イーサリアムの歴史がそれを証明しています。