ノード間にブロブ復元の負担を分散させるEthereumのプロトタイプは、1,000ノードシミュレーションで推定される復元計算量を11～18倍削減した。この結果は、オペレーターがフルのRowDASネットワーキング提案ではなく、より小さな変動幅で重複作業を削減できる可能性を示唆している。
研究者カサバ・キラリの9月3日の報告は、簡素化された設計をRowDASへの最初のステップと位置づけており、フルプロポーザルで新しいローネットワーキングチャネルを導入せずに回復の役割を割り当てています。
Blobsは、レイヤー2ロールアップで使用されるデータを保持します。PeerDASは、Ethereumがblobデータの可用性を確認するためのシステムで、ノードがその一部のみをダウンロードできるようにします。高信頼ノードは128列のうち少なくとも64列を保持し、欠落したblobデータを再構築するのに十分です。スーパーノードはすべての128列を保持します。
多くの高預かりノードが同じ復元を繰り返すことができます。簡素化された設計では、特定のブロブをまずそれらに割り当てることで、他のノードが自ら再構築するのではなく、復元されたデータを受け取れるようにします。
Ethereumのブロブ復元シミュレーションが示すもの
4つのブロブ、10%のスーパーノード、列を一切保持しない構成では、PeerDASモデルでの推定ネットワーク全体の再構築コストは48.6 CPU秒から、簡略化された設計では2.75 CPU秒に低下しました。スーパーノードの比率が20%の場合は、それぞれ91 CPU秒と6.6 CPU秒でした。
これらの合計値は、経過した回復時間ではなく、シミュレートされたネットワーク全体で蓄積された計算量を示しています。会計処理では、Ryzen 9 8945HSプロセッサ上で1つのblobの回復あたり162ミリ秒のコストを測定値として適用しています。トランザクション速度と手数料の節約は、報告された測定値の範囲外です。
PeerDASのベースラインには、重複した復元を抑制するランダムな待機とチェックが既に含まれています。したがって、この比較では、これらの遅延によって節約される作業を既存のクライアントの行動として評価しています。
削減版では、割り当てられたノードが既存の列配布チャネルを通じて回復したセルを共有します。高管理ノードは、まだ不足している分について遅延回復の役割を維持し、PeerDASスタイルのバックアップを確保します。
完全なRowDAS（ドラフトEIP-8371で指定）は、別の復元ルートを追加します：ローチャネルにより、小さなノードがデータをプールし、合計保有量が復元閾値を超えたときに共同で再構築できます。簡略化された設計は、現在の高保管ノードへの依存を維持し、この追加の耐障害性を提供できません。
測定は、実際の暗号化を使用したシミュレートされたプロセス内ネットワークに限定されています。Kiralyはdevnetの結果を報告しておらず、完全な設計の128行サブネット構成は、より小さなサブネット数からの外挿にすぎません。より大規模なシミュレーションと実ネットワークテストはまだ先に控えています。
EIP-8371はブロブ制限を変更せず、義務割り当てとローネットワーキングの分割案はまだ草案文に組み込まれていません。直近の機会は、復元に必要なプロセッサの処理負荷を削減することに限定されており、より広範な耐障害性の利点は、後のローレイヤーに依存しています。
投稿 Ethereumは、拡大するロールアップエコシステムの計算負荷を軽減するためのより単純な方法を持つ可能性がある は、CryptoSlate で最初に公開されました。