Další zpráva vypadla - 8/4 PeerDAS Devnet report od Sunnsyide Labs je zde! Zajímá vás, jak se uzly chovají v produkčních podmínkách s PeerDAS? 🧵

Tentokrát Sunnyside Labs spustil 2 druhy devnetů založených na obrazu fusaka-devnet-2 od @ethPandaOps, aby zkontroloval stabilitu sítě v realističtějším prostředí: 1. Interop devnet (smíšení klienti CL/EL s 50% supernodem) 2. Perfektní PeerDAS devnet (každý uzel má výhradní péči o jedinečný datový sloupec)

Pro každou konfiguraci devnet jsme na ní spustili 3 nové testovací scénáře: 1. Bloby s velkými Txs To má prozkoumat, jak pravidelné transakce ovlivňují konkurenci šíření bloku s šířením datového sloupce napříč uzly. Při testu jsme zachovali každý blok tak, aby dosáhl 22 Mgas (velikost bloku 2 MB). 2. Limit šířky pásma + velké Txs Tento test má prozkoumat chování sítě v podmínkách uzlů s omezenou šířkou pásma, jako jsou domácí staery. Šířka pásma je nastaveno jako 100/50Mbps pro supernody a 50/25Mbps pro fullnody, podle doporučení EIP-7870. 3. Test synchronizace Genesis Synchronizace Genesis je testována přes devnets, aby se zjistily případné blokátory nebo chyby v procesu synchronizace. Zde jsou poznatky, které jsme z těchto testů získali:

1 – Velké transakce mají malý dopad na síť, v neomezené síti V Interop Devnet i Perfect PeerDAS Devnet síť bez větších problémů vydržela 60 blobů, a to i s dalšími transakcemi jinými než bloby. Tento výsledek je stejný jako základní scénář pouze s objekty blob. To znamená, že běžné transakce jiné než objekty blob mají minimální dopad na stabilitu sítě bez omezení prostředků.

2 - Omezení šířky pásma ovlivňuje síť v různých cestách S odchozími linkami omezenými na 100/50 Mb/s pro superuzly a 50/25 Mb/s pro fullnodes se propustnost objektů blob sbalila na 20 objektů blob na blok v Interop devnet a 30 blobů na blok v Perfect PeerDAS devnet. Pod těmito limity prudký nárůst zpráv IWANT na téma beacon_block ukázal, že beacon bloky se potýkají s šířením. Jakmile uzly dosáhly svých výstupních stropů, EL mempools odhalily mnohem méně blobů, o čemž svědčí prudký pokles úspěšnosti getBlobsV2. Interní diskuze ukazují na limit 50 Mbps pro nahrávání superuzlů jako na hlavního viníka: tento strop na EIP-7870 je přizpůsoben pro místní stavitele bloků, nikoli pro supernody obsluhující širší síť. Tyto testy byly tedy tvrdší než podmínky v reálném světě. Sunnyside Labs tento týden provede následný test s vyšší šířkou pásma superuzlu, aby posoudila přesný dopad tohoto omezení.

3. Synchronizace Genesis funguje pro Interop devnet, ale selhala v Perfect PeerDAS devnet Synchronizace Genesis byla dokončena bezchybně na Interop devnet, ale zastavila se těsně po epoše upgradu Fulu na Perfect PeerDAS. Pokud uzel nemůže získat všechny sloupce během synchronizace genesis, měl by se v ideálním případě dotazovat dalších peerů, aby zaplnil mezery, což zatím není implementováno v žádném klientovi. Zda se toto načítání sloupců mezi vrstevníky stane povinnou funkcí před tím, než bude Fusaka stále otevřená; rozhodnutí se očekává na ACD příští čtvrtek.

4 - Backfill úschovy validátoru byl úspěšný na @Teku_Consensys Backfill úschovy validátoru umožňuje klientovi detekovat chybějící historické sloupce a automaticky je načítat z partnerských počítačů. Náš specializovaný test potvrdil, že implementace Teku funguje bezchybně - identifikovala mezery a v běžných podmínkách byla plně zasypána bez zádrhelů. Při testech byla identifikována malá chyba v okrajovém případě, kdy byla v řetězci velká mezera bez jakýchkoli blobů, kterou tým rychle opravil. Na této funkci teď pracují další klienti a po dokončení implementace se bude testovat v budoucích devnets Sunnyside.

Sunnyside Labs bude tento týden pokračovat v běhu devnets a zaměří se na následující témata: - Interoperabilita Devnet s vyššími limity šířky pásma supernodu a delšími časovými obdobími - Další analýza synchronizačních testů genesis v devnet Perfect PeerDAS - Více vývojářských sítí zaměřených na maximální velikost bloku (v rychle komprimovaném formátu), uzly poškozené blobberem a konečnost v rozdělené síti