Zpráva Sunnyside 7/14 PeerDAS Devnet je tady! Pojďme se ponořit do současného stavu PeerDAS - s jakým množstvím blobů si dokážeme poradit a jaké je úzké hrdlo?

Mezi těmito snahami je úlohou Sunnyside spouštět týdenní devnety v mnoha různých konfiguracích a poskytovat vývojářům jádra výsledné poznatky: •Kde jsou aktuální limity PeerDAS •Přesně které komponenty vytvářejí úzká místa •Jak dobře fungují optimalizace jako Supernodes a GetBlobV2 v praxi

Naším hlavním cílem je rychle a flexibilně testovat způsoby, které doplňují to, co dělají ostatní týmy jako @ethPandaOps na fusaka-devents, a poskytovat včasnou zpětnou vazbu, která podporuje probíhající implementaci PeerDAS.

V tomto týdnu jsme provozovali 12 devnets a spustili 3 testovací sady pomocí nejnovějšího obrazu fusaka-devnet-2 @ethPandaOps: 1. Propustnost objektů blob (maximální počet blobů na blok) 2. Šířka pásma sítě (test trvalého zatížení) 3. Omezení šířky pásma (limity 30 / 20 / 10 Mbps)

1 – Test propustnosti objektu blob Výsledky testů ukázaly, že většina klientů CL dokázala zpracovat 84 objektů blob na blok nebo více a zůstala stabilní s nejméně 40 objekty blob. Někteří klienti zaznamenali relativně nižší maximální počet objektů blob ve srovnání s předchozími devnets – ale to může být způsobeno tím, že počet validátorů na uzel v této devnet byl snížen ze 100 na 8, což zase snížilo míru účasti každého uzlu v podsíti.

2 – Test šířky pásma sítě Na rozdíl od dřívějších devnetů, kde se síť často stávala nestabilní při vysokém počtu blobů, tentokrát všechny devnety běžely stabilně po delší dobu (~16 hodin), a to i s 60 nebo 72 bloby na blok. I když to nezaručuje stabilitu na úrovni výroby, ukazuje to, že alespoň některé kombinace CL-EL dosáhly díky optimalizaci 🚀 mnohem vyšší úrovně robustnosti

3 – Test omezení šířky pásma Aby se ověřilo, zda se skuteční domácí stakeři mohou hladce zapojit, jakmile je PeerDAS aktivní, tento test aplikoval limity sítě a zkoumal, které faktory se stávají úzkými místy v různých omezených scénářích. V několika testech jsme zjistili, že využití šířky pásma uzlů pravidelně stoupá – zejména na začátku slotu, kdy se o bloupech mluví – a že tyto špičky omezují celkový výkon sítě. Nárazový provoz probíhal rovnoměrně napříč uzly, spíše než aby byl způsoben konkrétním klientem CL nebo EL, a jakmile shluky začaly, síť nemohla dále zvyšovat propustnost blobů. Jinými slovy, nárazový provoz je největším úzkým hrdlem v prostředích s omezenou šířkou pásma a musíme najít způsoby, jak jej zmírnit.

Kromě toho jsme komunikovali s různými klientskými týmy a podporovali vylepšení problémů souvisejících se synchronizací a kolegiem.

Sunnyside devnet stále běží 🏗️; Provádění interoperabilitních sítí s více kombinacemi klientů, podrobnějších testů šířky pásma, testů spamu, které zahrnují normální transakce, a testů backfill/sync k identifikaci kritických bodů v prostředích, která se více podobají podmínkám mainnetu.