Nowy raport Lazarus Security Lab giełdy Bybit suggests, że wiele dużych blockchainów nie jest tak beztrustowych, jak się wydaje. W branży zbudowanej na decentralizacji wygląda to podejrzanie.
Badacze Bybit przeanalizowali kody źródłowe 166 blockchainów, łącząc analizę wspieraną przez AI z ręcznym przeglądem. Odkryli, że 16 sieci ma już wbudowane mechanizmy zamrażania środków, a kolejne 19 mogłoby je włączyć przy użyciu jedynie drobnych zmian w protokole.
Choć ich celem jest zabezpieczenie przed włamaniami i nielegalnymi transferami, ustalenia te na nowo rozpalają stare pytanie: jak bardzo zdecentralizowane są systemy stanowiące kręgosłup branży kryptowalut?
Śledztwo zostało zainspirowane głośnym incydentem: na początku tego roku Sui Foundation zamroziła ponad 160 mln dolarów w skradzionych aktywach po ataku na Cetus DEX – błyskawiczna interwencja wywołała intensywną debatę.
Jeśli fundacja może zablokować portfel hakera, aby ochronić użytkowników, co powstrzyma ją przed zamrożeniem środków kogokolwiek innego?
Raport pojawia się krótko po własnych problemach bezpieczeństwa Bybit.
Zaledwie kilka miesięcy temu giełda padła ofiarą ogromnego włamania na 1,5 mld dolarów – jednego z największych w historii krypto. W tym przypadku wkroczyli scentralizowani gracze – partnerzy tacy jak Circle i Tether zamrozili ok. 42,9 mln dolarów skradzionych stablecoinów, a inne protokoły pomogły odzyskać dodatkowe środki.
Możliwość „wciśnięcia pauzy” w nagłej sytuacji ma ewidentne zalety. Podkreśla jednak także paradoks: im bardziej sieci krypto polegają na takich „wyłącznikach awaryjnych”, aby ograniczać zagrożenia, tym bardziej zaczynają przypominać tradycyjne scentralizowane systemy, które miały zastąpić.
Zamrażanie środków w krypto: obrona przed hackami kontra ryzyko dla decentralizacji
Na blockchainie „zamrożenie” konta oznacza zatrzymanie ruchu środków – de facto unieruchomienie ich.
W praktyce zwykle robią to producenci bloków (walidatorzy) albo przez zmianę zasad protokołu, które uniemożliwiają transakcje z adresem z czarnej listy. Takie uprawnienia awaryjne pojawiły się w odpowiedzi na plagę hacków i oszustw w DeFi.
Logika jest prosta: jeśli złodzieje kradną miliony w krypto, trzeba ich zatrzymać on-chain, zanim zdążą wyprać środki.
Na przykład po exploicie na 160 mln dolarów w protokole Sui fundacja szybko wdrożyła na poziomie protokołu listę odmów (deny-list), aby zamrozić portfele hakera.
Podobnie deweloperzy BNB Chain wpisali na stałe do kodu czarną listę, by zatrzymać ruch 570 mln dolarów wyprowadzonych z mostu cross-chain w 2022 r. Już w 2019 r. VeChain wprowadził podobną listę po kradzieży tokenów o wartości 6,6 mln dolarów z portfela fundacji.
Te interwencje okazały się skuteczne pragmatycznie – ograniczyły straty.
„Nikt nie chce patrzeć, jak setki milionów znikają” – zauważył jeden z analityków branżowych.
Zamrażając skradzione aktywa, projekty zyskują czas na dochodzenie, odzyskanie środków lub negocjacje z atakującymi. W przypadku Sui ostatecznie głosowanie społeczności zatwierdziło odzyskanie zamrożonych środków z ataku na Cetus, przywracając wartość ofiarom.
Z czysto bezpieczeństwowego punktu widzenia możliwość zatrzymania transakcji to potężne narzędzie w zestawie środków reagowania kryzysowego operatorów blockchainów.
Ta sama władza, która może zatrzymać napad, może jednak podkopać podstawową ideę decentralizacji. Nieodwracalne, odporne na cenzurę transakcje mają być fundamentalną cechą publicznych blockchainów – „code is law”. Wizja, że centralna grupa może wstecznie zatrzymywać lub odwracać transakcje, stoi w sprzeczności z tą zasadą.
Krytycy twierdzą, że jeśli jakikolwiek organ może jednostronnie zamrażać aktywa w księdze, pod znakiem zapytania staje neutralność sieci.
Po awaryjnym zamrożeniu na Sui część społeczności uznała to za „zdradę ideałów decentralizacji”, zauważając, że rzekomo permissionless sieć ujawniła bardzo „permissioned” punkt kontroli. To rodzi niewygodne pytania: Kto dokładnie ma prawo przełączyć „kill switch” w „zdecentralizowanym” łańcuchu? W jakich okolicznościach? I czy takie uprawnienia mogą zostać nadużyte lub rozszerzone w przyszłości?
Nowy raport Bybit rzuca światło na rosnący kompromis między bezpieczeństwem a suwerennością. Kluczowy wniosek: funkcje zamrażania nie są rzadkimi wyjątkami – są częstsze (i ciszej wdrażane), niż większość użytkowników przypuszcza. Spośród 166 przeanalizowanych blockchainów 16 (prawie 10%) miało natywne mechanizmy zamrażania zapisane w kodzie. Co istotne, te 16 obejmuje wiele największych sieci na świecie, które łącznie odpowiadają za ponad 80% całkowitej wartości zablokowanej w DeFi. Innymi słowy, większość dzisiejszej aktywności krypto przebiega przez systemy, które ktoś – przynajmniej w określonych warunkach – może zatrzymać, filtrować lub zamrozić. Ta rzeczywistość kłóci się z popularnym przekonaniem, że blockchainy są poza czyjąkolwiek kontrolą.
Z perspektywy zarządzania ryzyka centralizacji są wyraźne.
Badacze z Lazarus Lab odnotowali, że niemal 70% udokumentowanych przez nich przypadków zamrożeń miało miejsce na warstwie walidatorów lub konsensusu – głęboko w protokole, niewidocznie na pierwszy rzut oka dla zwykłych użytkowników. W wielu przypadkach te „kontrole awaryjne” były wykonywane przez niewielką grupę insiderów: głównych deweloperów projektu, radę fundacji lub grupę czołowych walidatorów. Podmioty te nie zawsze są transparentne w procesie podejmowania decyzji. W przeciwieństwie do otwartego kodu blockchaina, te procesy ludzkiego governance często odbywają się za zamkniętymi drzwiami lub w bardzo krótkim czasie.
Ten brak przejrzystości podsyca obawy, że zaufanie jest ponownie wprowadzane do systemów, które miały być beztrustowe. Jak ujął to jeden z obserwatorów, decentralizacja często kończy się tam, gdzie zaczyna się dostęp walidatorów.
Jak działają mechanizmy zamrażania
Raport Bybit wyróżnia trzy główne kategorie funkcjonalności zamrażania on-chain.
Twardo zakodowane czarne listy
Logika zamrażania wpisana bezpośrednio w kod źródłowy blockchaina. Konkretne adresy mogą być blokowane na poziomie protokołu poprzez aktualizacje kodu. Ta metoda – używana m.in. przez BNB Chain, VeChain i inne – wymaga wydania nowego oprogramowania (lub hard forka), aby dodać lub usunąć zbanowane adresy. Czarna lista jest publicznie widoczna w kodzie, ale zmieniać ją mogą tylko deweloperzy protokołu lub upoważnione podmioty poprzez aktualizację.
Zamrażanie przez pliki konfiguracyjne
Bardziej zakulisowe podejście, w którym walidatorzy lub operatorzy węzłów ładują prywatną czarną listę przez pliki konfiguracyjne (np. YAML, TOML), które oprogramowanie sprawdza podczas produkcji bloków.
Takie „zamrażanie konfiguracyjne” nie wymaga zmiany publicznego kodu; zamiast tego operatorzy sieci po cichu uzgadniają aktualizację pliku ustawień o adresy do zablokowania, a następnie restartują węzły. Aptos, Sui i Linea to przykłady łańcuchów warstwy 1 z tą funkcją, zarządzaną zasadniczo przez konsensus walidatorów off-chain. Ponieważ te czarne listy znajdują się w konfiguracjach węzłów, zazwyczaj nie są widoczne publicznie, co dodatkowo pogłębia problemy z przejrzystością.
Zamrażanie przez kontrakty on-chain
Systemowy smart kontrakt, który może natychmiast umieścić konta na czarnej liście lub je „odmrozić” poprzez komendy on-chain. Działa jak kontrakt administracyjny z uprawnieniem do wpływania na przetwarzanie transakcji.
Heco (Huobi Eco) Chain to jeden z wyraźnych przykładów – implementuje kontrakt, do którego odwołują się walidatorzy, by sprawdzić, czy dany adres ma zakaz transakcji. Ten model może być bardziej dynamiczny (lista nie wymaga restartu węzłów przy aktualizacji), ale ostatecznie nad wpisami w kontrakcie czuwa klucz admina lub uprzywilejowane governance.
Praktyczne wdrożenia
Każde z tych podejść w efekcie przyznaje małej grupie prawo do zatrzymywania transakcji w sieci – rolę tradycyjnie zastrzeżoną dla banków lub regulatorów w starym systemie finansowym.
Co uderzające, te kontrolne mechanizmy zostały wplecione w architektury różnych blockchainów po cichu. W wielu projektach brakowało wyraźnej komunikacji czy dokumentacji, by poinformować użytkowników, że taki „przycisk pauzy” istnieje.
Często funkcjonalność ta jest zakopana w repozytoriach kodu lub instrukcjach konfiguracyjnych, a nie eksponowana w whitepaperach czy materiałach onboardingowych.
Oznacza to, że użytkownicy, a nawet wielu deweloperów, może nie wiedzieć o mechanizmie zamrażania w danym łańcuchu, dopóki nie zostanie on uruchomiony w kryzysie.
Według raportu 10 z 16 blockchainów z funkcją zamrażania korzysta z metody plików konfiguracyjnych, dając walidatorom możliwość nakładania prywatnych czarnych list poprzez zmianę ustawień węzła. Do tej kategorii należą m.in. Aptos, Sui, EOS i kilka innych.
Ponieważ wpisy czarnej listy znajdują się lokalnie w konfiguracji, sieć z zewnątrz wygląda normalnie – nic w publicznej księdze wprost nie oznacza zamrożonych adresów. Tylko insiderzy koordynujący zamrożenie (oraz ewentualnie eksploratory bloków, które później odnotują brak transakcji z tych adresów) ujawniają, że interwencja miała miejsce.
Kolejnych pięć z 16 łańcuchów ma funkcje zamrażania twardo zaszyte w kodzie źródłowym.
Analitycy Bybit wskazali jako przykłady Binance BNB Chain, VeChain, Chiliz, „VIC” (mniejszą sieć zidentyfikowaną w raporcie) oraz XDC Network XinFin. W tych systemach deweloperzy wbudowali logikę czarnej listy bezpośrednio w zasady konsensusu – to zdecydowanie scentralizowany bezpiecznik. Na przykład w kodzie BNB Chain znajduje się jawna lista zablokowanych adresów, których walidatorzy nie uwzględniają w blokach. Zmiana tej listy wymaga aktualizacji kodu (zwykle koordynowanej przez zespół core Binance). VeChain podobnie dodał twardo zakodowany „moduł blacklist” po hacku z 2019 r., choć projekt utrzymuje, że został on aktywowany decyzją społeczności, a nie jako stałe tylne wejście (więcej na ten temat później).
Ostatni z 16 (Heco) korzysta wyłącznie z podejścia opartego na smart kontrakcie on-chain.
Co istotne, Tron – który był również oznaczony w raporcie – ma wbudowany moduł uprawnionej czarnej listy, który działa w pewnym sensie jak wywołanie kontraktu zainicjowane przez Tron Foundation w celu zamrożenia kont (mechanizm Trona nie został opisany w podsumowaniu Bybit, ale z wcześniejszych przypadków wiadomo, że węzły Trona mogą otrzymać instrukcję odrzucania transakcji z określonych adresów).
We wszystkich przypadkach, niezależnie od tego, czy zamrożenie jest oparte na kodzie, konfiguracji, czy kontrakcie, efekt końcowy jest ten sam: określone adresy mogą zostać pozbawione możliwości dokonywania transakcji, według uznania podmiotów kontrolujących tę funkcję.
Po cichu rozprzestrzenił się swoisty szablon kontroli zamrożeń w różnych ekosystemach blockchain.
Przeczesując repozytoria GitHuba, zespół Bybit znalazł powtarzające się wzorce – hooki w kodzie przetwarzania transakcji, odwołania do zmiennych typu „blacklist” lub sprawdzanie określonych list kont. Występowały one w różnych projektach i językach (na przykład w łańcuchach opartych na EVM, takich jak BNB i Chiliz, w porównaniu z łańcuchami w Rust, jak Sui i Aptos), co sugeruje, że deweloperzy niezależnie doszli do wniosku, że blockchain powinien mieć awaryjny hamulec. To, co zaczęło się jako doraźne reakcje na kryzysy, zdaje się stawać standardowym założeniem projektowym. I co ważne, te mechanizmy często koncentrują władzę w rękach tych, którzy utrzymują kod lub prowadzą główne węzły walidujące. Jak sucho zauważa raport, decentralizacja „często kończy się tam, gdzie zaczyna się dostęp walidatorów”.
16 głównych blockchainów z funkcją zamrażania
Badanie Bybit wskazało szesnaście publicznych blockchainów, które obecnie mają natywną funkcjonalność zamrażania kont lub transakcji. Poniżej znajduje się lista tych sieci oraz znanego mechanizmu, za pomocą którego mogą one blokować środki:
- Ethereum (ETH) – Może wprowadzić awaryjne wstrzymanie poprzez interwencję governance (np. poprzez aktualizację sieci lub hooki EIP podobne do proponowanego EIP-3074). Chociaż Ethereum nie ma prostego „blacklist” wbudowanego w protokół, deweloperzy mogliby wypchnąć specjalny fork lub użyć logiki kontraktu, by osiągnąć zamrożenie w wyjątkowych sytuacjach, jak pokazano przy cofnięciu DAO w 2016 roku.
- BNB Chain (BNB) – Wykorzystuje konsensus walidatorów oparty na czarnej liście. Łańcuch wspierany przez giełdę Binance ma zakodowane na sztywno funkcje zamrażania; jego walidatorzy, koordynowani przez główny zespół Binance, mogą odmówić przetwarzania transakcji z adresów znajdujących się na wewnętrznej czarnej liście.
- Polygon (POL) – Zastosowano dynamiczne filtrowanie adresów w pulach transakcji. Węzły Polygon mogą być skonfigurowane (poprzez forki lub aktualizacje) do odfiltrowywania transakcji obejmujących określone adresy, co w praktyce uniemożliwia uwzględnianie zablokowanych kont w nowych blokach.
- Solana (SOL) – Obsługuje aktualizacje konfiguracji wykonania pod kątem czarnej listy. Konstrukcja Solana pozwala zespołowi głównemu lub podmiotowi zarządzającemu szybko wprowadzać sieciowe zmiany konfiguracji. Teoretycznie może to zostać wykorzystane do wdrożenia czarnej listy na poziomie oprogramowania walidatorów lub zablokowania określonych kont.
- Avalanche (AVAX) – Zawiera zatrzymanie transakcji wywoływane przez governance. Avalanche może wykorzystać swoje on-chain governance (głosowanie walidatorów), aby wdrażać awaryjne zatrzymania lub ograniczenia adresowe w swojej C-Chain i subnetach, jeśli superwiększość walidatorów się zgodzi.
- Tron (TRX) – Wbudowany moduł czarnej listy w protokole. Sieć Tron, nadzorowana przez Tron Foundation, ma funkcjonalność umożliwiającą władzom zamrażanie kont (np. w celu spełnienia żądań organów ścigania lub ochrony przed włamaniami, jak miało to miejsce w przeszłości w odniesieniu do aktywów opartych na TRON).
- Cosmos (ekosystem ATOM) – Pauza modułu IBC i zakazy adresów. Cosmos i jego blockchainy oparte na SDK nie korzystały jeszcze z globalnych zamrożeń, ale system komunikacji międzyłańcuchowej (IBC) oraz konta modułów mogłyby zostać wykorzystane do wstrzymywania transferów lub umieszczania adresów na czarnej liście w wielu strefach poprzez skoordynowaną aktualizację.
- Polkadot (DOT) – Zamrożenia specyficzne dla parachainów poprzez Relay Chain. Governance Polkadot może wdrażać aktualizacje środowiska wykonawczego na parachainach. W sytuacji awaryjnej relay chain mógłby narzucić zamrożenie lub revert dla problematycznego parachainu lub adresu, pod warunkiem zatwierdzenia w głosowaniu on-chain.
- Cardano (ADA) – Hard forki z wyłączeniami adresów. Cardano nie posiada prostego opcodu zamrażającego, lecz poprzez aktualizacje za pomocą hard fork combinator społeczność mogłaby wprowadzić zasady wykluczania określonych UTXO lub adresów (na przykład poprzez nieuwzględnianie wyjść kontrolowanych przez klucz z czarnej listy w nowej epoce).
- Tezos (XTZ) – Głosowania governance umożliwiające zamrożenia. Samomodyfikujący się rejestr Tezos może wprowadzić mechanizm zamrażania poprzez poprawkę protokołu. Jeśli posiadacze zagłosowaliby za włączeniem w aktualizację funkcji czarnej listy lub pauzy (do użycia w sytuacjach awaryjnych), stałaby się ona częścią protokołu Tezos.
- Near Protocol (NEAR) – Filtrowanie transakcji na poziomie shardów. Sfragmentowana architektura NEAR może pozwalać węzłom koordynującym na filtrowanie lub odmawianie przetwarzania transakcji, które kierowane są do określonych adresów w danym shardzie – możliwość tę można wdrożyć poprzez governance protokołu w sytuacjach skrajnych.
- Algorand (ALGO) – Transfery atomowe z kluczami odwołania. Standardowy framework aktywów (ASA) Algorand zawiera funkcję opt-in dla emitenta, umożliwiającą zamrażanie aktywów oraz clawback. Samo ALGO nie może zostać zamrożone, lecz wiele tokenów Algorand ma kontrolę zamrażania. Algorand obsługuje także wymuszone transfery (jeśli autoryzowane), które naśladują zamrożenie poprzez przeniesienie środków z adresu na czarnej liście.
- Hedera Hashgraph (HBAR) – Administracyjne funkcje zamrażania tokenów. Hedera, zarządzana przez korporacyjną radę, oferuje wbudowane funkcje administracyjne dla tokenów. Uprawnieni administratorzy mogą zamrażać transfery tokenów, a nawet wyzerować salda. Model sieci z uprawnieniami oznacza, że rada mogłaby prawdopodobnie również zablokować konta na poziomie rejestru, jeśli zaszłaby taka potrzeba.
- Stellar (XLM) – Klauzule clawback i zamrożenia przy emisji aktywów. Stellar pozwala emitentom aktywów (tokenów) na włączenie funkcji „clawback”, która umożliwia im zamrażanie lub odzyskiwanie tokenów z portfeli użytkowników w określonych warunkach. Funkcja ta była używana przez regulowanych emitentów stablecoinów w sieci Stellar i stanowi częściowy mechanizm zamrażania w ekosystemie.
- Ripple XRP Ledger (XRP) – Funkcjonalność escrow i zamrażania linii kredytowych. Rejestr XRP nie pozwala na zamrożenie natywnej waluty XRP, ale umożliwia emitentom tokenów IOU (jak stablecoiny czy papiery wartościowe na rejestrze) globalne zamrażanie aktywów lub określonych linii zaufania. Sieć Ripple obsługuje także blokowanie XRP w kontraktach escrow (blokady czasowe), co jest powiązane z ograniczaniem przepływu środków.
- VeChain (VET) – Kontrola transakcji oparta na autorytecie. System masternodów autorytarnych VeChain umożliwił w 2019 roku zastosowanie czarnej listy po ataku hakerskim. Fundacja, za aprobatą społeczności, aktywowała reguły konsensusu nakazujące walidatorom odrzucanie wszelkich transakcji z adresów hakera – co w praktyce zamroziło te środki.
Ważne jest, że nie wszystkie projekty zgadzają się z tym, jak opisano ich możliwości zamrażania.
Na przykład po publikacji raportu Bybit, zespół VeChain publicznie zakwestionował stwierdzenie, jakoby jego protokół miał stałe, na sztywno zakodowane zamrożenie.
Fundacja VeChain wyjaśniła, że w incydencie z 2019 roku społeczność zagłosowała za jednorazową poprawką – zmianą zasad konsensusu – która zablokowała adresy hakera na poziomie walidatorów.
„Oprogramowanie VeChainThor zawiera sprawdzanie na poziomie konsensusu, które po włączeniu poprzez governance społeczności uczyniło te aktywa niemożliwymi do ruszenia” – napisał zespół, podkreślając, że środek ten był zatwierdzony w głosowaniu i nie jest funkcją stale aktywną. Innymi słowy, VeChain argumentuje, że w normalnych warunkach nie ma tajnego kill-switcha; po prostu zmieniono kod zgodnie z procedurą, aby zamrozić skradzione środki. Taka odpowiedź uwidacznia wrażliwość tematu – żaden blockchain nie chce być postrzegany jako centralnie kontrolowany, nawet jeśli w sytuacjach awaryjnych działa właśnie w ten sposób.
Następne w kolejce: 19 sieci o krok od uzyskania mocy zamrażania
Być może jeszcze bardziej uderzające niż 16 blockchainów z funkcją zamrażania jest ostrzeżenie raportu, że 19 innych sieci mogłoby przyjąć podobne mechanizmy przy minimalnym wysiłku. W wielu przypadkach struktura kodu pod czarne listy lub pauzowanie transakcji już istnieje albo jest łatwa do dodania. Czasem wystarczyłoby zmienić kilka linijek kodu lub przełączyć flagę konfiguracyjną, aby włączyć tę funkcję.
Jak powszechne może się to stać? Potencjalnie bardzo – jeśli deweloperzy uznają, że kompromis jest tego wart.
Zespół Bybit wskazał kilka konkretnych projektów w tej kategorii „można łatwo zamrozić”.
Zauważyli, że popularne łańcuchy, takie jak Arbitrum, Cosmos, Axelar, Babylon, Celestia i Kava, należą do tych, które mogłyby wprowadzić zamrażanie środków przy stosunkowo niewielkich zmianach protokołu. Sieci te obecnie nie reklamują żadnych funkcji zamrażania, jednak ich architektury są takie, że wprowadzenie takiej możliwości nie byłoby trudne.
Na przykład wiele łańcuchów opartych na Cosmos używa systemu kont modułów (do obsługi takich rzeczy jak governance czy konta opłat).
Jak zaobserwowali badacze, te konta modułów można by zmodyfikować tak, aby odmawiały wychodzących transakcji z określonych adresów. Do tej pory żaden blockchain z ekosystemu Cosmos nie wykorzystał tego do umieszczania użytkownika na czarnej liście – wymagałoby to zatwierdzonego przez governance hard forka z drobną zmianą kodu w logice obsługi transakcji. Ale fakt, że jest to możliwe dzięki prostemu uaktualnieniu, oznacza, że szablon już istnieje i czeka na decyzję.
W praktyce wprowadzenie funkcji zamrażania na tych dodatkowych łańcuchach prawdopodobnie przebiegałoby według znajomego wzorca: poważny hack lubPresja regulacyjna może skłonić deweloperów do stwierdzenia: „Potrzebujemy tego narzędzia”. Rzeczywiście, po włamaniu na Sui na kwotę 162 mln dolarów i zamrożeniu środków, sieć Aptos (również łańcuch używający języka Move) po cichu dodała możliwość umieszczania adresów na czarnej liście w swoim kodzie w ciągu następnych tygodni. Zrozumieli, co nadchodzi: bez mechanizmu zamrażania mieliby niewielkie pole manewru, gdyby podobny exploit uderzył w ich ekosystem.
To pokazuje, jak precedens jednego projektu może wpływać na inne. Jeśli dojdzie choćby do kilku kolejnych głośnych incydentów, łatwo wyobrazić sobie kaskadę łańcuchów, które szybko wdrażają ukryte przełączniki zamrażania „na wszelki wypadek”.
Powszechność podobnych wzorców kodu sugeruje pewien stopień konwergencji branżowej w tej kwestii. „To nie jest anomalia – to staje się szablonem branżowym” – stwierdza raport na temat logiki on-chainowego zamrażania. Wiele nowszych blockchainów najwyraźniej wyciągnęło wnioski (lepsze lub gorsze) z wcześniejszych hacków na starszych sieciach.
W niektórych przypadkach uwzględniają w projekcie haki pozwalające na opcjonalne scentralizowane działania, nawet jeśli się nimi nie chwalą.
W części przypadków te haki zostały wykryte przez narzędzie skanujące Bybit oparte na AI: zespół wykorzystał model AI (Claude 4.1 firmy Anthropic), aby przeskanować setki repozytoriów pod kątem słów kluczowych i struktur kodu związanych z umieszczaniem na czarnej liście oraz filtrowaniem transakcji.
Ten pomocnik AI oznaczył dziesiątki potencjalnych przypadków w różnych projektach.
Nie wszystkie były prawdziwymi funkcjami zamrażania – niektóre fałszywe trafienia dotyczyły funkcji na poziomie użytkownika, które w rzeczywistości nie były kontrolami na poziomie protokołu. Sam fakt, że do odsiania, jak powszechne może to być zjawisko, potrzebna była automatyzacja, podkreśla, jak bardzo zamazały się granice „zdecentralizowanej kontroli”.
Badacze musieli ostatecznie ręcznie zweryfikować każdy przypadek, co pokazuje, że nawet eksperci mogą mieć problem z ustaleniem, gdzie blockchain ukrył dźwignie kontroli.
Raport Bybit podkreśla, że istnienie możliwości zamrażania w coraz większej liczbie sieci nie jest czymś hipotetycznym. Już teraz jest to norma w duchu, jeśli nie w literze. Różnica polega jedynie na tym, czy dany projekt przełączył już ten wyłącznik. Wiele z nich mogłoby to zrobić poprzez hard fork lub nawet zmianę konfiguracji w czasie wykonywania, co oznacza, że etos absolutnej niezmienności jest w praktyce naruszony. Zbliżamy się do krajobrazu, w którym większość łańcuchów ma jakiś stopień „przycisku stop” – albo aktywny, albo czekający w gotowości. To podnosi stawkę, jeśli chodzi o przejrzystość: jeśli te przełączniki są powszechne, użytkownicy i inwestorzy będą chcieli dokładnie wiedzieć, kto może je uruchomić i w jaki sposób.
Pragmatyczne bezpieczeństwo czy ukryta centralizacja?
Debata wokół tych ustaleń w zasadzie sprowadza się do klasycznego dylematu: czy korzyści z interwencji awaryjnej przeważają nad kosztami dla decentralizacji?
Zwolennicy funkcji zamrażania twierdzą, że to pragmatyczny środek bezpieczeństwa – konieczna opcja w świecie, w którym włamania, exploity i kradzieże są powszechne. Raport dokumentuje wręcz, jak zamrożenia uratowały znaczną wartość. Szybka reakcja Sui po włamaniu na Cetus DEX mogła uratować 162 mln dolarów przed bezpowrotnym wyprowadzeniem.
Czarna lista BNB Chain podczas exploitu z 2022 r. pomogła opanować naruszenie na kwotę 570 mln dolarów, zapobiegając dalszej kontaminacji ekosystemu Binance. Zamrożenie przez VeChain w 2019 r. 6,6 mln dolarów skradzionych tokenów ochroniło skarbiec projektu i środki społeczności przed nieodwracalną utratą. Każde z tych zdarzeń mogło być druzgocące; możliwość interwencji sprawiła, że były one bolesne, ale nie śmiertelne.
„Bez nich, hacki takie jak Cetus czy exploit mostu BNB wymazałyby inwestorów” – zauważa raport w obronie tych mechanizmów.
Jednak za każdym razem, gdy blockchain korzysta z takiej formy nadpisania stanu, nadkrusza fundamentalny, pozbawiony zaufania etos technologii blockchain. Odporność na cenzurę – gwarancja, że nikt nie może zablokować ważnych transakcji – jest kluczowym powodem, dla którego ludzie pokładają wiarę w zdecentralizowanych sieciach. Jeśli użytkownicy zaczną czuć, że fundacja lub komitet może wejść i zamrozić środki wedle uznania, psychologiczne (i prawne) różnice w stosunku do tradycyjnych banków zaczną się zacierać. Badacze z Bybit ostrzegają, że nawet dobrze intencjonowane zamrożenia tworzą precedens:
„Gdy łańcuch raz zamrozi środki, trudno sobie wyobrazić, że nie zrobi tego ponownie” – piszą. Obawa polega na tym, że to, co zaczyna się jako środek wyjątkowy, może przekształcić się w rutynowe narzędzie kontroli.
Są przesłanki, że ta granica już się przesuwa.
Według danych z raportu, blisko 70% udokumentowanych przypadków zamrożeń miało miejsce poprzez działania na warstwie konsensusu, podejmowane przez walidatorów lub producentów bloków. To istotne, ponieważ jest to najgłębsza warstwa systemu – oznacza to, że cenzura była wbudowana w sam proces produkcji bloków, a nie tylko w powierzchowną warstwę aplikacji. Przeciętni użytkownicy nawet by nie wiedzieli, że coś się dzieje; łańcuch po prostu przestaje przetwarzać transakcje z określonych adresów, bez wyjaśnień zapisanych on-chain.
W większości przypadków decyzje o zamrożeniu podejmowały małe rady zarządzające, zespoły fundacyjne lub grupy kluczowych deweloperów.
Często są to organy niewybieralne, a jeśli wybieralne (jak niektóre zestawy walidatorów), to zdominowane przez insiderów i bez bezpośredniej odpowiedzialności przed milionami globalnych użytkowników. Takie zamrożenia mogą więc przypominać działania banku centralnego lub dekretu rządowego, realizowane bez rodzaju mechanizmów kontroli i równowagi, które decentralizacja miała zapewnić.
Nieprzejrzystość wokół tych działań awaryjnych stanowi dużą część problemu.
W przypadku Sui koordynacja zamrożenia środków odbyła się poprzez zakulisowe porozumienia między walidatorami, zorganizowane przez Sui Foundation. Nie było żadnej propozycji on-chain ani wcześniejszego głosowania użytkowników; była to pilna reakcja.
Podobnie, nowo dodana funkcja zamrażania w Aptos jest podobno zarządzana za pośrednictwem prywatnych plików konfiguracyjnych walidatorów, a „tylko kilka osób wie”, kto utrzymuje czarną listę i jak podejmowane są te decyzje. Takie dyskretne podejście może być skuteczne w kryzysie, ale spycha społeczność na margines i pozbawione jest przejrzystości.
Nawet w BNB Chain, który stosunkowo otwarcie mówi o swojej zakodowanej na stałe czarnej liście, kontrola „spoczywa mocno w rękach kluczowego zespołu deweloperskiego Binance”, jak zauważa analiza. Oznacza to, że ostateczna decyzja, kto trafi na czarną listę w BNB, należy de facto do kierownictwa Binance – struktury władzy bliższej korporacji niż zdecentralizowanemu projektowi społecznościowemu. W przypadku opartego na kontrakcie mechanizmu zamrażania w Heco klucz administratora w rękach operatorów protokołu może zdecydować, które adresy żyją lub umierają w sieci.
Dla krytyków te fakty potwierdzają od dawna wysuwane podejrzenia, że wiele tak zwanych zdecentralizowanych blockchainów jest zdecentralizowanych tylko z nazwy. „Granice między fundacją, walidatorem a regulatorem szybko się zacierają”, jak zauważył jeden z komentarzy. Gdy dochodzi do przesilenia, większość głównych sieci może działać bardzo podobnie do scentralizowanych pośredników: mogą zamrażać środki, odwracać transakcje czy w inny sposób regulować aktywność użytkowników w sposób, którego ci mogą nawet nie być świadomi.
Społeczność krypto widziała już analogiczne spory przy kwestiach takich jak przestrzeganie sankcji OFAC, kiedy w 2022 r. walidatorzy Ethereum zaczęli cenzurować objęte sankcjami adresy w blokach. To również postrzegano jako równię pochyłą, na której presja zewnętrzna prowadzi do de facto scentralizowanych zachowań w zdecentralizowanym systemie.
Z drugiej strony obrońcy uprawnień awaryjnych twierdzą, że pewna zdolność do interwencji jest po prostu częścią „dojrzewania” krypto. W miarę jak platformy blockchain stają się mainstreamowe i przenoszą miliardy wartości, realiów hacków i przestępczości nie da się ignorować.
Nawet zatwardziali zwolennicy decentralizacji mogliby przyznać, że gdyby skradziono ich własne środki, przywitaliby w porę przeprowadzone zamrożenie, które umożliwiłoby ich odzyskanie. Kluczowe jest być może zapewnienie odpowiedniego zarządzania i przejrzystości wokół tych możliwości.
David Zong, szef bezpieczeństwa Bybit, który prowadził badania, ujął to tak: Blockchain mógł zostać zbudowany na decentralizacji, „jednak nasze badania pokazują, że wiele sieci rozwija pragmatyczne mechanizmy bezpieczeństwa, aby szybko reagować na zagrożenia”.
Najważniejsze jest, jak mówi, że „przejrzystość buduje zaufanie” – jeśli takie mechanizmy istnieją, powinny być jawnie ujawnione i poddane nadzorowi, a nie ukryte w kodzie.
Najgorszym scenariuszem byłyby tajne tylne furtki lub przyciski zamrażania, o których użytkownicy dowiadują się dopiero wtedy, gdy jest już za późno.
Z kolei jeśli projekt otwarcie stwierdza, że zachowuje hamulec awaryjny i przedstawia jasną politykę, jak i kiedy jest on używany (np. tylko przy hackach powyżej X kwoty, wymagając wielopodpisowej autoryzacji itd.), użytkownicy i inwestorzy mogą sami ocenić ten kompromis.
Reakcja VeChain, o której wspomniano wcześniej, jest tu pouczająca. Nie zaprzeczyli zamrożeniu środków – bronili sposobu, w jaki to zrobiono, przedstawiając je jako działanie zarządzane przez społeczność, a nie jednostronną decyzję. Sugeruje to możliwy złoty środek: każde zamrożenie powinno być wprowadzane poprzez jakąś formę zdecentralizowanego procesu decyzyjnego. W przypadku VeChain twierdzą, że posiadacze tokenów zatwierdzili czarną listę. W przypadku Sui społeczność po fakcie zatwierdziła plan odzyskania środków w głosowaniu. Choć te kroki w zakresie governance mogą być niedoskonałe (krytycy zauważą, że wpływ fundacji często może przechylać wynik głosowań albo że pilny charakter sytuacji uniemożliwia długie debaty), to przynajmniej stanowią próbę pogodzenia się z zasadami decentralizacji. Alternatywa – garstka kluczowych deweloperów podejmująca decyzje – zbliża się niepokojąco do scentralizowanych systemów, przed którymi krypto miało uciec.
Prawie rok po historycznym „forku DAO” Ethereum z 2016 r. – prawdopodobnie pierwszej interwencji w fundusze on-chain – branża wciąż mierzy się z tym samym zasadniczym pytaniem: czy blockchainy powinny kiedykolwiek ingerować w aktywność on-chain, nawet po to, by naprawić wyrządzone zło?
Być może nigdy nie będzie jednej uniwersalnej odpowiedzi. Różne sieci przyjmują różne stanowiska – od absolutystycznej niezmienności Bitcoina (nawet kradzieży z ery Satoshiego nie da się cofnąć) po bardziej elastyczne, silnie oparte na governance łańcuchy, takie jak Tezos czy Polkadot, które wyraźnie dopuszczają zmiany prowadzone przez społeczność. Jasne jest natomiast, że obecność te mechanizmy zamrażania zacierają dychotomię scentralizowane vs zdecentralizowane.
Wiele sieci zajmuje szarą strefę pomiędzy – są zdecentralizowane w codziennym działaniu, ale mają scentralizowane możliwości nadpisania w skrajnych scenariuszach. To, czy ktoś uzna to za rozsądne zarządzanie ryzykiem, czy za fatalny kompromis, zależy prawdopodobnie od jego filozofii, a może też od tego, czy kiedykolwiek znalazł się po przegranej stronie włamania.
Końcowe przemyślenia
Raport Bybit odsłonił niewygodną prawdę: możliwość zamrożenia środków jest już elementem krajobrazu blockchain, zwłaszcza wśród czołowych sieci.
Wybór stojący przed branżą nie brzmi już po prostu „centralizacja vs decentralizacja”. Chodzi o uczciwe zarządzanie vs ukrytą kontrolę.
Projekty, które otwarcie przyznają się do swoich uprawnień i poddają je demokratycznym kontrolom, mogą zachować wiarygodność – będą mówiły: jesteśmy w większości zdecentralizowani, z wyjątkiem skrajnych sytuacji awaryjnych, i dokładnie tak to działa.
Natomiast jeśli takie uprawnienia pozostaną nieprzejrzyste i poza kontrolą, to tylko kwestia czasu, aż zasieją nieufność lub zostaną nadużyte. Wraz ze wzrostem presji regulacyjnej niektóre jurysdykcje mogą wręcz wymagać on-chainowych mechanizmów zamrażania (UE i Singapur już przedstawiły pomysły na przepisy dotyczące „hamulca bezpieczeństwa”). Inwestorzy instytucjonalni również mogą preferować sieci, które potrafią kontrolować ryzyko, nawet kosztem częściowej utraty decentralizacji.
Może to doprowadzić do podziału na „zgodne” łańcuchy, które potrafią interweniować, oraz „purystyczne” łańcuchy, które tego odmawiają – co zasadniczo przeobrazi tożsamość ekosystemu krypto.
Ostatecznie decentralizacja w krypto nie umiera – ale dojrzewa i konfrontuje się z twardą rzeczywistością.