Актуальні теми
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Звіт 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 з декількома комбінаціями клієнтів, більш детальні тести пропускної здатності, тести на спам, які включають звичайні транзакції, і тести зворотного заповнення/синхронізації, щоб виявити вузькі місця в середовищах, які більше нагадують умови основної мережі.
743
Найкращі
Рейтинг
Вибране