Звіт Sunnyside 7/14 PeerDAS Devnet тут! Давайте зануримося в поточний стан PeerDAS - скільки ляпок ми можемо обробити і в чому проблема?

Серед цих зусиль, роль Sunnyside полягає в тому, щоб запускати щотижневі devnet у різних конфігураціях і надавати основним розробникам отримані ідеї: •Де лежать поточні обмеження PeerDAS •Які саме компоненти створюють вузькі місця •Наскільки добре оптимізації, такі як Supernodes і GetBlobV2, працюють на практиці

Наша головна мета — швидко та гнучко тестувати таким чином, щоб доповнити те, що роблять інші команди, як @ethPandaOps, на fusaka-devents, надаючи своєчасний зворотний зв'язок, який підтримує поточне впровадження PeerDAS.

За цей тиждень ми запустили 12 devnet і запустили 3 набори тестів, використовуючи останній образ fusaka-devnet-2 @ethPandaOps: 1. Пропускна здатність Blob (максимальна кількість плям на блок) 2. Пропускна здатність мережі (тест тривалого навантаження) 3. Обмеження пропускної здатності (обмеження 30 / 20 / 10 Мбіт/с)

1 – Тест пропускної здатності BLOB Результати тестів показали, що більшість клієнтів CL могли обробляти 84 ляпки на блок або більше, і залишалися стабільними принаймні з 40 ляпами. Деякі клієнти зафіксували відносно нижчу максимальну кількість BLOB порівняно з попередніми devnet - але це може бути пов'язано з тим, що кількість валідаторів на вузол у цій devnet була зменшена зі 100 до 8, що, у свою чергу, знизило рівень участі кожного вузла в підмережі.

2 – Тест пропускної здатності мережі На відміну від більш ранніх девентів, де мережа часто ставала нестабільною при великій кількості блобів, цього разу всі devnet працювали стабільно протягом тривалого періоду (~16 годин) навіть з 60 або 72 ляпами на блок. Хоча це не гарантує стабільності на рівні виробництва, це свідчить про те, що принаймні деякі комбінації CL-EL досягли набагато вищого рівня надійності завдяки оптимізації 🚀

3 – Тест на обмеження пропускної здатності Щоб перевірити, чи можуть реальні домашні стейкери безперешкодно брати участь після активності PeerDAS, цей тест застосував обмеження мережі та вивчив, які фактори стають вузькими місцями в різних сценаріях з обмеженнями. Під час численних тестів ми виявили, що використання пропускної здатності вузла періодично зростає - особливо на початку слоту, коли пліткують про блоби - і що ці сплески обмежують загальну продуктивність мережі. Сплеск трафіку відбувався рівномірно на всіх вузлах, а не був викликаний конкретним клієнтом CL або EL, і як тільки починалися сплески, мережа не могла більше збільшити пропускну здатність BLOB. Іншими словами, вибуховий трафік є найбільшим вузьким місцем у середовищах з обмеженою пропускною здатністю, і нам потрібно знайти способи його пом'якшення.

Крім того, ми спілкувалися з різними командами клієнтів і заохочували вдосконалення для синхронізації та проблем, пов'язаних з колегами.

Devnet Sunnyside все ще працює 🏗️; Проведення interop-devnet з декількома комбінаціями клієнтів, більш детальні тести пропускної здатності, тести на спам, які включають звичайні транзакції, і тести зворотного заповнення/синхронізації, щоб виявити вузькі місця в середовищах, які більше нагадують умови основної мережі.