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 eseguire devnet settimanali in molte configurazioni diverse e fornire agli sviluppatori principali le informazioni risultanti: •Dove si trovano gli attuali limiti PeerDAS •Esattamente quali componenti creano colli di bottiglia •Come funzionano in pratica ottimizzazioni come Supernodes e GetBlobV2

Il nostro obiettivo principale è quello di testare in modo rapido e flessibile in modo complementare a ciò che altri team come @ethPandaOps stanno facendo in fusaka-devents, fornendo un feedback tempestivo che supporti l'implementazione in corso di PeerDAS.

In questa settimana, abbiamo gestito 12 devnet e eseguito 3 suite di test, utilizzando l'ultima immagine fusaka-devnet-2 di @ethPandaOps: 1.Velocità effettiva dei BLOB (numero massimo di BLOB per blocco) 2. Larghezza di banda della rete (test a carico sostenuto) 3. Limitazione della larghezza di banda (30 / 20 / 10 Mbps caps)

1 – Test di velocità effettiva del BLOB I risultati dei test hanno mostrato che la maggior parte dei client CL era in grado di gestire 84 BLOB per blocco o più ed è rimasta stabile con almeno 40 BLOB. Alcuni client hanno registrato un numero massimo di BLOB relativamente inferiore rispetto alle devnet precedenti, ma ciò potrebbe essere dovuto al fatto che il numero di validatori per nodo in questa devnet è stato ridotto da 100 a 8, il che a sua volta ha ridotto il tasso di partecipazione alla subnet di ciascun nodo.

2 – Test della larghezza di banda della rete A differenza delle devnet precedenti, in cui la rete diventava spesso instabile a causa di un numero elevato di blob, questa volta tutte le devnet sono state eseguite stabilmente per un periodo prolungato (~16 ore) anche con 60 o 72 blob per blocco. Sebbene ciò non garantisca la stabilità a livello di produzione, dimostra che almeno alcune combinazioni CL-EL hanno raggiunto un livello di robustezza molto più elevato attraverso l'ottimizzazione 🚀

3 – Test di vincolo della larghezza di banda Per verificare se gli staker domestici reali possono partecipare senza problemi una volta che PeerDAS è attivo, questo test ha applicato i limiti della rete e ha esaminato quali fattori diventano colli di bottiglia in vari scenari vincolati. In più test abbiamo scoperto che l'utilizzo della larghezza di banda del nodo aumenta periodicamente, soprattutto all'inizio di uno slot quando i blob vengono spettegolati, e che questi picchi limitano le prestazioni complessive della rete. Il traffico burst si è verificato in modo uniforme tra i nodi anziché essere causato da un particolare client CL o EL e, una volta iniziati i burst, la rete non è stata in grado di aumentare ulteriormente il throughput dei blob. In altre parole, il burst del traffico è il più grande collo di bottiglia negli ambienti con larghezza di banda limitata e dobbiamo trovare il modo di mitigarlo.

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

La devnet di Sunnyside è ancora in esecuzione 🏗️; Esecuzione di interop-devnet con più combinazioni di client, test di larghezza di banda più granulari, test di spam che includono transazioni normali e test di backfill/sincronizzazione, per identificare i colli di bottiglia in ambienti che assomigliano più da vicino alle condizioni della mainnet.