Laporan PeerDAS Devnet 7/14 Sunnyside ada di sini! Mari selami status PeerDAS saat ini - berapa banyak blob yang dapat kita tangani, dan apa kemacetannya?

Di antara upaya tersebut, peran Sunnyside adalah menjalankan devnet mingguan dalam berbagai konfigurasi dan memberi makan pengembang inti dengan wawasan yang dihasilkan: • Di mana batas PeerDAS saat ini terletak •Komponen mana yang membuat kemacetan • Seberapa baik pengoptimalan seperti Supernode dan GetBlobV2 bekerja dalam praktik

Tujuan utama kami adalah untuk menguji dengan cepat dan fleksibel dengan cara yang melengkapi apa yang dilakukan tim lain seperti @ethPandaOps di fusaka-devents, memberikan umpan balik tepat waktu yang mendukung implementasi PeerDAS yang sedang berlangsung.

Pada minggu ini, kami mengoperasikan 12 devnet dan menjalankan 3 rangkaian pengujian, menggunakan gambar fusaka-devnet-2 terbaru @ethPandaOps: 1.Throughput Blob (blob maks per blok) 2. Bandwidth Jaringan (uji beban berkelanjutan) 3. Pembatasan Bandwidth (batas 30 / 20 / 10 Mbps)

1 – Uji Throughput Blob Hasil pengujian menunjukkan bahwa sebagian besar klien CL dapat menangani 84 blob per blok atau lebih, dan tetap stabil dengan setidaknya 40 blob. Beberapa klien mencatat jumlah blob maksimum yang relatif lebih rendah dibandingkan dengan devnet sebelumnya - tetapi ini mungkin karena jumlah validator per simpul di devnet ini dikurangi dari 100 menjadi 8, yang pada gilirannya menurunkan tingkat partisipasi subnet setiap simpul.

2 – Tes Bandwidth Jaringan Tidak seperti devnet sebelumnya di mana jaringan sering menjadi tidak stabil pada jumlah blob yang tinggi, kali ini semua devnet berjalan secara stabil untuk waktu yang lama (~16 jam) bahkan dengan 60 atau 72 blob per blok. Meskipun ini tidak menjamin stabilitas tingkat produksi, ini menunjukkan bahwa setidaknya beberapa kombinasi CL-EL telah mencapai tingkat ketahanan yang jauh lebih tinggi melalui pengoptimalan 🚀

3 – Tes Pembatasan Bandwidth Untuk memeriksa apakah staker rumah nyata dapat berpartisipasi dengan lancar setelah PeerDAS aktif, tes ini menerapkan batas jaringan dan memeriksa faktor mana yang menjadi hambatan dalam berbagai skenario terbatas. Di beberapa pengujian, kami menemukan bahwa penggunaan bandwidth node meningkat secara berkala - terutama di dekat awal slot saat blob digosip - dan bahwa lonjakan ini membatasi performa jaringan secara keseluruhan. Lalu lintas burst terjadi secara seragam di seluruh node daripada disebabkan oleh klien CL atau EL tertentu, dan setelah burst dimulai, jaringan tidak dapat meningkatkan throughput blob lebih jauh. Dengan kata lain, lalu lintas burst adalah hambatan terbesar di lingkungan yang dibatasi bandwidth, dan kita perlu menemukan cara untuk menguranginya.

Selain itu, kami berkomunikasi dengan berbagai tim klien dan mendorong penyempurnaan untuk sinkronisasi dan masalah terkait rekan kerja.

Sunnyside devnet masih berjalan 🏗️; melakukan interop-devnet dengan beberapa kombinasi klien, pengujian bandwidth yang lebih terperinci, pengujian spam yang mencakup transaksi normal, dan pengujian pengisian ulang/sinkronisasi, untuk mengidentifikasi kemacetan di lingkungan yang lebih mirip dengan kondisi mainnet.