Sunnysides 7/14 PeerDAS Devnet-rapport är här! Låt oss dyka in i den aktuella statusen för PeerDAS - hur mycket blob kan vi hantera och vad är flaskhalsen?

Bland dessa ansträngningar är Sunnysides roll att köra veckovisa devnets i många olika konfigurationer och mata kärnutvecklare med de resulterande insikterna: •Var de nuvarande PeerDAS-gränserna ligger •Exakt vilka komponenter som skapar flaskhalsar •Hur väl optimeringar som supernoder och GetBlobV2 fungerar i praktiken

Vårt huvudmål är att testa snabbt och flexibelt på ett sätt som kompletterar vad andra team som @ethPandaOps gör på fusaka-devents, vilket ger snabb feedback som stöder den pågående implementeringen av PeerDAS.

Under den här veckan körde vi 12 devnets och körde 3 testsvit med hjälp av @ethPandaOps senaste fusaka-devnet-2-avbildningen: 1.Blob-dataflöde (maximalt antal blobbar per block) 2. Nätverksbandbredd (test med ihållande belastning) 3. Bandbreddsbegränsning (30 / 20 / 10 Mbps kepsar)

1 – Test av blob-dataflöde Testresultaten visade att de flesta CL-klienter kunde hantera 84 blobbar per block eller mer, och förblev stabila med minst 40 blobbar. Vissa klienter registrerade ett relativt lägre maximalt antal blobar jämfört med tidigare devnets – men det kan bero på att validatorantalet per nod i detta devnet minskade från 100 till 8, vilket i sin tur sänkte varje nods deltagandefrekvens för undernät.

2 – Test av nätverksbandbredd Till skillnad från tidigare devnets där nätverket ofta blev instabilt vid höga blobantal, kördes den här gången alla devnets stabilt under en längre period (~16 timmar) även med 60 eller 72 blobbar per block. Även om detta inte garanterar stabilitet på produktionsnivå, visar det att åtminstone vissa CL-EL-kombinationer har uppnått en mycket högre nivå av robusthet genom optimering 🚀

3 - Test av bandbreddsbegränsning För att kontrollera om riktiga bostadsstakare kan delta smidigt när PeerDAS väl är aktivt, tillämpade detta test nätverksgränser och undersökte vilka faktorer som blir flaskhalsar under olika begränsade scenarier. I flera tester upptäckte vi att användningen av nodbandbredd regelbundet ökar – särskilt i början av ett fack när blobbar skvallras – och att dessa toppar begränsar den övergripande nätverksprestandan. Burst-trafik skedde enhetligt mellan noder i stället för att orsakas av en viss CL- eller EL-klient, och när bursts började kunde nätverket inte öka blob-dataflödet ytterligare. Med andra ord är burst-trafik den största flaskhalsen i bandbreddsbegränsade miljöer, och vi måste hitta sätt att mildra den.

Dessutom kommunicerade vi med olika kundteam och uppmuntrade förbättringar för synkroniserings- och peer-relaterade problem.

Sunnyside devnet är fortfarande igång 🏗️ ; Genomföra interop-devnets med flera klientkombinationer, mer detaljerade bandbreddstester, skräpposttester som inkluderar normala transaktioner och återfyllnings-/synkroniseringstester för att identifiera flaskhalsar i miljöer som mer liknar mainnet-förhållanden.