イーサリアムの断片化設計の歴史: 「ブロック」から「ブロブ」まで

元のソース:@protolambda によるツイート

「ブロック」から「ブロブ」まで、その意味は奥深いです。

「ブロック」から「ブロブ」まで、その意味は奥深いです。

「クロスリンク」を備えた実行可能な「シャード チェーン」が登場: ビーコン チェーンでの EVM 実装、「データ可用性サンプリング」を使用したロールアップ中心の Ethereum ロードマップ、アプリケーション環境の複雑さを増加させることなく Ethereum ベース レイヤをスケーリング。しかし、ブロック メタデータなしでシャード コンテンツを呼び出すにはどうすればよいでしょうか?

さて、ここで「blob」が役に立ちます。 「ブロブスペース」って素敵な名前ですね！

イーサリアムのシャーディング設計の歴史をいくつか共有しましょう。

シャーディング (または「フェーズ 1」) は、以前の計画どおり「フェーズ 2」 (ビーコン チェーン実行環境) で開始される予定でした。しかし、「フェーズ 0」(ビーコン チェーンの起動) の前に、メインネット EVM が優先される一方、「フェーズ 2」実行層 (ewasm?) の展開はどこにも見えないことが明らかになります。

「フェーズ 1」仕様は、ビーコン チェーンの前に数回書き直されました。

• シャードの減少 (1024 -> 64)

• 理想的なクロスシャード通信 (クロスリンク) によるフリーライド

• 新しいエスクロープルーフ設計 (まれな意図的なプルーフロスを考慮してエスクロー部分を削除)

以前のシャーディングの研究作業については言うまでもありませんが、正直に言うと、これらの研究は非常に抽象的で野心的です。クロスドメインのメッセージ パッシング、ewasm を使用した実行環境、ステートレスな動的アクセス、シャーディング委員会などです。L1 はさらに複雑になります。そしてL1は骨化し始めています。

ただし、L1 がデータの問題の解決のみに焦点を当てている場合、上記の問題のほとんどは L2 の開発問題に変換されます。そして、サンプリング（サンプリング）は L1 データの問題を解決するだけです。ネットワーク層で追加機能をサポートできたらどうなるでしょうか...?

そこで2020年10月14日、開発者らは「フェーズ1のネットワーク接続の問題（ネットワーキング）」に関する電話会議を行った。議論の結果、gossipsub は非常にホットで、DHT は遅いと結論付けることができます。しかし、当時はまだ黎明期で、Web 開発者はまだビーコン チェーンの立ち上げ (12 月 1 日!) の準備で忙しく、当時の最新の開発により、ネットワーク層には明らかなギャップがありました。

当時の偏見：

• Gossipsub = ホット、メインネットの準備完了 (一部の DoS 問題を除いて、それほど問題はありません。また、これらの問題もメインネットの開始前に発見/開示されました)

• Discv5 = 不完全、メインネットの立ち上げ前に 5.0 から 5.1 へのライブ ネットワーク マイグレーションが必要

(https://github.com/protolambda/discv5-catdog)

しかし、方向性は明確のようです。ビーコン チェーンはすでに十分に複雑であるため、L1 の複雑さを軽減します。データのみを通じてスケーラビリティを向上させ、長期的には「データ可用性サンプリング」スキームを使用し、L2 拡張ソリューションを採用します。したがって、Vitalik氏はこれを「ロールアップを中心としたイーサリアムロードマップ」（中国語版）と説明しました。

しかし、実装者がビーコン チェーンのリリースで忙しい一方で、研究者はすでに起動後の作業で忙しかったです。Vitalik と Dankrad は初期のデータ可用性設計草案に取り組んでおり、実装者が原理を理解しやすくすることに努めていました。

同時に、Zinken、Toledo、Pyrmont のテストネットを起動し、さらに多くの起動項目をチェックしました (バグのチェックなど)。そして、私たちは研究を続けて、ネットワーク層の設計ドキュメントを追加し始めるように努めています。当時、これらの問題に焦点を当てるのは時期尚早でしたが、DAS (データ可用性サンプリング) は無視するには優れていました。

gossipsub からの情報に基づいて、DAS に使用するためのアイデアをいくつか書きました。今にして思えば、おそらく初期配布を除いて、DHT は Gossipsub よりも DAS に適していると思います。

当時、私はいくつかの DAS 仕様が実装され、シミュレーションされることを期待していました。 「ブロブ」について言及されたのはこれが初めてだと思いますか？ 「シャードされたデータ BLOB」などのコンテキストでこの用語を使用していましたが、当時その用語はシャーディングの仕様には登場していませんでした。

ビーコン チェーンがリリースされた後、さらに時間ができたので、Vitalik と Dankrad が書いたサンプル仕様草案にさらにタイピングとネットワーク層のコンテンツを追加した草案を書きました。 BLOB の名前をシャードの仕様に組み込みます:)

2021 年にいくつかのことが変わりました。そのために設計された理想的な p2p 構造は複雑すぎたので、代わりにそれにツールを提供したり (go-kzg)、初期のマージ活動 (rayonism) に参加したりすることにしました。その後、夏には、Altair/London アップグレードの開発に取り組む代わりに、シャーディングに関する研究作業に参加してみてください。

BLOB が再び取り組んでおり、今回はより PBS に似た構造になっており、BLOB ビルダーと BLOB プロポーザーの BLS 署名を集約しています。まだ複雑すぎます。したがって、シャーディング設計は主に「ビーコン提案者中心」になるように進化し、ネットワーク層「のみ」の問題になりました。

これはある意味、シャーディングの 5 番目のデザインのようなものですか?ミニマリズムとは多くのことを放棄することですが、その結果は、よりモジュール化されたデザイン、パッケージング、オプションの複雑さなど、美しく強力なものになります。ロールアップ、特に楽観主義が私の注意を引きました。

2022 年末、EIP 4488 (4844 ではなく、混同しないでください!) と 4490: 人々は焦り始めており、競争力を維持するには通話データのコストを迅速に下げる必要があります。ロンドンでのアップグレード後、All Core devs でもこれらのトピックに関する議論が活発になりました。しかし、私の意見では、calldata には L2 に必要のない従来のオーバーヘッドが伴うため、これは持続不可能です。

一方、Vitalik と Dankrad は、ビーコン チェーン中心、データのみによるスケーリング、サンプリング スキームに重点を置いた、いくつかの新しいシャーディング設計に引き続き取り組んでいます。 「ダンクシャーディング」は本当に 21 年の終わりか 22 年の初めに発売されたと思いますか?最初のバージョンが何だったのかはわかりませんが、Dankrad はシャーディングに取り組んでいます。

22 年の初めに、Vitalik は、サンプリングを使用せずに完全なダークシャーディングに向けて開発できる 2 つの方法、つまり単純なバージョンと複雑なバージョンを提案しました。私の考えでは、これは実際には「重い EL (実行層)」と「容易さと将来の互換性を目的とした EL と CL の分離」の違いです。

私は 2 番目のオプションが気に入っており、EthDenver 2022 中に EIP-4844 を実装しました: 私と @lightclients は Geth に取り組み、@asn_d6 は KZG を支援し、@adietrichs は手数料市場に取り組み、両者とも Vitalik/Dankrad Draft と EIP を実装しました。 Prysm チームは最初の CL プロトタイプを構築しました。

4844 という名前が付けられました"proto-danksharding": 完全なシャーディングを実現するための前提条件。しかし、「ブロブスペース」こそが本当のミームです。シャーディングの設計を何度も繰り返した結果、これは他のどのシャーディング設計よりもイーサリアムのビジョンに近づいたバージョンです。

私にとって、Serenity のこの段階は、PoS とシャード設計、および反復的な更新がすべてです。ビーコン チェーンやオフプロトコル PBS などの開発である程度の進歩があり、PoS では良いスタートを切ることができました。最初のシャード アップグレードの時期が来たと思います: 4844!

将来のダークシャーディングのホットスポットもいくつかあります。

• L1 データ包含レイテンシが L2 に与える影響は過大評価されています。

• 設計スペースのトレードオフでは、データ可用性の帯域幅を増やす価値があります。

• ゴシップと TCP DHT は悪く、UDP DHT クラスのカバレッジは良好です。重要なのはライト ノードの数をカウントすることです (discv5 はいつスケール アウトしますか?)

ダンクシャルディングのその他のホットスポット:

• サンプリングは優れたピアに大きく依存しているため、よりスコア優先で堅牢な設計が望まれます。

• p2p よりもバリデーターのプライバシーが欠如するよりも、軽量の通信とより多くの Sybil を好みます。

• ZK は将来の p2p 対魔女技術になる可能性がありますが、それは今では遠い先のことのようです。