Un altro report è uscito - il report 8/4 di PeerDAS Devnet di Sunnsyide Labs è qui! Sei curioso di sapere come si comportano i nodi in condizioni di produzione con PeerDAS? 🧵

Questa volta, Sunnyside Labs ha eseguito 2 tipi di devnet basati sull'immagine fusaka-devnet-2 di @ethPandaOps, per controllare la stabilità della rete in un ambiente più realistico: 1. Devnet di interoperabilità (client CL/EL misti con il 50% di supernodi) 2. Devnet Perfect PeerDAS (ogni nodo custodisce esclusivamente una colonna di dati unica)

Per ogni configurazione del devnet, abbiamo eseguito 3 nuovi scenari di test: 1. Blobs con Transazioni Grandi Questo serve a indagare come le transazioni regolari influenzano la competizione nella propagazione dei blocchi con la propagazione della colonna dati tra i nodi. Abbiamo mantenuto ciascun blocco nel test per raggiungere 22 Mgas (dimensione del blocco di 2MB). 2. Limite di Larghezza di Banda + Transazioni Grandi Questo test serve a indagare il comportamento della rete in condizioni di nodi con larghezza di banda limitata, come i validatori domestici. La larghezza di banda è impostata a 100/50Mbps per i supernodi e 50/25Mbps per i nodi completi, secondo le raccomandazioni dell'EIP-7870. 3. Test di Sincronizzazione Genesis La sincronizzazione Genesis viene testata sui devnet per scoprire eventuali blocchi o bug nel processo di sincronizzazione. Ecco le intuizioni che abbiamo ottenuto da questi test:

1 - Le transazioni di grandi dimensioni hanno un basso impatto sulla rete, in una rete senza vincoli Sia nell'Interop Devnet che nel Perfect PeerDAS Devnet, la rete ha sostenuto 60 blob senza molti problemi, anche con transazioni aggiuntive oltre ai blob. Questo risultato è lo stesso dello scenario di base con solo blob. Ciò indica che le transazioni ordinarie, diverse dai blob, hanno un impatto minimo sulla stabilità della rete in assenza di vincoli sulle risorse.

2 - Il limite di larghezza di banda influisce sulla rete in vari percorsi Con i collegamenti in upload limitati a 100/50Mbps per i supernodi e 50/25Mbps per i nodi completi, il throughput dei blob è crollato a 20 blob/blocco sulla devnet Interop e 30 blob/blocco sulla devnet Perfect PeerDAS. Sotto questi limiti, un forte aumento dei messaggi IWANT sul topic beacon_block ha mostrato che i beacon block stavano faticando a propagarsi. Inoltre, una volta che i nodi hanno raggiunto i loro limiti di uscita, le mempool EL hanno esposto molti meno blob, come dimostrato da un forte calo nei tassi di successo di getBlobsV2. Le discussioni interne indicano il limite di upload di 50 Mbps sui supernodi come il principale colpevole: quel limite all'EIP-7870 è progettato per i costruttori di blocchi locali, non per i supernodi che servono la rete più ampia. Pertanto, questi test sono stati più severi rispetto alle condizioni del mondo reale. Sunnyside Labs eseguirà un test di follow-up questa settimana con una larghezza di banda superiore per i supernodi per valutare l'impatto esatto di questa restrizione.

3 - La sincronizzazione del Genesis funziona per l'Interop devnet, ma è fallita su Perfect PeerDAS devnet La sincronizzazione del Genesis è stata completata senza problemi sull'Interop devnet, ma si è bloccata subito dopo l'epoca dell'aggiornamento Fulu su Perfect PeerDAS. Se un nodo non riesce a ottenere tutte le colonne durante la sincronizzazione del Genesis, dovrebbe idealmente interrogare peer aggiuntivi per colmare le lacune, cosa che non è ancora implementata in nessun client. Se questo recupero di colonne tra peer diventi una funzionalità necessaria prima del Fusaka è ancora aperto; la decisione è attesa per il prossimo giovedì all'ACD.

4 - Riempimento della custodia dei validatori riuscito su @Teku_Consensys Il riempimento della custodia dei validatori consente a un client di rilevare colonne storiche mancanti e di recuperarle automaticamente dai peer. Il nostro test dedicato ha confermato che l'implementazione di Teku funziona perfettamente: ha identificato le lacune e le ha riempite completamente senza intoppi in condizioni normali. È stato identificato un piccolo bug in un caso limite in cui c'era una grande lacuna nella catena senza alcun blob, che è stato rapidamente risolto dal team. Altri client stanno ora lavorando su questa funzionalità, e sarà testata nei futuri devnet di Sunnyside man mano che l'implementazione sarà completata.

Sunnyside Labs continuerà a gestire devnet questa settimana, concentrandosi sui seguenti argomenti: - Interoperabilità del Devnet con limiti di larghezza di banda supernode più elevati e periodi di tempo più lunghi - Maggiore analisi sui test di sincronizzazione del genesi su Perfect PeerDAS devnet - Più devnet focalizzati sulla dimensione massima del blocco (in formato compresso snappy), nodi corrotti con blobber e finalità su rete divisa.