Peg-out Liquid na 320 mln dolarów: jak 4 tys. BTC opuściło rezerwę bez przejęcia kluczy

Około 4 tys. BTC — wówczas wycenianych na ok. 320 mln dolarów — opuściło portfel federacji zabezpieczający L-BTC w sieci Liquid. Było to mniej więcej 95% raportowanej rezerwy. Liquid wstrzymał działanie mostu, a dostępne relacje wskazują na domniemany błąd inflacyjny oprogramowania Elements, nie zaś na kradzież kluczy federacji czy klucza autoryzacji SideSwap. Pełne techniczne szczegóły luki nadal nie zostały publicznie ujawnione. 413

Co miało się wydarzyć

Zgłaszany przebieg zdarzeń jest dość klarowny, choć sama luka wciąż nie została w pełni opisana:

1. Nieznany podmiot miał utworzyć L-BTC bez zablokowanego w zamian BTC, wykorzystując błąd w Elements.
2. Tak powstałe L-BTC miało zostać przekazane do standardowej usługi peg-out SideSwap, czyli wykupu L-BTC na BTC w głównym łańcuchu Bitcoina.
3. Peg-out przeszedł przy użyciu prawidłowego klucza Peg-out Authorization Key (PAK) SideSwap; Liquid i SideSwap oświadczyły, że klucz nie został skompromitowany.
4. Infrastruktura federacji Liquid zatwierdziła wypłatę BTC. Relacje mówią o ok. 3996 BTC wypłaconych w jednej operacji i o ok. 4 tys. BTC w całym zdarzeniu. 26

Sednem problemu nie miało więc być przejęcie kluczy kontrolujących rezerwę. Według zgłaszanej wersji system uznał żądanie wykupu za spełniające warunki autoryzacji, mimo że L-BTC przedstawione do wykupu nie miało prawidłowego ekonomicznego pokrycia.

Dlaczego HSM-y podpisały wypłatę, skoro klucze nie wyciekły?

Liquid działa w modelu Strong Federations: grupa członków federacji wspólnie obsługuje sidechain i poprzez podpisy progowe kontroluje rezerwę BTC po stronie głównego łańcucha. Oficjalna dokumentacja Liquid określa ten model konsensusu właśnie jako Strong Federations.

Sprzętowe moduły bezpieczeństwa, czyli HSM-y, mają chronić klucze podpisujące i wymuszać zaprogramowane polityki. Nie są jednak niezależnym audytorem całej historii emisji danego aktywa ani jego realnego pokrycia. Jeżeli zlecenie peg-out zawiera dane, które system rozpoznaje jako ważne — w tym poprawną ścieżkę autoryzacji — HSM może złożyć podpis bez jakiegokolwiek wycieku klucza prywatnego.

W tym incydencie kluczowe jest rozróżnienie między dwoma pojęciami:

• Autoryzacja: peg-out został podobno przeprowadzony z użyciem prawidłowego PAK SideSwap.
• Pochodzenie i pokrycie: przedstawione do wykupu L-BTC miało zostać stworzone przez błąd Elements, a nie w zwykłym procesie emisji zabezpieczonej BTC. 2

SideSwap podał, że peg-out na ok. 4 tys. BTC trafił do jego usługi jako zlecenie klienta, jego PAK nie został skompromitowany, a L-BTC pochodziło z błędu Elements, a nie z systemów SideSwap.

Nie oznacza to zatem porażki kryptografii podpisów progowych ani samej ochrony HSM. Wspólny błąd w logice emisji albo walidacji może sprawić, że poprawnie działające automatyczne podpisywanie zatwierdzi wypłatę, która nigdy nie powinna kwalifikować się do wykupu. Poprawny podpis dowodzi spełnienia polityki podpisu — nie dowodzi sam w sobie, że wykupywane aktywo było właściwie zabezpieczone.

Czy sprawcy rzeczywiście byli „white hatami”?

Podmiot kontrolujący środki dołączył do transakcji wiadomość on-chain: „we are whitehats. contact us on chain” („jesteśmy white hatami, skontaktujcie się z nami on-chain”). 16

Z relacji wynika też, że Blockstream i Liquid kontaktowały się ze sprawcami przez podpisane wiadomości on-chain. Sprawcy mieli zaoferować zwrot „większości” środków po naprawieniu luki w całej sieci. 418

To potwierdza jedynie, że sami przedstawiają się jako badacze bezpieczeństwa i pozostawili kanał komunikacji. Nie stanowi niezależnego dowodu ich statusu ani intencji. W chwili opisywanej w raportach środki nie zostały potwierdzenie zwrócone, a publicznego wdrożenia poprawki ani ponownego uruchomienia sieci również nie potwierdzono. 13

Najtrafniejszym określeniem pozostaje więc „rzekomi white hati”. Ocena może się zmienić dopiero po zwrocie środków, weryfikacji szczegółów exploitu i niezależnym potwierdzeniu działań naprawczych.

Reakcja Liquid, SideSwap i giełd

Liquid wyłączył węzły mostu i wstrzymał operacje, blokując zwykłe transfery między Bitcoinem a Liquid. Giełdy zostały powiadomione, aby wstrzymać — lub przygotować się do wstrzymania — wpłaty i wypłaty L-BTC. 48

SideSwap poinformował, że zawiesił peg-iny i peg-outy na czas wstrzymania Liquid.

Są to działania ograniczające skutki zdarzenia: mają zatrzymać dalszy ruch przez most w okresie badania luki, oceny stanu rezerw i ustalania warunków bezpiecznego wznowienia działania. Według relacji plan odzyskania sprawności zależał od usunięcia błędu, aktualizacji dotkniętych nim węzłów oraz wyjaśnienia losu wypłaconych BTC. 1318

Co to oznacza dla posiadaczy L-BTC

L-BTC ma reprezentować BTC w sieci Liquid. W praktyce jego równoważność z BTC zależy jednak od dostępności mostu i wiarygodnego, faktycznego pokrycia rezerwą.

Jeśli z rezerwy wynoszącej ok. 4,2 tys. BTC wypłacono ok. 4 tys. BTC, a most pozostaje wstrzymany, zwykły wykup L-BTC na BTC został zakłócony, a ewentualna luka w pokryciu stała się natychmiastowym problemem dla użytkowników. 313

Nie przesądza to jeszcze o końcowym wyniku ani o tym, czy użytkownicy poniosą ostateczną stratę. Oznacza jednak, że w trakcie incydentu posiadanie L-BTC nie było operacyjnie tym samym co posiadanie BTC, które można swobodnie wypłacić w głównym łańcuchu Bitcoina. Wynik zależy od odzyskania środków, naprawy domniemanej luki, decyzji federacji i polityk dostawców usług.

Pozostałe aktywa wyemitowane na Liquid

Samo wypłacenie BTC z portfela federacji nie oznacza automatycznie uszczuplenia rezerw emitentów innych aktywów na Liquid. Liquid stwierdził, że aktywa takie jak USDT, DePix i RWA nie zostały bezpośrednio dotknięte samym incydentem.

„Niedotknięte” nie znaczy jednak „wolne od ryzyka”. Zatrzymanie sieci może ograniczać działanie portfeli, wsparcie giełd, płynność i możliwość wykonywania transakcji. Może też utrudniać użycie L-BTC, które pełni rolę aktywa opłat i głównego aktywa mostowego. Bezpośrednie pokrycie każdego z tych aktywów zależy od jego własnego emitenta i modelu przechowywania rezerw, natomiast użyteczność operacyjna zależy od powrotu infrastruktury Liquid do normalnego działania.

Lekcja architektoniczna: federacja a most w stylu BitVM

Obecna konstrukcja Liquid opiera się na znanej, uprawnionej federacji i rezerwie kontrolowanej podpisami progowymi. To coś innego niż model, w którym konsensus Bitcoina bezpośrednio weryfikuje, czy każdy wykup ma pokrycie.

Obecny peg federacyjny	Planowany kierunek BitVM 1-of-n
Stała federacja kontroluje rezerwę BTC przez podpisy progowe.	Blockstream opisuje go jako długoterminową inicjatywę badawczą, a nie wdrożony następca Liquid.
Bezpieczeństwo zależy od ochrony kluczy, działania sygnatariuszy oraz poprawności wspólnego oprogramowania walidacyjnego i polityk.	Celem jest obniżenie założeń zaufania względem konwencjonalnych konstrukcji z podpisami progowymi.
Wspólny błąd oprogramowania może sprawić, że wszyscy automatyczni sygnatariusze zaakceptują tę samą błędną interpretację.	Systemy w stylu BitVM wykorzystują optymistyczną weryfikację i mechanizmy zakwestionowania; bezpieczeństwo zależy od poprawnego protokołu oraz aktywnego, uczciwego podmiotu kwestionującego.

Model BitVM nie usuwa ryzyka mostu — przenosi je na inne założenia. Podmioty monitorujące muszą móc i chcieć reagować, proces dowodu oszustwa musi być poprawny, a wypłaty mogą być bardziej złożone lub wolniejsze. Badania nad mostami opartymi na BitVM wskazują model bezpieczeństwa wymagający co najmniej jednego uczciwego uczestnika, zaś BitVM2 zakłada, że w trakcie działania każdy może zakwestionować nieprawidłowe twierdzenie.

Jeżeli zgłaszany mechanizm incydentu zostanie potwierdzony, pokazuje on istotę tej różnicy: federacja podpisów progowych może skutecznie chronić przed kradzieżą kluczy, a mimo to pozostawać podatna, gdy wszyscy jej sygnatariusze opierają się na tej samej wadliwej interpretacji tego, czy aktywo jest ważne i kwalifikuje się do wykupu.

Najważniejszy wniosek

Zgłoszone zdarzenie w Liquid o wartości ok. 320 mln dolarów wygląda nie na klasyczną kradzież kluczy prywatnych, lecz na kryzys walidacji mostu. Partia rzekomo niepokrytego L-BTC miała przejść autoryzowaną ścieżkę peg-out, po czym federacja wypłaciła rzeczywiste BTC. 24

Najważniejsze pytania pozostają otwarte: jaki dokładnie był błąd w Elements, jaki jest ostateczny stan rezerw i pokrycia L-BTC, czy środki wrócą oraz jakie zabezpieczenia muszą zostać zmienione przed bezpiecznym wznowieniem mostu. Dopóki odpowiedzi nie zostaną publicznie zweryfikowane, sprawę należy traktować jako nierozwiązaną — nie jako zakończone ujawnienie typu white hat ani zwykłą przerwę techniczną.