イーサリアムには、拡大するロールアップエコシステムのコンピューティング負荷を軽減する簡単な方法があるかもしれない

BLOB 回復の役割をノード間で分割するイーサリアムのプロトタイプでは、1,000 ノードのシミュレーション全体で推定再構築コンピューティング作業量が 11 ～ 18 分の 1 に削減されたことが報告されました。この結果は、オペレーターが完全な RowDAS ネットワーキング提案よりも小さな変更で重複した作業を削減できることを示唆しています。

研究者 Csaba Kiraly の 9 月 3 日のレポートでは、縮小設計が RowDAS に向けた最初のステップとして考えられると説明されています。完全な提案では、新しい行ネットワーキング チャネルを導入せずに、回復任務を割り当てています。

BLOB には、レイヤー 2 ロールアップで使用されるデータが含まれます。 PeerDAS (BLOB データが利用可能かどうかを確認するイーサリアムのシステム) では、ノードはその一部のみをダウンロードできます。高管理ノードは、欠落している BLOB データを再構築するのに十分な、128 個のデータ列のうち少なくとも 64 個を保持します。スーパーノードには 128 個すべてが含まれます。

多くの高管理ノードは同じ再構築を繰り返すことができます。縮小された設計では、最初に特定の BLOB が割り当てられ、他のユーザーが自分でデータをすぐに再構築するのではなく、回復されたデータを受け取ることができるようになります。

イーサリアム BLOB 回復シミュレーションが示すもの

4 つの BLOB、10% のスーパーノード、保留列なしの 1 つの構成では、ネットワーク全体の推定再構築コストは、PeerDAS モデルの 48.6 CPU 秒から、削減された設計では 2.75 CPU 秒に減少しました。スーパーノード シェアが 20% の場合、対応する数値は 91 CPU 秒と 6.6 CPU 秒でした。

これらの合計は、経過した回復時間ではなく、シミュレートされたネットワーク全体での累積されたコンピューティング作業を表します。この計算では、Ryzen 9 8945HS プロセッサー上で測定された BLOB リカバリあたり 162 ミリ秒のコストが適用されます。トランザクション速度と手数料削減は報告された測定値の範囲外でした。

PeerDAS ベースラインには、重複した再構築を抑制するランダム化された待機とチェックがすでに含まれています。したがって、この比較により、既存のクライアントの動作が、遅延によって節約された作業の功績として認められます。

縮小されたバリアントでは、割り当てられたノードは既存の列分配チャネルを通じて回復されたセルを共有します。高管理ノードは、まだ不足しているものに対して遅延回復の役割を保持し、PeerDAS スタイルのバックストップを維持します。