Sunnyside's 7/14 PeerDAS Devnet-rapport is hier! Laten we duiken in de huidige status van PeerDAS - hoeveel blob kunnen we aan, en wat is de bottleneck?

Onder deze inspanningen is de rol van Sunnyside om wekelijks devnets te draaien in veel verschillende configuraties en de kernontwikkelaars te voorzien van de resulterende inzichten: •Waar de huidige PeerDAS-limieten liggen •Welke componenten precies knelpunten creëren •Hoe goed optimalisaties zoals Supernodes en GetBlobV2 in de praktijk werken

Ons belangrijkste doel is om snel en flexibel te testen op manieren die aanvullen wat andere teams zoals @ethPandaOps doen bij fusaka-devents, en tijdige feedback te geven die de voortdurende implementatie van PeerDAS ondersteunt.

In deze week hebben we 12 devnets beheerd en 3 test suites uitgevoerd, met behulp van de nieuwste fusaka-devnet-2 afbeelding van @ethPandaOps: 1. Blob Doorvoer (max blobs per blok) 2. Netwerkbandbreedte (duurtest) 3. Bandbreedte Beperking (30 / 20 / 10 Mbps limieten)

1 – Blob Doorvoertest Testresultaten toonden aan dat de meeste CL-clients 84 blobs per blok of meer konden verwerken en stabiel bleven met ten minste 40 blobs. Sommige clients registreerden een relatief lager maximaal aantal blobs in vergelijking met eerdere devnets - maar dit kan komen doordat het aantal validators per node in deze devnet is verlaagd van 100 naar 8, wat op zijn beurt de subnetdeelnamegraad van elke node verlaagde.

2 – Netwerk Bandbreedte Test In tegenstelling tot eerdere devnets waar het netwerk vaak onstabiel werd bij hoge blob-aantallen, draaiden deze keer alle devnets stabiel gedurende een langere periode (~16 uur), zelfs met 60 of 72 blobs per blok. Hoewel dit geen garantie biedt voor stabiliteit op productieniveau, toont het aan dat ten minste enkele CL-EL combinaties een veel hoger niveau van robuustheid hebben bereikt door optimalisatie 🚀

3 – Bandwidth Beperkings Test Om te controleren of echte thuis-stakers soepel kunnen deelnemen zodra PeerDAS actief is, past deze test netwerklimieten toe en onderzoekt welke factoren knelpunten worden onder verschillende beperkte scenario's. Bij meerdere tests ontdekten we dat het bandbreedtegebruik van knooppunten periodiek piekt - vooral vlak voor het begin van een slot wanneer blobs worden verspreid - en dat deze pieken de algehele netwerkprestaties beperken. Burstverkeer kwam uniform voor over knooppunten in plaats van veroorzaakt te worden door een specifieke CL- of EL-client, en zodra de pieken begonnen, kon het netwerk de blobdoorvoer niet verder verhogen. Met andere woorden, burstverkeer is het grootste knelpunt in omgevingen met beperkte bandbreedte, en we moeten manieren vinden om dit te verminderen.

Daarnaast hebben we gecommuniceerd met verschillende klantteams en verbeteringen aangemoedigd voor synchronisatie- en peer-gerelateerde problemen.

Het Sunnyside devnet draait nog steeds 🏗️; het uitvoeren van interop-devnets met meerdere clientcombinaties, meer gedetailleerde bandbreedtetests, spamtests die normale transacties omvatten, en backfill/sync-tests, om knelpunten te identificeren in omgevingen die meer lijken op de mainnet-omstandigheden.