Після фінансування через два дні виявили критичну уразливість. Чи зможе Babylon виправити цю бомбу сповільнення до другого кварталу?

Babylon щойно отримала інвестицію в розмірі 15 мільйонів доларів від a16z 7 січня, а 9 січня була виявлена вразливість коду. Це не збіг, а відображення справжнього стану високоризикованих інфраструктурних проектів — проблеми безпеки часто виявляються лише після фінансування. Ця вразливість стосується основного механізму консенсусу Babylon, і якщо її не виправити вчасно, вона може вплинути на стабільність усієї мережі.

Технічні деталі вразливості

Ця вразливість розташована в схемі розширення BLS-голосування Babylon, яка є ключовим компонентом підписання блоків. Конкретно:

• Вразливість дозволяє зловмисним валідаторам навмисно пропустити поле хешу блоку при надсиланні розширення голосування
• Поле хешу блоку служить для інформування інших валідаторів про те, які саме блоки вони фактично підтримують своїми голосами
• Пропуск цього поля призводить до того, що валідатори не можуть підтвердити об’єкт своїх голосів, порушуючи прозорість консенсусу

Це звучить як незначна проблема, але в консенсусі блокчейна це еквівалентно голосуванню без позначення кандидатів — весь процес голосування втрачає сенс.

Наскільки велики потенційні наслідки

Згідно з попередженнями розробників, шкода від цієї вразливості проявляється насамперед на границях епох (критичні періоди переходу мережі):

Зловмисні валідатори можуть скористатися цією вразливістю для краху інших валідаторів під час перевірок консенсусу на границі етапів. Якщо одночасно потраплять під вплив одночасно кілька валідаторів, швидкість генерування блоків у мережі помітно сповільниться. Для протоколу стейкингу це критично — користувачі отримуватимуть менший дохід від стейкингу через повільне генерування блоків.

Однак поки що немає описів фактичного використання цієї вразливості. Це означає, що або зловмисники ще не виявили цю вразливість, або виявили, але ще не почали її використовувати. Обидва сценарії вказують на невідкладність виправлення.

Часовий збіг фінансування та вразливості

З погляду часової шкали цей момент виявлення дуже цікавий. Babylon повинна була пройти аудит коду перед фінансуванням, проте ця вразливість все ще перебувала в коді. Це відображає дві реальності:

По-перше, навіть після аудиту вразливості можуть залишитися без уваги. Це поширено в складних криптографічних протоколах — сама схема BLS-підписання досить складна, а логіка розширення голосування ще складніша.

По-друге, аудити коду після фінансування часто проводяться більш суворо. З такою великою інвестицією від a16z обов’язково будуть потребувати більш глибокої перевірки безпеки, що могло бути причиною виявлення вразливості за два дні після фінансування.

Оцінка впливу на екосистему Babylon

У короткостроковій перспективі ринок може відреагувати. Власники токенів BABY занепокоюватимуться тим, чи вплине ця вразливість на прогрес проекту. Але у довгостроковій перспективі це залежить від кількох факторів:

Швидкість виправлення: Babylon потребує виправлення перед інтеграцією з Aave у Q2. Якщо патч буде випущено протягом тижня-двох, вплив буде мінімальним. Якщо це займе місяці, це може затримати плани інтеграції.

Якість виправлення: Виправлення самої вразливості недостатньо, потрібно переконатися, що процес виправлення не внесе нових вразливостей. Це потребує додаткового часу на аудит.

Довіра ринку: Своєчасне розкриття вразливості розробниками — це позитив, що свідчить про відповідальність проекту. Але якщо часто виникатимуть подібні проблеми, інвестори почнуть сумніватися в якості коду.

Підсумок

Ця вразливість Babylon не є критичною, але дуже важлива. Вона нагадує всій індустрії, що для інфраструктурних проектів як біткойн-стейкинг безпека повинна бути на першому місці. Фінансування в розмірі 15 мільйонів доларів — це визнання, але якщо код небезпечний, жодна кількість грошей не допоможе.

З технічної точки зору сам процес виявлення цієї вразливості є нормальним — у складних системах завжди будуть пропуски, важливо як на них реагувати. Babylon тепер потрібно довести, що вона може швидко та повністю вирішити цю проблему та запобігти подібним проблемам у майбутньому. Подальша увага повинна зосередитися на темпі виправлення та графіку інтеграції з Aave у Q2.