另一份報告發布了 - 8/4 的 PeerDAS Devnet 報告由 Sunnsyide Labs 提供！ 對於 PeerDAS 在生產環境下節點的行為感到好奇嗎？ 🧵

這次，Sunnyside Labs 基於 @ethPandaOps 的 fusaka-devnet-2 映像運行了兩種開發網絡，以檢查在更現實環境下的網絡穩定性： 1. 互操作開發網絡（混合 CL/EL 客戶端，50% 超級節點） 2. 完美 PeerDAS 開發網絡（每個節點專門保管一個獨特的數據列）

對於每個開發網路配置，我們在其上運行了 3 種新的測試場景： 1. 大交易的 Blob 這是為了調查常規交易如何影響區塊傳播與數據列在節點之間傳播的競爭。我們在測試中保持每個區塊達到 22 Mgas（2MB 區塊大小）。 2. 帶寬限制 + 大交易 這個測試是為了調查在帶寬受限的節點（如家庭質押者）條件下，網路的行為。帶寬設置為超級節點 100/50Mbps 和完整節點 50/25Mbps，根據 EIP-7870 的建議。 3. 創世同步測試 創世同步在開發網路上進行測試，以找出同步過程中的任何阻礙或錯誤。 以下是我們從這些測試中獲得的見解：

1 - 大型交易對網絡的影響較小，在無限制的網絡下 在 Interop Devnet 和 Perfect PeerDAS Devnet 中，網絡在沒有太多問題的情況下承受了 60 個 blob，即使有其他額外的交易。這一結果與僅有 blob 的基準情境相同。 這表明，除了 blob 之外的普通交易在沒有資源限制的情況下對網絡穩定性影響微乎其微。

2 - 帶寬限制影響網絡的多條路徑 由於超節點的上行帶寬限制為100/50Mbps，完整節點為50/25Mbps，blob的吞吐量在Interop開發網絡上降至每區塊20個blob，在Perfect PeerDAS開發網絡上降至每區塊30個blob。 在這些限制下，IWANT消息在beacon_block主題上的急劇上升顯示出beacon區塊在傳播上遇到了困難。此外，一旦節點達到其出口上限，EL內存池顯示的blob數量大幅減少，這表明getBlobsV2的成功率急劇下降。 內部討論指出，超節點的50 Mbps上傳上限是主要原因：EIP-7870的這一上限是為本地區塊建設者量身定制的，而不是為服務更廣泛網絡的超節點設計的。因此，這些測試的條件比現實世界的情況更為苛刻。 Sunnyside Labs將在本週進行後續測試，使用更高的超節點帶寬，以評估這一限制的具體影響。

3 - Genesis 同步在 Interop devnet 上運作正常，但在 Perfect PeerDAS devnet 上失敗 在 Interop devnet 上，Genesis 同步順利完成，但在 Perfect PeerDAS 的 Fulu 升級時期後卻停滯不前。如果一個節點在 Genesis 同步期間無法獲取所有列，它應該理想地查詢其他對等節點以填補空白，但目前在任何客戶端中尚未實現。這種跨對等節點的列獲取是否會成為在 Fusaka 之前的必要功能仍然懸而未決；預計在下週四的 ACD 上會做出決定。

4 - @Teku_Consensys 的驗證者保管回填成功 驗證者保管回填讓客戶端能夠檢測缺失的歷史欄位並自動從對等節點檢索它們。 我們的專門測試確認 Teku 的實現運作完美 - 它識別了缺口並在正常條件下完全回填，沒有任何問題。在測試中發現了一個小錯誤，這是在鏈中存在大缺口且沒有任何 blobs 的邊緣情況下，該問題已迅速由團隊修復。 其他客戶端目前正在開發此功能，並將在未來的 Sunnyside 開發網絡中進行測試，隨著實現的完成。

Sunnyside Labs 將在本週繼續運行開發網絡，專注於以下主題： - 與更高超級節點帶寬限制和更長時間的開發網絡互操作性 - 對 Perfect PeerDAS 開發網絡的創世同步測試進行更多分析 - 更多開發網絡專注於最大區塊大小（以 snappy 壓縮格式）、被 blobber 損壞的節點，以及分裂網絡上的最終性