一個將 blob 恢復任務分配給節點的以太坊原型，在 1,000 個節點的模擬中報告了估計的重建計算工作量減少 11–18 倍。結果表明，運營商可以透過比完整 RowDAS 網絡提案更小的變更來減少重複工作。
研究員 Csaba Kiraly 的 Sept. 3 report 將簡化設計描述為邁向 RowDAS 的可能第一步，該設計在未引入完整提案中新行網絡通道的情況下分配了恢復職責。
Blobs 傳送層-2 擴容方案所使用的資料。PeerDAS 是以太坊用於檢查 blob 資料是否可用的系統，可讓節點僅下載其中一部分。高保管節點至少持有 128 個資料欄中的 64 個，足以重建遺失的 blob 資料；超級節點則持有全部 128 個。
許多高託管節點可以重複相同的重建過程。簡化設計會優先將特定的 blob 分配給它們，讓其他節點接收已恢復的資料，而非立即自行重建。
以太坊 blob 恢復模擬所顯示的內容
在四個數據塊、10% 超級節點且不保留任何列的配置下，根據 PeerDAS 模型，預估的全網重建成本從 48.6 CPU 秒降至 2.75 CPU 秒；在 20% 超級節點比例下，對應的數值分別為 91 和 6.6 CPU 秒。
這些總量描述的是模擬網絡中累積的計算工作量，而非耗費的恢復時間。會計應用了在 Ryzen 9 8945HS 處理器上每恢復一個 blob 花費 162 毫秒的測量成本。交易速度和費用節省未包含在報告的測量範圍內。
PeerDAS 基線已包含隨機等待和檢查，以抑制重複重建。因此，此比較將這些延遲所節省的工作歸功於現有客戶的行為。
在簡化變體下，指派的節點透過現有的列分發通道共享已恢復的儲存單元。高託管節點對仍遺失的部分保留延遲恢復角色，以維持類似 PeerDAS 的備援機制。
完整的 RowDAS，如草案 EIP-8371 所指定，將增加另一種恢復途徑：行通道允許較小的節點將其資料集中，當其合計持有量達到恢復門檻時，共同重建資料。簡化設計仍保留對高託管節點的當前依賴，無法提供此額外的彈性。
測量仍限於使用真實加密技術的模擬內部網絡。Kiraly 報告稱未有 devnet 結果，而完整設計的 128 行子網配置仍基於較小子網數量的推算。更大的模擬和真實網絡測試仍有待進行。
EIP-8371 保持 blob 限制不變，而責任分配與行網路之間的建議分離尚未納入其草案文本中。目前的機會較為有限：減少恢復所需的處理器工作量，而更廣泛的彈性效益則取決於後續的行層。
文章 Ethereum 可能有更簡單的方法來減輕其不斷增長的 rollup 生態系統的計算負擔 首先出現在 CryptoSlate。