Як із Liquid вивели 4 000 BTC без викрадення ключів

Liquid Network призупинила роботу мосту після того, як із федеративного гаманця, який забезпечує L-BTC, вивели приблизно 4 000 BTC — орієнтовно на $320 млн на той момент. Це становило близько 95% заявленого резерву. Наявні повідомлення вказують на ймовірний інфляційний баг у програмному забезпеченні Elements, а не на викрадення ключів федерації чи ключа авторизації SideSwap. Водночас повні технічні деталі публічно ще не розкрито. 413

Що, ймовірно, сталося

Описана послідовність подій виглядає так, хоча першопричину бага ще не оприлюднено повністю:

1. Невідомі особи нібито створили L-BTC, які не були забезпечені заблокованими BTC, використавши ваду в Elements.
2. Ці L-BTC подали до звичайного сервісу peg-out від SideSwap — механізму виведення активів із Liquid назад у мережу Bitcoin.
3. Для операції використали легітимний Peg-out Authorization Key (PAK) SideSwap; Liquid і SideSwap заявили, що цей ключ не було скомпрометовано.
4. Інфраструктура федерації Liquid авторизувала видачу BTC: за повідомленнями, виплата становила близько 3 996 BTC, а загалом із резерву вийшло приблизно 4 000 BTC. 26

Тобто, за цією версією, резерв не «відкрили» через крадіжку ключів. Натомість система, ймовірно, визнала запит на виведення коректним, хоча L-BTC, які подали до погашення, не мали належного економічного забезпечення.

Чому HSM могли підписати операцію без компрометації ключів

Liquid працює за моделлю Strong Federation: учасники федерації спільно керують сайдчейном і резервом BTC через порогове підписання. Власна технічна документація Liquid називає цю модель Strong Federations.

Апаратні модулі безпеки — HSM — захищають ключі підпису та виконують задані політики. Але вони не є незалежним арбітром, здатним перевірити всю історію походження активу й гарантувати, що кожен L-BTC був випущений лише під заблокований BTC.

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

У цьому й полягає ключова відмінність повідомленого інциденту:

• Авторизація: peg-out, за повідомленнями, пройшов із легітимним PAK SideSwap.
• Походження та забезпечення: L-BTC, подані до погашення, нібито були створені через баг Elements, а не в результаті стандартного внесення BTC у міст. 2

SideSwap заявив, що peg-out приблизно на 4 000 BTC надійшов через його сервіс як клієнтське замовлення, PAK не був скомпрометований, а L-BTC походили з бага Elements, а не із систем SideSwap.

Отже, порогові підписи чи криптографія HSM, імовірно, не «зламалися». Спільний дефект у перевірці або випуску активів міг змусити справно працюючі підписанти погодити виведення, яке взагалі не мало бути допустимим. Коректний цифровий підпис підтверджує виконання політики підписання, але сам по собі не доводить, що актив, який погашається, був належно забезпечений.

Чи справді це «білі хакери»

Особи, пов’язані з транзакцією, залишили ончейн-повідомлення: «we are whitehats. contact us on chain» («ми білі хакери, зв’яжіться з нами в мережі»). 16

Також повідомлялося, що Blockstream/Liquid контактувала з ними через підписані ончейн-повідомлення, а ті нібито запропонували повернути «більшість» коштів після того, як уразливість буде виправлено на всіх вузлах мережі. 418

Це підтверджує лише те, що учасники операції заявили про дослідницький мотив і залишили канал зв’язку. Але цього недостатньо, щоб незалежно вважати їх «білими хакерами». На час публікацій повернення коштів не було підтверджено, як і не було підтверджено публічного патчу чи відновлення мережі. 13

Точніше називати їх особами, які називають себе білими хакерами. Остаточна оцінка можлива лише після перевіреного повернення коштів, розкриття механізму експлойту та незалежного підтвердження виправлення.

Реакція Liquid, SideSwap і бірж

Liquid вимкнула вузли мосту та призупинила операції, зупинивши звичайне переміщення коштів між Bitcoin і Liquid. Біржі повідомили про необхідність призупинити або підготуватися до призупинення депозитів і виведень L-BTC. 48

SideSwap заявив про паузу peg-in і peg-out, доки Liquid залишається на паузі.

Це заходи стримування: вони обмежують подальший рух через міст, доки оператори розслідують імовірну вразливість, оцінюють стан резерву та визначають умови безпечного перезапуску. За повідомленнями, план відновлення залежав від виправлення помилки, оновлення зачеплених вузлів і врегулювання статусу виведених BTC. 1318

Що це означає для власників L-BTC

L-BTC задуманий як Bitcoin у мережі Liquid. Проте на практиці його еквівалентність BTC залежить від доступності мосту та переконливого забезпечення резервами.

Якщо з резерву приблизно у 4 200 BTC було виведено близько 4 000 BTC, а роботу мосту призупинено, звичайне погашення L-BTC у BTC стало недоступним, а дефіцит резерву — безпосередньою проблемою для власників. 313

Це ще не визначає остаточного результату для користувачів. Але під час інциденту володіння L-BTC не було операційно тотожним володінню BTC, які можна вільно вивести в базовий блокчейн Bitcoin. Подальший результат залежить від повернення коштів, усунення ймовірного бага, рішень федерації та політик провайдерів послуг.

Інші активи, випущені в Liquid

Сам факт виведення BTC із гаманця федерації не означає автоматичного вилучення резервів інших активів у Liquid. Liquid заявила, що сам інцидент не зачепив такі активи, як USDT, DePix і RWA.

Втім, «не зачепив» не означає «без ризику». Пауза мережі може вплинути на доступ через гаманці, підтримку бірж, ліквідність, проведення транзакцій та можливість використовувати L-BTC як актив для комісій і переказів через міст. Пряме забезпечення кожного активу залежить від його емітента та схеми зберігання резервів, а практична доступність — від відновлення інфраструктури Liquid.

Головний урок: безпека федерації проти моста у стилі BitVM

Поточна архітектура Liquid спирається на відому, дозвільну федерацію та порогове управління резервом. Це відрізняється від моделі, де сам консенсус Bitcoin безпосередньо перевіряє, чи забезпечене кожне погашення.

Поточний федеративний peg	Запропонований напрям BitVM у моделі 1-of-n
Фіксована федерація контролює резерв BTC через порогове підписання.	Blockstream описує це як довгостроковий дослідницький напрям, а не як уже запущену заміну Liquid.
Безпека залежить від захисту ключів, роботи підписантів і коректності спільного ПЗ для валідації та політик.	Мета — зменшити припущення щодо довіри порівняно зі звичайними пороговими схемами підпису.
Спільний програмний дефект потенційно може змусити всіх автоматизованих підписантів прийняти однакову неправильну інтерпретацію.	Системи у стилі BitVM застосовують оптимістичну верифікацію та механізми оскарження; їхня безпека залежить від коректного протоколу й наявності активного чесного учасника, здатного заперечити некоректну дію.

Модель BitVM не усуває ризики мостів. Вона переносить їх до інших припущень: має існувати учасник, здатний і готовий оскаржити шахрайську дію; механізм fraud proof повинен бути коректним; а виведення коштів може бути складнішим або повільнішим. Дослідження мостів на основі BitVM описують цільову модель безпеки як таку, що потребує щонайменше одного чесного учасника, тоді як BitVM2 прагне дозволити будь-кому оскаржити недійсне твердження під час роботи системи.

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

Висновок

Повідомлений інцидент Liquid на $320 млн виглядає як криза валідації мосту, а не як звичайна крадіжка приватних ключів. Імовірно, партія незабезпечених L-BTC пройшла авторизований шлях peg-out, після чого федерація видала реальні BTC. 24

Ключові питання досі залишаються без публічно перевіреної відповіді: якою саме була вразливість Elements, яким є остаточний стан резерву та забезпечення L-BTC, чи повернуть кошти і які контролі змінять до безпечного відновлення мосту. Поки цього не підтверджено, інцидент варто вважати невирішеним, а не завершеним розкриттям уразливості «білими хакерами» чи звичайною технічною паузою.