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

在這些努力中，Sunnyside 的角色是以多種不同的配置運行每週的開發網絡，並向核心開發人員提供結果見解： • 當前 PeerDAS 的限制在哪裡 • 究竟哪些組件造成瓶頸 • 像 Supernodes 和 GetBlobV2 這樣的優化在實踐中效果如何

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

在這一週，我們運行了 12 個開發網絡並執行了 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 數量下都穩定運行了較長時間（約 16 小時），即使每個區塊有 60 或 72 個 blob。雖然這並不保證生產級的穩定性，但它顯示至少某些 CL-EL 組合通過優化達到了更高的穩定性 🚀

3 – 帶寬限制測試 為了檢查當 PeerDAS 啟動後，真實的家庭質押者是否能夠順利參與，此測試應用了網絡限制，並檢查在各種受限情境下哪些因素成為瓶頸。 在多次測試中，我們發現節點的帶寬使用量會定期激增——特別是在槽開始時，當 blobs 被廣播時——而這些激增限制了整體網絡性能。突發流量在節點之間均勻發生，而不是由特定的 CL 或 EL 客戶端引起的，並且一旦突發開始，網絡就無法進一步提高 blob 的吞吐量。 換句話說，突發流量是帶寬受限環境中最大的瓶頸，我們需要找到減輕它的方法。

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

Sunnyside 開發網絡仍在運行 🏗️；正在進行多個客戶端組合的互操作開發網絡，更細緻的帶寬測試、包括正常交易的垃圾測試，以及回填/同步測試，以識別在更接近主網條件的環境中的瓶頸。