Bridge exploit — це атака на механізм, який передає токени або повідомлення між блокчейнами. Міст має підтвердити подію в одній мережі й дозволити відповідну дію в іншій. Якщо зловмисник обходить цю перевірку, отримує достатньо ключів підписантів або використовує помилку смартконтракту, він може домогтися несанкціонованого випуску чи виведення активів.
- Як працює блокчейн-міст
- Що саме називають exploit
- Чому наслідки бувають великими
- Чотири відомі інциденти 2022 року
- Ronin: поріг 5-of-9, а не 4-of-5
- Nomad: хибна автентифікація повідомлень
- Harmony Horizon: ключі, а не код контракту
- Як читати заяви про безпеку
- Ризик не закінчується після переказу
- Що перевірити перед операцією
- Часті запитання
- Чи можна назвати міст безпечним після кількох аудитів?
- Чим bridge exploit відрізняється від зламу блокчейну?
- Чи захищає велика кількість валідаторів?
Як працює блокчейн-міст
Блокчейни не перевіряють стан інших мереж автоматично. Тому міст додає окремий механізм передавання та перевірки повідомлень. У поширеній моделі актив блокують у вихідній мережі, а в цільовій випускають його забезпечене представлення. Під час повернення представлення спалюють, після чого оригінал розблоковують. Існують також пули ліквідності та моделі burn-and-mint, тому не кожен міст працює однаково.
Перевірку можуть виконувати зовнішні підписанти, валідатори, оракули, light client або криптографічний доказ. Кожна модель має власні припущення про довіру. Тому безпека активу після перенесення може залежати не лише від двох базових блокчейнів, а й від коду мосту, ключів операторів, процедури оновлення та зовнішньої інфраструктури.
Що саме називають exploit
Exploit — це спосіб використати конкретну слабкість системи. Для мостів типові чотири групи проблем:
- помилка перевірки повідомлення — цільовий контракт приймає підроблене або вже використане підтвердження;
- компрометація ключів — атакувальник отримує порогову кількість підписів для несанкціонованого виведення;
- помилка смартконтракту — хибна логіка обліку, ініціалізації, прав доступу або оновлення;
- операційна атака — уразливість серверів, інтерфейсу, залежностей чи процесів керування відкриває шлях до критичних повноважень.
Чому наслідки бувають великими
Міст може утримувати значний резерв активів або мати право випускати токени в іншій мережі. Одна помилка в перевірці міжмережевого повідомлення впливає одразу на кілька контрактів і екосистем. Додаткову складність створюють різні правила фінальності, оновлення контрактів, аварійні повноваження та залежність від зовнішніх підписантів.
Аудит зменшує частину ризиків, але не є гарантією. Код може змінитися після перевірки, а інцидент може виникнути в управлінні ключами чи інфраструктурі, якої аудит смартконтракту не охоплював. Кількість валідаторів також сама по собі нічого не доводить: важливі поріг підпису, незалежність операторів і те, чи не контролює одна сторона кілька ключів.
Чотири відомі інциденти 2022 року
| Міст | Дата | Підтверджений механізм | Активи |
|---|---|---|---|
| Wormhole | 2 лютого 2022 | обхід перевірки міжмережевого повідомлення на стороні Solana | 120 000 незабезпечених wETH; тоді близько $325 млн |
| Ronin | 23 березня 2022 | компрометовано п’ять із дев’яти ключів валідаторів, достатніх для порога 5-of-9 | 173 600 ETH і 25,5 млн USDC |
| Harmony Horizon | 23 червня 2022 | компрометовано щонайменше два з чотирьох приватних ключів; двох підписів було достатньо | приблизно $100 млн |
| Nomad | 1 серпня 2022 | помилка ініціалізації Replica порушила автентифікацію повідомлень | приблизно $190 млн |
Суми в доларах — оцінки на час подій і можуть відрізнятися між звітами через рух цін та склад активів. Точнішу картину дають кількості токенів і технічний опис.
Ronin: поріг 5-of-9, а не 4-of-5
Атакувальник отримав контроль над п’ятьма ключами з дев’яти, серед них — ключ валідатора Axie DAO. Саме п’ять підписів дозволили провести два несанкціоновані виведення. Пізніше влада США пов’язала атаку з Lazarus Group.
Nomad: хибна автентифікація повідомлень
У власному аналізі Nomad пояснив, що після оновлення значення нульового кореня в Replica фактично стало прийнятним. Через це підроблені повідомлення могли пройти перевірку, якщо їх ще не обробляли. Проблема була не звичайною «підробкою доказу» користувачем, а конкретною помилкою ініціалізації та логіки автентифікації.
Harmony Horizon: ключі, а не код контракту
Harmony повідомила, що доказів зламу смартконтракту не було. Зловмисник скомпрометував ключі підписантів; у подальшому поріг Ethereum-сторони мосту підвищили до 4-of-5.
Як читати заяви про безпеку
- «Аудит пройдено». Перевірте дату, версію коду, обсяг аудиту та виправлення зауважень.
- «Децентралізований». З’ясуйте кількість незалежних операторів, поріг підпису й аварійні повноваження.
- «Trustless». Подивіться, хто перевіряє стан іншої мережі та які зовнішні компоненти потрібні.
- «Застраховано». Умови, винятки, ліміти й процедура вимоги важливіші за саме слово.
- «Великий TVL». Значний резерв показує використання, але водночас збільшує потенційний збиток.
Список аудитів, bug bounty, документація, відкритий код, моніторинг і план реагування допомагають оцінити процес безпеки. Жодна окрема ознака не доводить, що експлойт неможливий.
Ризик не закінчується після переказу
Якщо користувач отримав wrapped token, його вартість може й надалі залежати від резерву та працездатності мосту. Отже, завершена транзакція не завжди завершує експозицію. Для нативних міжмережевих токенів, пулів ліквідності та канонічних L2-мостів набір залежностей інший, тому оцінювати потрібно конкретний маршрут.
Що перевірити перед операцією
- Переконатися, що адреса інтерфейсу та контракти відповідають офіційній документації.
- Прочитати модель верифікації, поріг підпису, права на оновлення й аварійну зупинку.
- Зіставити версію розгорнутого коду з останніми аудитами та перевірити відкриті критичні зауваження.
- Зрозуміти, який актив буде отримано: нативний, wrapped чи виданий пулом ліквідності, і від чого залежить його погашення.
- Врахувати ризики всього маршруту, включно з агрегатором, гаманцем, RPC та цільовим протоколом.
Цей перелік пояснює технічні ризики й не є рекомендацією проводити операцію. У разі інциденту слід зупинити нові перекази через уражений маршрут і перевіряти повідомлення команди в її офіційних каналах; самостійні «сервіси повернення коштів» можуть бути фішингом.
Часті запитання
Чи можна назвати міст безпечним після кількох аудитів?
Ні. Аудити дають корисні докази для конкретної версії та обсягу перевірки, але не охоплюють автоматично ключі, сервери, майбутні оновлення й усі можливі помилки.
Чим bridge exploit відрізняється від зламу блокчейну?
У більшості відомих випадків базові блокчейни продовжували працювати за правилами. Зламували додатковий протокол, який передавав повідомлення або керував резервом між ними.
Чи захищає велика кількість валідаторів?
Лише разом з достатнім порогом, незалежністю операторів і захищеним керуванням ключами. Великий список вузлів не допомагає, якщо одна сторона контролює критичний поріг.
Джерела: ethereum.org: архітектура та ризики мостів; ООН: звіт із даними про атаку Ronin; ФБР: атрибуція атаки Harmony Horizon; Harmony: підсумок інциденту Horizon; Nomad: аналіз першопричини; Wormhole: документація VAA. Перевірено 18 вересня 2026 року.
