Sunnysides 7/14 PeerDAS Devnet-rapport er her! La oss dykke ned i den nåværende statusen til PeerDAS - hvor mye blob kan vi håndtere, og hva er flaskehalsen?

Blant disse tiltakene er Sunnysides rolle å kjøre ukentlige devnets i mange forskjellige konfigurasjoner og mate kjerneutviklere med den resulterende innsikten: •Hvor gjeldende PeerDAS-grenser ligger •Nøyaktig hvilke komponenter som skaper flaskehalser •Hvor godt optimaliseringer som Supernodes og GetBlobV2 fungerer i praksis

Vårt hovedmål er å teste raskt og fleksibelt på måter som utfyller det andre team som @ethPandaOps gjør på fusaka-devents, og gi rettidig tilbakemelding som støtter den pågående implementeringen av PeerDAS.

I løpet av denne uken opererte vi 12 devnets og kjørte 3 testsuiter, ved å bruke @ethPandaOps' siste fusaka-devnet-2-bilde: 1.Blob-gjennomstrømming (maksimalt antall blober per blokk) 2. Nettverksbåndbredde (test av vedvarende belastning) 3. Båndbreddebegrensning (30 / 20 / 10 Mbps tak)

1 – Test av blob-gjennomstrømming Testresultater viste at de fleste CL-klienter kunne håndtere 84 blober per blokk eller mer, og forble stabile med minst 40 blober. Noen klienter registrerte et relativt lavere maksimalt antall blober sammenlignet med tidligere devnets – men dette kan være fordi validatorantallet per node i dette devnet ble redusert fra 100 til 8, noe som igjen reduserte hver nodes delnettdeltakelsesrate.

2 – Test av nettverksbåndbredde I motsetning til tidligere devnets der nettverket ofte ble ustabilt ved høyt antall blobs, kjørte alle devnets denne gangen stabilt i en lengre periode (~16 timer) selv med 60 eller 72 blober per blokk. Selv om dette ikke garanterer stabilitet på produksjonsnivå, viser det at i det minste noen CL-EL-kombinasjoner har oppnådd et mye høyere nivå av robusthet gjennom optimalisering 🚀

3 – Test av båndbreddebegrensning For å sjekke om ekte hjemmeaktører kan delta jevnt når PeerDAS er aktiv, brukte denne testen nettverksgrenser og undersøkte hvilke faktorer som blir flaskehalser under ulike begrensede scenarier. På tvers av flere tester oppdaget vi at bruken av nodebåndbredde med jevne mellomrom øker – spesielt nær starten av et spor når blobber sladres – og at disse toppene begrenser den generelle nettverksytelsen. Burst-trafikk skjedde jevnt på tvers av noder i stedet for å være forårsaket av en bestemt CL- eller EL-klient, og når bursts begynte, kunne ikke nettverket øke blob-gjennomstrømmingen ytterligere. Med andre ord er burst-trafikk den største flaskehalsen i miljøer med begrenset båndbredde, og vi må finne måter å dempe den på.

I tillegg kommuniserte vi med ulike kundeteam og oppmuntret til forbedringer for synkronisering og noderelaterte problemer.

Sunnyside-utvikleren kjører 🏗️ fortsatt; Gjennomføring av interop-devnets med flere klientkombinasjoner, mer detaljerte båndbreddetester, spamtester som inkluderer normale transaksjoner, og tilbakefyllings-/synkroniseringstester, for å identifisere flaskehalser i miljøer som ligner mer på mainnet-forhold.