Vitalik の新しい記事の解釈: BLOB 領域が効率的に使用されていない Rollup はなぜ開発困難に陥るのか?

@VitalikButerin のイーサリアムの拡張に関する新しい記事の考えを理解するにはどうすればよいですか?ヴィタリックのブロブ碑文の命令はとんでもないという人もいる。

それでは、Blob パケットはどのように機能するのでしょうか?カンクンのアップグレード後に BLOB スペースが効率的に使用されないのはなぜですか?シャーディングの準備として DAS データの可用性をサンプリングしますか?

私の意見では、Cancun のパフォーマンスはアップグレード後も使用できるため、Vitalik は Rollup の開発を心配しています。なぜ？次に、私の理解について話させてください:

前に何度も説明したように、Blob は EVM コールデータから切り離された一時データ パッケージであり、コンセンサス層によって直接呼び出すことができます。 EVM はトランザクションの実行時に BLOB データにアクセスする必要がないため、実行層のコンピューティング コストが削減されます。

現在、一連の要素のバランスをとっており、1 BLOB のサイズは 128k で、メイン ネットワークへの Batch トランザクションは最大 2 つの BLOB を運ぶことができます。理想的には、メイン ネットワーク ブロックの最終目標は次のとおりです。 16MB 約 128 個の BLOB パケットを伝送します。

したがって、ロールアップ プロジェクト チームは、BLOB スペースを最適な状態で使用することを目標に、Blob ブロックの数、TPS トランザクション容量、Blob メイン ネットワーク ノードのストレージ コストなどの要素のバランスを可能な限り調整する必要があります。コストパフォーマンス。

「Optimism」を例にとります。現在、1 日に約 500,000 件のトランザクションが発生しています。平均すると、トランザクションは 2 分ごとにメイン ネットワークにバッチ処理され、一度に 1 つの BLOB データ パケットが送信されます。なぜ 1 つ持ち運ぶのでしょうか? 使い切れない TPS の数が限られているためです。もちろん、2 つ持ち運ぶこともできます。そうすると、各 BLOB の容量がいっぱいになることはありませんが、ストレージ コストが増加するため、不必要です。

ロールアップ チェーンからのトランザクションの量が増加した場合 (たとえば、毎日 5,000 万のトランザクションが処理される場合)、どうすればよいでしょうか? 1. Compress は各 Batch のトランザクション ボリュームを圧縮し、Blob 領域でできるだけ多くのトランザクションを許可します。2. BLOB の数を増やします。3. Batch トランザクションの頻度を短縮します。

2)メイン ネットワークのため、ブロックによって伝送されるデータの量は、ガス制限とストレージ コストの影響を受けます。ブロックあたり 128 個の BLOB が理想的な状態です。現在、それほど多くのブロブは使用していません。楽観主義では 2 分ごとに 1 個だけを使用し、そのままにしておきますTPS を改善し、拡大するためのレイヤー 2 プロジェクトへの移行 市場のユーザー数と生態学的繁栄にはまだ多くの余地があります。

したがって、カンクンのアップグレード後の一定期間、ロールアップは、使用される BLOB の数と頻度、および BLOB スペース入札の使用量の点で「ボリューム」がありませんでした。

Vitalik が Blobscription の碑文について言及した理由は、このタイプの碑文によりトランザクション量が一時的に増加する可能性があり、それが BLOB の使用需要の増加につながり、量が拡大するためです。ブロブの動作メカニズムについてのより深い理解を提供します。ヴィタリックは本当に私が表現したいことは碑文とは何の関係もありません。

理論上、メイン ネットワークに対して高頻度かつ大容量のバッチ トランザクションを実行し、耐える意思がある限り、毎回 Blob ブロックを埋めるレイヤー 2 プロジェクト パーティが存在する場合、偽造されたトランザクション バッチの高コスト。他のレイヤー 2 による Blob の通常の使用に影響しますが、現在の状況では、誰かがコンピューティング パワーを購入して BTC に対して 51% のハード フォーク攻撃を実行するのと同じように、理論的には実現可能ですが、実際には利益動機が欠如している。

したがって、第 2 層のガスコストは長期間にわたって「低い」範囲で安定し、これにより第 2 層市場に「兵力と食料の増加」という長期にわたる黄金の開発期間が与えられることになります。 。

3) それでは、ある日、レイヤー 2 市場がある程度繁栄し、Batch からメイン ネットワークへのトランザクション数が毎日膨大な量に達したらどうなるでしょうか。 BLOB データ パケットだけでは十分ではありませんか?イーサリアムはすでにソリューションを提供しています: データ可用性サンプリング技術 (DAS) を使用:

単純に理解すると、本来 1 つのノードに保存する必要があるデータを同時に複数のノードに分散できることを意味します。たとえば、各ノードはすべての Blob データの 1/8 を格納し、DA 機能を満たすために 8 つのノードがグループを形成します。これは、現在の Blob ストレージ容量を 8 倍に拡張することに相当します。これは実際にシャーディングが将来行うことです。

しかし今、Vitalik はこれを何度も、非常に魅力的に繰り返しており、レイヤー 2 プロジェクト関係者の大多数に警告しているようです: 「イーサリアムの DA 容量が高価であると常に不平を言う必要はありません。現在の TPS 容量では、 Blob データパケットの容量が開発されていないため、極論を言えば、急いで火力を上げてエコシステムを開発し、ユーザーとトランザクション量を拡大する必要があります。ワンクリックチェーン作成に従事するために DA が逃げることを常に考えている必要はありません。

その後、Vitalik 氏は、現在のコア ロールアップの中でステージ 1 に到達したのは Arbitum だけであると付け加えました。@DeGateDex、Fuel などはステージ 2 に到達しましたが、より広範なグループにはまだ馴染みがありません。ステージ 2 はロールアップ セキュリティの最終目標です。ステージ 1 に到達したロールアップはほとんどなく、ほとんどのロールアップはステージ 0 にあります。ロールアップ業界の発展が Vitalik を本当に心配していることがわかります。

4) 実際、拡張ボトルネックの問題に関しては、ロールアップ層 2 ソリューションでパフォーマンスを向上させる余地がまだたくさんあります。

1. データ圧縮を通じて Blob 領域をより効率的に使用します。OP-Rollup には現在、この作業を実行する専用のコンプレッサー コンポーネントがあります。ZK-Rollup 独自のオフチェーン圧縮 SNARK/STARK 証明は、メイン ネットワーク。「圧縮中」です;

2. レイヤー 2 のメイン ネットワークへの依存をできる限り減らし、特別な状況下で L2 セキュリティを確保するために楽観的証明技術のみを使用します。たとえば、プラズマのデータのほとんどはチェーン上にありますが、入金と引き出しのシナリオでは、それはメインネットワークです. が発生するため、メインネットはセキュリティを約束できます。

これは、レイヤー 2 がメイン ネットワークに関連性の高い入出金などの重要な操作のみを考慮する必要があることを意味し、これによりメイン ネットワークの負荷が軽減されるだけでなく、L2 自体のパフォーマンスも向上します。前述のシーケンサーの並列処理機能、オフチェーン スクリーニング、多数のトランザクションの分類と前処理、さらに @MetisL2 が推進するハイブリッド ロールアップ、OP-Rollup を介した通常のトランザクション、ZK Route を介した特別な出金リクエスト、などはすべて同様の考慮事項があります。

上記

イーサリアムの将来の拡張計画について考えるVitalikの記事は非常に啓発的であると言わなければなりません。特に、レイヤー 2 の現在の開発状況に不満を持ち、Blob のパフォーマンス空間については楽観的であり、将来のシャーディング技術に期待しており、最適化する価値のあるレイヤー 2 の方向性についても指摘しました。

実際のところ、現時点で唯一の不確実性はレイヤー 2 自体に残されています。開発を加速するにはどうすればよいでしょうか?

以上がVitalik の新しい記事の解釈: BLOB 領域が効率的に使用されていない Rollup はなぜ開発困難に陥るのか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。