En annen rapport droppet - 8/4 PeerDAS Devnet-rapport fra Sunnsyide Labs er her! Nysgjerrig på hvordan noder oppfører seg under produksjonsforhold med PeerDAS? 🧵

Denne gangen kjørte Sunnyside Labs 2 typer devnets basert på @ethPandaOps fusaka-devnet-2-bilde, for å sjekke nettverksstabiliteten i mer realistiske omgivelser: 1. Interop devnet (blandede CL/EL-klienter med 50 % supernode) 2. Perfekt PeerDAS-devnet (hver node har eksklusiv forvaring av en unik datakolonne)

For hver devnet-konfigurasjon kjørte vi 3 nye testscenarioer på den: 1. Blobs med store Txs Dette er for å undersøke hvordan vanlige transaksjoner påvirker blokkutbredelsens konkurranse med datakolonneforplantningen på tvers av nodene. Vi har beholdt hver blokk ved testen for å nå 22 MGA (2 MB blokkstørrelse). 2. Båndbreddegrense + store txs Denne testen er for å undersøke oppførselen til nettverket under forholdene til båndbreddebegrensede noder som hjemmeaktører. Båndbredden er satt til 100/50 Mbps for supernoder og 50/25 Mbps for fullnoder, i henhold til anbefalinger fra EIP-7870. 3. Test av Genesis-synkronisering Genesis-synkronisering testes over devnets for å finne ut eventuelle blokkeringer eller feil i synkroniseringsprosessen. Her er innsikten vi fikk fra disse testene:

1 - Store transaksjoner har lav innvirkning på nettverket, under ubegrenset nettverk I både Interop Devnet og Perfect PeerDAS Devnet tålte nettverket 60 blober uten store problemer, selv med andre transaksjoner enn blober. Dette resultatet er det samme som grunnscenarioet med bare blober. Dette indikerer at andre vanlige transaksjoner enn blober har minimal innvirkning på nettverksstabiliteten uten ressursbegrensninger.

2 - Båndbreddegrense påvirker nettverket i forskjellige baner Med oppkoblinger begrenset til 100/50 Mbps for supernoder og 50/25 Mbps for fullnoder, kollapset blob-gjennomstrømmingen til 20 blober/blokk på Interop-devnet og 30 blober/blokk på Perfect PeerDAS-devnet. Under disse grensene viste en kraftig økning i IWANT-meldinger om det beacon_block emnet at beacon-blokker slet med å spre seg. Når noder traff utgangstaket, eksponerte EL-mempooler langt færre blobber, bevist av et bratt fall i suksessraten for getBlobsV2. Interne diskusjoner peker på opplastingstaket på 50 Mbps på supernoder som hovedsynderen: taket på EIP-7870 er skreddersydd for lokale blokkbyggere, ikke for supernoder som betjener det bredere nettverket. Dermed var disse testene tøffere enn virkelige forhold. Sunnyside Labs vil kjøre en oppfølgingstest denne uken med høyere supernodebåndbredde for å måle den nøyaktige effekten av denne begrensningen.

3 - Genesis-synkronisering fungerer for Interop devnet, men mislyktes på Perfect PeerDAS devnet Genesis-synkronisering fullførte feilfritt på Interop-devnet, men stoppet like etter Fulu-oppgraderingsepoken på Perfect PeerDAS. Hvis en node ikke kan hente alle kolonnene under genesis-synkronisering, bør den ideelt sett spørre flere noder for å fylle hullene, som ennå ikke er implementert i noen klienter. Om denne cross-peer-kolonnen blir en nødvendig funksjon før Fusaka fortsatt er åpen; avgjørelsen er ventet på neste torsdags ACD.

4 - Validator depotutfylling vellykket ved @Teku_Consensys Med valideringsvaretekt kan en klient oppdage manglende historiske kolonner og automatisk hente dem fra kolleger. Vår dedikerte test bekreftet at Tekus implementering fungerer feilfritt - den identifiserte hull og fylte fullstendig opp uten hikke under vanlige forhold. En liten feil ved et kanttilfelle der det var stort gap i kjeden uten noen blobber ble identifisert ved testene, som raskt ble fikset av teamet. Andre kunder jobber nå med denne funksjonen, og den vil bli testet i fremtidige Sunnyside-utviklere etter hvert som implementeringen er fullført.

Sunnyside Labs vil fortsette å kjøre devnets denne uken, med fokus på følgende emner: - Devnet Interop med høyere supernodebåndbreddegrenser og lengre tidsperioder - Mer analyse av genesis-synkroniseringstester på Perfect PeerDAS devnet - Flere devnets som fokuserer på maksimal blokkstørrelse (i raskt komprimert format), noder som er skadet med blobber og finalitet på delt nettverk