Il rapporto Devnet di PeerDAS di Sunnyside del 7/14 è qui! Esploriamo lo stato attuale di PeerDAS: quanto blob possiamo gestire e qual è il collo di bottiglia?

Tra questi sforzi, il ruolo di Sunnyside è quello di gestire devnet settimanali in molte configurazioni diverse e fornire ai core developer le intuizioni risultanti: •Dove si trovano i limiti attuali di PeerDAS •Quali componenti creano esattamente colli di bottiglia •Quanto bene funzionano in pratica ottimizzazioni come Supernodes e GetBlobV2

Il nostro obiettivo principale è testare rapidamente e in modo flessibile in modi che completino ciò che altri team come @ethPandaOps stanno facendo a fusaka-devents, fornendo feedback tempestivi che supportano l'implementazione in corso di PeerDAS.

In questa settimana, abbiamo operato 12 devnet e eseguito 3 suite di test, utilizzando l'ultima immagine fusaka-devnet-2 di @ethPandaOps: 1. Throughput dei Blob (max blob per blocco) 2. Larghezza di banda di rete (test di carico sostenuto) 3. Limitazione della larghezza di banda (30 / 20 / 10 Mbps)

1 – Test di throughput dei blob I risultati del test hanno mostrato che la maggior parte dei client CL poteva gestire 84 blob per blocco o più, e rimaneva stabile con almeno 40 blob. Alcuni client hanno registrato un conteggio massimo di blob relativamente più basso rispetto ai devnet precedenti - ma questo potrebbe essere dovuto al fatto che il numero di validatori per nodo in questo devnet è stato ridotto da 100 a 8, il che ha a sua volta abbassato il tasso di partecipazione della subnet di ciascun nodo.

2 – Test della larghezza di banda della rete A differenza delle precedenti devnet, dove la rete diventava spesso instabile con un alto numero di blob, questa volta tutte le devnet sono rimaste stabili per un lungo periodo (~16 ore) anche con 60 o 72 blob per blocco. Anche se ciò non garantisce stabilità a livello di produzione, dimostra che almeno alcune combinazioni CL-EL hanno raggiunto un livello di robustezza molto più elevato grazie all'ottimizzazione 🚀

3 – Test di Limitazione della Larghezza di Banda Per verificare se i veri staker domestici possono partecipare senza problemi una volta attivo PeerDAS, questo test ha applicato limiti di rete ed esaminato quali fattori diventano colli di bottiglia in vari scenari limitati. Attraverso molteplici test abbiamo scoperto che l'uso della larghezza di banda dei nodi aumenta periodicamente - specialmente vicino all'inizio di uno slot quando i blob vengono diffusi - e che questi picchi limitano le prestazioni complessive della rete. Il traffico burst si è verificato uniformemente tra i nodi piuttosto che essere causato da un particolare client CL o EL, e una volta iniziati i picchi, la rete non poteva aumentare ulteriormente il throughput dei blob. In altre parole, il traffico burst è il più grande collo di bottiglia in ambienti con larghezza di banda limitata, e dobbiamo trovare modi per mitigarne l'impatto.

Inoltre, abbiamo comunicato con vari team di clienti e incoraggiato miglioramenti per problemi di sincronizzazione e relativi ai peer.

Il devnet di Sunnyside è ancora in esecuzione 🏗️; stiamo conducendo interop-devnets con più combinazioni di client, test di larghezza di banda più granulari, test di spam che includono transazioni normali e test di riempimento/sincronizzazione, per identificare i colli di bottiglia in ambienti che somigliano di più alle condizioni della mainnet.