🚨 Sunnyside devnet-rapporten (09/30) släpptes precis - om devnet-5 kördes på ~11% mainnet-skala (~1.7K fullständiga noder). Om du bryr dig om blobskalning och nätverksgränser är detta viktig läsning. En tråd 🧵
Test in Prod (Sunnyside Labs)
Test in Prod (Sunnyside Labs)16 sep. 2025
Sunnyside Labs har tillsammans med @ethPandaOps, @Optimism och @base lanserat ytterligare ett mega-devnet för Fusaka, med 56K-validerare och 1,7K fullständiga noder - ungefär 11 % av huvudnätets skala - och med stöd för upp till 72 blobbar.
Blob-dataflödet vid devnet-5 upprätthöll 22/33 blobbar och sträcktes ut till 48/72, med en topp på nästan ~45 miljoner. Den största begränsningen var nätverkskapaciteten: fullnoder med 50 Mbit/s uppladdningstak slog ständigt i taket vid 48/72 blobbar.
Till skillnad från våra tidigare små devnets överträffade EL P2P-toppar för de fullständiga noderna helt skvaller, vilket skapar ny instabilitet i stor skala. EL-sidan av nätverkande är nu den dominerande volatilitetskällan. Topparna i uppladdningen av kolumnskvaller minskade, troligen på grund av att EL-trafiken redan mättade bandbredden och noderna hade fler CL-peers för att dela kolumnbegäranden.
När det gäller tillgänglighet visade GetBlobsV2-tillförlitligheten tydligt vissa försämringar med högre belastning. Geth och Nethermind visade högre blobtillgänglighet än träfffrekvensen, vilket tyder på att de ofta bara innehöll partiella blobbar – vilket antyder att om partiella returer från GetBlobs-API:et tillåts kan CL-prestanda vid högre blobantal. Samtidigt har GetBlobAPI-prestandan för Reth förbättrats mycket, fördubblat antalet peer-medlemmar (~120 jämfört med ~40–60) och slutligen skakat av sig tidigare synkroniserings-/OOM-problem.
Slutsats: Fusaka kommer att låsa upp stöd för fler blobbar för L2:er, medan de för närvarande schemalagda BPO:erna kommer att skalas upp till målet på 14 blobbar per block (med högst 21). För att gå utöver denna gräns krävs noggrann uppmärksamhet på de kritiska flaskhalsar som lyfts fram i denna rapport – nämligen uppladdningsbandbredd, P2P-nätverksstabilitet och klientspecifika extremvärden. Den omedelbara prioriteten bör vara att förbättra bandbreddseffektiviteten och förfina hanteringen av klientblobar, till exempel att aktivera partiella returer via GetBlobs-API:et. Sunnyside Labs är fortsatt engagerade i att utveckla dessa områden och kommer att fortsätta arbeta för att pressa blob-genomströmningen till sina gränser – men alltid på ett sätt som säkerställer att nätverket fungerar säkert och tillförlitligt.
2,84K