🚨 Raportul Sunnyside devnet (30/09) tocmai a fost lansat - aproximativ devnet-5 a rulat la ~11% scară mainnet (~1.7K noduri complete). Dacă vă pasă de scalarea blob-urilor și de limitele de rețea, aceasta este o lectură esențială. Un fir 🧵
Test in Prod (Sunnyside Labs)
Test in Prod (Sunnyside Labs)16 sept. 2025
Sunnyside Labs, împreună cu @ethPandaOps, @Optimism și @base, a lansat un alt mega-devnet pentru Fusaka, cu 56K validatoare și 1.7K noduri complete - aproximativ 11% din scala rețelei principale - și suportă până la 72 de blob-uri.
Debitul de blob la devnet-5 a susținut 22/33 de blob-uri și a fost extins la 48/72, cu un vârf de consum de gaz de aproape ~45M. Cel mai mare limitator a fost capacitatea rețelei: nodurile complete cu limite de încărcare de 50Mbps au atins plafonul constant la 48/72 de blob-uri.
Spre deosebire de micile noastre devnet-uri anterioare, vârfurile EL P2P pentru nodurile complete au depășit complet bârfele, creând o nouă instabilitate la scară. Partea EL a rețelei este acum sursa dominantă de volatilitate. Vârfurile de încărcare a bârfelor coloanelor s-au diminuat, probabil pentru că traficul EL satura deja lățimea de bandă și nodurile aveau mai mulți colegi CL pentru a partaja cererile de coloane.
În ceea ce privește disponibilitatea, fiabilitatea GetBlobsV2 a arătat clar unele degradări cu o sarcină mai mare. Geth și Nethermind au arătat o disponibilitate mai mare a blob-urilor decât rata de accesare, sugerând că adesea dețineau doar blob-uri parțiale - sugerând că permiterea returnărilor parțiale de la API-ul GetBlobs ar putea ajuta performanța CL la un număr mai mare de blob-uri. Între timp, performanța GetBlobAPI a lui Reth s-a îmbunătățit foarte mult, dublând numărul de colegi (~120 vs ~40-60) și, în cele din urmă, scuturându-se de problemele anterioare de sincronizare/OOM.
Concluzie: Fusaka va debloca suportul pentru mai multe blob-uri pentru L2, în timp ce BPO-urile programate în prezent se vor extinde până la ținta de 14 blob-uri pe bloc (cu un maxim de 21). Pentru a depăși această limită, este necesară o atenție deosebită la blocajele critice evidențiate în acest raport - și anume lățimea de bandă de încărcare, stabilitatea rețelei P2P și valorile aberante specifice clientului. Prioritatea imediată ar trebui să fie îmbunătățirea eficienței lățimii de bandă și rafinarea gestionării blob-urilor client, cum ar fi activarea returnărilor parțiale prin API-ul GetBlobs. Sunnyside Labs își menține angajamentul de a avansa aceste domenii și va continua să lucreze pentru a împinge debitul de blob la limitele sale - dar întotdeauna într-un mod care să asigure funcționarea sigură și fiabilă a rețelei.
2,83K