Sunnyside 的 7/14 PeerDAS Devnet 報告來了！ 讓我們深入了解 PeerDAS 的當前狀態 - 我們能處理多少 blob，瓶頸在哪裡？

在這些工作中，Sunnyside 的職責是每周以許多不同的配置運行開發網，並將由此產生的見解提供給核心開發人員： •當前 PeerDAS 限制所在 •究竟哪些元件造成了瓶頸 •超級節點和 GetBlobV2 等優化在實踐中的效果如何

我們的主要目標是以補充其他團隊（如 @ethPandaOps）在 fusaka-devents 所做的事情的方式快速靈活地進行測試，提供及時的反饋，以支援 PeerDAS 的持續實施。

在本周，我們運行了 12 個 devnet，運行了 3 個測試套件，使用了 @ethPandaOps 最新的 fusaka-devnet-2 鏡像： 1.Blob 輸送量（每個區塊的最大 blob） 2. 網路頻寬（持續負載測試） 3. 頻寬限制（30 / 20 / 10 Mbps 上限）

1 – Blob 輸送量測試 測試結果顯示，大多數 CL 用戶端每個塊可以處理 84 個或更多 blob，並且至少有 40 個 blob 保持穩定。與以前的開發網相比，一些客戶端記錄的最大 blob 計數相對較低——但這可能是因為該開發網中每個節點的驗證者計數從 100 減少到 8，這反過來又降低了每個節點的子網參與率。

2 – 網路頻寬測試 與早期的開發網不同，早期的開發網在高 blob 數量下網路經常變得不穩定，這一次，即使每個塊有 60 或 72 個 blob，所有開發網也能穩定運行較長時間（~16 小時）。雖然這並不能保證生產級的穩定性，但它表明至少一些CL-EL組合通過優化🚀實現了更高水準的魯棒性

3 – 帶寬約束測試 為了檢查 PeerDAS 啟動后，真正的家庭質押者是否能夠順利參與，該測試應用了網路限制，並檢查了在各種受限場景下哪些因素成為瓶頸。 在多項測試中，我們發現節點頻寬使用量會週期性地激增，尤其是在 blob 被八卦時，在插槽開始附近，並且這些峰值限制了整體網路性能。突發流量在節點之間均勻發生，而不是由特定的 CL 或 EL 用戶端引起的，一旦突發開始，網路就無法進一步增加 blob 輸送量。 換句話說，突發流量是頻寬受限環境中最大的瓶頸，我們需要找到緩解它的方法。

此外，我們還與各個客戶團隊進行了溝通，並鼓勵改進同步和對等相關問題。

Sunnyside 開發網仍在運行🏗️;使用多個客戶端組合進行互作開發網、更精細的頻寬測試、包括正常事務的垃圾郵件測試以及回填/同步測試，以識別更接近主網條件的環境中的瓶頸。