🚨 Il report del devnet di Sunnyside (30/09) è appena uscito — riguarda il devnet-5 che ha funzionato a ~11% della scala del mainnet (~1.7K nodi completi). Se ti interessa la scalabilità dei blob e i limiti della rete, questa è una lettura essenziale. Un thread 🧵
Test in Prod (Sunnyside Labs)
Test in Prod (Sunnyside Labs)16 set 2025
Sunnyside Labs, insieme a @ethPandaOps, @Optimism e @base, ha lanciato un altro mega-devnet per Fusaka, con 56K validatori e 1.7K nodi completi - circa l'11% della scala mainnet - e supportando fino a 72 blob.
Il throughput dei blob su devnet-5 ha sostenuto 22/33 blob ed è stato esteso a 48/72, con l'uso del gas che ha raggiunto un picco vicino a ~45M. Il principale limite era la capacità di rete: i fullnode con limiti di upload di 50Mbps hanno costantemente raggiunto il limite a 48/72 blob.
A differenza dei nostri precedenti piccoli devnet, i picchi P2P di EL per i nodi completi hanno completamente superato il gossip, creando una nuova instabilità su larga scala. Il lato EL del networking è ora la principale fonte di volatilità. I picchi di upload del gossip nella colonna si sono attenuati, probabilmente perché il traffico EL stava già saturando la larghezza di banda e i nodi avevano più peer CL con cui condividere le richieste della colonna.
Sulla disponibilità, l'affidabilità di GetBlobsV2 ha chiaramente mostrato alcuni degradi con carichi più elevati. Geth e Nethermind hanno mostrato una disponibilità di blob superiore rispetto al tasso di successo, suggerendo che spesso detenevano solo blob parziali — suggerendo che consentire restituzioni parziali dall'API GetBlobs potrebbe aiutare le prestazioni di CL con conteggi di blob più elevati. Nel frattempo, le prestazioni dell'API GetBlob di Reth sono notevolmente migliorate, raddoppiando i conteggi dei peer (~120 contro ~40–60) e finalmente liberandosi dai problemi di sincronizzazione/OOM del passato.
Conclusione: Fusaka sbloccherà il supporto per più blob per L2, mentre i BPO attualmente programmati scaleranno fino a un obiettivo di 14 blob per blocco (con un massimo di 21). Per superare questo limite, è necessaria un'attenzione particolare ai colli di bottiglia critici evidenziati in questo rapporto — vale a dire la larghezza di banda in upload, la stabilità della rete P2P e gli outlier specifici del client. La priorità immediata dovrebbe essere il miglioramento dell'efficienza della larghezza di banda e la raffinazione della gestione dei blob da parte del client, come abilitare i ritorni parziali tramite l'API GetBlobs. Sunnyside Labs rimane impegnata a far progredire queste aree e continuerà a lavorare per spingere la capacità di throughput dei blob ai suoi limiti — ma sempre in un modo che garantisca che la rete operi in modo sicuro e affidabile.
2,88K