Wieczorem 22 września użytkownik wysłał przelew ATOM.
Po upływie nocy transakcja wciąż pozostawała w stanie „oczekiwania na potwierdzenie”.
Klucz prywatny nie został utracony, a portfel nie wykazywał żadnych anomalii związanych z podpisywaniem. Przy ponownej weryfikacji następnego dnia wiele publicznych RPC wskazywało, że Cosmos Hub zatrzymał się na wysokości bloku 33 086 740.
Skoro nie powstawały nowe bloki, naturalnie nie było miejsca, które mogłoby zapakować tę transakcję.
Dopiero około dzień później, po wznowieniu produkcji bloków przez Cosmos Hub, ten przelew ATOM, który przez cały czas pozostawał w stanie oczekiwania, w końcu zakończył się sukcesem.
Dla zwykłych użytkowników może to być najbardziej intuicyjna lekcja zrozumienia konsensusu blockchain.
Jesteśmy przyzwyczajeni do mówienia, że „żadna centralna instytucja nie może zamknąć publicznego łańcucha”, ale rzeczywistość jest wyraźnie znacznie bardziej złożona. Wystarczająco zdecentralizowany blockchain rzeczywiście zwykle nie ma tego „przycisku wyłączania” w serwerowni, ale wciąż może się zatrzymać.
Ta pauza Cosmos Hub przypadkowo w pełni ujawniła ten zestaw mechanizmów, zwykle ukrytych na najniższej warstwie, zwykłym użytkownikom.
1. Dlaczego Cosmos nagle „przestał produkować bloki”?
Najpierw należy wyjaśnić kwestię, którą łatwo pomylić: tym razem bezpośrednio zaatakowany nie został Cosmos Hub.
Incydent miał miejsce najpierw w Neutron.
22 września przegłosowano propozycję zarządzania Neutron o nazwie „AIATO: AI Agent Takeover”. Atakujący wykorzystał lukę w uprawnieniach zarządzania na poziomie łańcucha i użył uprzywilejowanych instrukcji natywnie dostarczanych przez framework wasmd, aby zmienić administratorów kontraktów aplikacji takich jak Astroport i Drop na adresy kontrolowane przez atakującego.
To nie jest to, co zwykle rozumiemy jako „luka w kodzie” czy „błąd protokołu”.
Można to prosto zrozumieć tak: same aplikacje mają własne „zamki w drzwiach”, ale zarządzanie na poziomie łańcucha Neutron również posiada „klucz główny” o wyższych uprawnieniach, a gdy atakujący kontroluje wynik zarządzania, jest to równoznaczne z uzyskaniem tego klucza, co pozwala mu ponownie przypisać administratorów, migrować kontrakty i dalej przenosić znajdujące się w nich aktywa.
To, co naprawdę wciągnęło Cosmos Hub, to następujący po tym transfer środków międzyłańcuchowych.
Analiza po zdarzeniu przygotowana przez Cosmos Labs pokazuje, że zanim Neutron przestał działać, atakujący zdążył przenieść część aktywów do wielu sieci, spośród których około 1,7 miliona ATOM zostało przeniesionych do Cosmos Hub i zaczęło być wymieniane poprzez międzyłańcuchową płynność.
Innymi słowy, sam Cosmos Hub nie został bezpośrednio zaatakowany, a środki zwykłych użytkowników Hub nie zostały bezpośrednio skradzione z powodu luki w Neutron.
Jednak ATOM uzyskane w wyniku ataku już trafiły do Hub, a aby zapobiec dalszemu wypływowi pozostałych ATOM, część walidatorów Cosmos Hub zaczęła przestawać uruchamiać swoje węzły.
Około godziny 19:18 22 września (SGT) walidatorzy, którzy przestali działać, reprezentowali już ponad jedną trzecią całkowitej mocy głosowania, więc Cosmos Hub nie mógł dalej tworzyć nowych bloków i ostatecznie zatrzymał się na 33 086 740.
Ten krok jest bardzo kluczowy.
Oznacza to, że Cosmos Hub nie ma przycisku „Pause”, który jakaś firma mogłaby bezpośrednio kliknąć, ani nie odbyło się to najpierw w drodze głosowania nad zarządzaniem on-chain. Tym, co naprawdę zatrzymało sieć, było to, że wystarczająca liczba walidatorów przestała uczestniczyć w tworzeniu konsensusu.
Ale co jest bardziej godne uwagi, to właściwie proces odzyskiwania po tym zdarzeniu.
Około 4 godziny po zatrzymaniu łańcucha walidatorzy otrzymali kompletny plan odzyskiwania: wykonać jednorazową modyfikację stanu na wysokości zatrzymania łańcucha, przenosząc pozostałe ATOM z adresu atakującego na adres multisig zarządzany wspólnie przez walidatorów społeczności.
Następnie Cosmos Labs przygotowało poprawkę Gaia v28.3.0 na podstawie planu już uzgodnionego przez walidatorów, przetestowało ją i rozesłało walidatorom.
Ta wersja Gaia miała wykonać jednorazową zmianę stanu na określonej wysokości odzyskiwania, przenosząc 1 227 121 ATOM z adresu atakującego na adres multisig 4-z-6 złożony z sześciu stron: Nansen, Keplr, Enigma, Silknodes, Kiln i Polkachu.
Do wczesnych godzin porannych 23 września walidatorzy potwierdzeni jako mający zainstalowaną wersję v28.3.0 przekroczyli już 67% całkowitej mocy głosu, więc o 12:00 UTC tego dnia Cosmos Hub skoordynował restart. Około 6 minut później ta jednorazowa modyfikacja stanu została wykonana na wysokości bloku 33 086 741, a sieć wznowiła normalną produkcję bloków.
W ostatecznej analizie, przez cały proces od zatrzymania produkcji bloków przez Cosmos do wznowienia działania, walidatorzy najpierw spowodowali utratę Liveness przez sieć, a następnie ponad dwie trzecie mocy głosu zaakceptowało nowy zestaw reguł przejścia stanu, ostatecznie czyniąc ten zestaw reguł kanonicznym stanem po odzyskaniu.
W tym momencie pojawia się pozornie proste pytanie: skoro jest to zdecentralizowany publiczny łańcuch, dlaczego więcej niż jedna trzecia mocy walidacyjnej może go zatrzymać, podczas gdy przywrócenie sieci wymaga, aby wystarczająca liczba walidatorów wspólnie zaakceptowała i uruchomiła to samo oprogramowanie?
Odpowiedź jest właściwie ukryta w słowie „konsensus”.
2. Tak zwany konsensus nigdy nie oznaczał „nigdy się nie zatrzymuje”
Jedną z rzeczy najczęściej błędnie rozumianych w odniesieniu do blockchaina jest utożsamianie „decentralizacji” z „nigdy nie pada”.
W rzeczywistości mechanizm konsensusu naprawdę rozwiązuje problem jak, bez centralnego księgowego, wiele węzłów może osiągnąć porozumienie co do kolejności transakcji i stanu księgi.
Jednak różne publiczne łańcuchy nie implementują tego w ten sam sposób.
Na przykład najbardziej klasycznym mechanizmem Bitcoina jest PoW, proof of work — górnicy konkurują o produkcję bloków za pomocą mocy obliczeniowej. Gdy w sieci na krótko pojawią się dwie ważne gałęzie, węzły wybierają jedną z nich, aby kontynuować budowanie na niej zgodnie z skumulowaną pracą.
Tak więc Bitcoin nie ma wyraźnego momentu, w którym „po głosowaniu 67% ten blok jest na zawsze sfinalizowany”. Jest to bliższe pewnego rodzaju probabilistycznej finalności: im więcej jest kolejnych bloków, tym więcej kosztu mocy obliczeniowej potrzeba, aby zreorganizować i usunąć wcześniejsze transakcje.
To także dlatego kiedyś mówiono, że na transakcję Bitcoina najlepiej poczekać 6 potwierdzeń bloków. W końcu nawet przy większej mocy obliczeniowej nie można po prostu ominąć reguł konsensusu, które wykonują węzły.
Oczywiście nie oznacza to, że stan Bitcoina jest „absolutnie niemożliwy do zmodyfikowania” w jakichkolwiek okolicznościach. Teoretycznie, jeśli cały ekosystem zaakceptuje nowego klienta i nowe reguły konsensusu, poprzez Hard Fork, równie możliwe jest sprawienie, by zmiany stanu, które były nieważne według starych reguł, stały się ważne.
Ale tu pojawia się problem: kto ma zdolność sprawienia, by wystarczająca liczba górników, Full Nodes, platform handlowych, portfeli i użytkowników wspólnie zaakceptowała taki nowy zestaw reguł?
Prawie nikt.
Zespół deweloperski nie może samodzielnie decydować o regułach konsensusu dla całej sieci Bitcoin, a górnicy i platformy handlowe również mają z tym trudność, ponieważ próg konsensusu, który trzeba przekroczyć, jest bardzo wysoki. Kiedy Binance zostało zhakowane na 7 000 BTC, niektórzy sugerowali, aby CZ skontaktował się z dużymi górnikami w celu przeprowadzenia operacji, ale ostatecznie nic z tego nie wyszło.
Ethereum dostarcza innego bardzo klasycznego przykładu.
Po przejściu na PoS Ethereum używa teraz konsensusu Gasper złożonego wspólnie z Casper FFG i LMD-GHOST. Mówiąc prościej, jedna część mechanizmu odpowiada za ustalenie „którego łańcucha należy obecnie przestrzegać”, podczas gdy druga część odpowiada za nadanie blokom prawdziwej Finalności.
Tylko gdy walidatorzy reprezentujący co najmniej dwie trzecie stakowanego ETH zgodzą się co do odpowiedniego checkpointu, blok może posunąć się dalej w kierunku finalizacji; odwrotnie, jeśli więcej niż jedna trzecia stawki przez długi czas nie uczestniczy w prawidłowym głosowaniu, sieć może tymczasowo nie być w stanie utworzyć Finalności. Jednak Ethereum zaprojektowało również inactivity leak, który stopniowo zmniejsza efektywną wagę walidatorów będących offline, gdy finalizacja nie może zostać osiągnięta przez długi czas, dając sieci szansę na ostateczne przywrócenie Finalności.
Aby naprawdę zmienić ten wynik, konieczna jest również zmiana reguł protokołu i klientów.
Podobnie jak w incydencie The DAO z 2016 roku, społeczność Ethereum ostatecznie przeprowadziła Hard Fork, wykonując na bloku 1 920 000 specjalną modyfikację stanu, którą ówczesna Fundacja Ethereum nazwała bezpośrednio nieregularną zmianą stanu, przenosząc odpowiednie ETH do kontraktu odzyskiwania.
Jednak niektórzy górnicy i członkowie społeczności, którzy odmówili aktualizacji i kontynuowali utrzymywanie oryginalnego stanu, ostatecznie utworzyli Ethereum Classic (ETC), co doprowadziło do dobrze znanego rozgałęzienia ETH i ETC, pokazując, że nie wszyscy zaakceptowali ten zestaw reguł.
Cosmos Hub jest znowu inny. Używa CometBFT, który jest bliższy typowemu konsensusowi BFT.
Można to rozumieć jako bardziej typowy konsensus BFT, co oznacza, że aby blok został naprawdę zatwierdzony, musi uzyskać Commit od więcej niż dwóch trzecich mocy głosowania.
Jego zaletą jest to, że Finalność jest bardzo jasna. Gdy blok zostanie zatwierdzony po głosowaniu przez wystarczającą moc weryfikacyjną, nie ma potrzeby dalszego czekania na coraz więcej bloków jak w PoW, wymieniając prawdopodobieństwo na poczucie bezpieczeństwa.
Ale jego druga strona jest również bardzo bezpośrednia: jeśli jedna trzecia lub więcej mocy głosowania nie dostarczy już głosów potrzebnych do utworzenia Commitu, to niezależnie od tego, jak bardzo pozostali walidatorzy się starają, nie mogą zebrać więcej niż dwóch trzecich.
W tym momencie najbezpieczniejszym wyborem dla sieci jest dokładnie „pauza w produkcji bloków” widziana tym razem, więc z perspektywy systemów rozproszonych to krótkie zatrzymanie Cosmos Hub w rzeczywistości nie jest tajemnicze.
Jednym słowem, po tym, jak grupa walidatorów posiadających wystarczającą moc głosowania przestaje uczestniczyć, protokół konsensusu, zgodnie z własnymi regułami, woli utracić dostępność niż kontynuować potwierdzanie nowych bloków bez wystarczającego konsensusu.
Za tym w rzeczywistości odpowiadają dwa pojęcia w systemach rozproszonych, które są często mylone przez zwykłych użytkowników:
- Bezpieczeństwo: różne węzły nie mogą jednocześnie potwierdzić dwóch sprzecznych stanów końcowych;
- Żywotność: czy sieć może nadal działać do przodu i przetwarzać nowe transakcje;
Dla systemów BFT, gdy jest niewystarczająca liczba węzłów uczestniczących w konsensusie, pauza jest czasami dokładnie ceną zapłaconą za utrzymanie Bezpieczeństwa. Mówiąc wprost, ten zdecentralizowany rejestr wolałby najpierw się zatrzymać, niż pozwolić pozostałym prowadzić własne zapisy.
Patrząc z tego kąta, można zauważyć, że wiele pozornie zupełnie różnych incydentów w historii publicznych blockchainów w rzeczywistości obraca się wokół tej samej rzeczy:
Kiedy rozproszone węzły nie mogą już osiągnąć konsensusu co do „właściwego stanu”, co powinna zrobić sieć?
III. Od Bitcoina do Solany, gdzie jest prawdziwa granica ryzyka publicznych blockchainów?
To nie pierwszy raz, gdy Cosmos stawia to pytanie na stole.
Już w 2013 roku Bitcoin doświadczył bardzo klasycznego incydentu rozgałęzienia łańcucha.
W tym czasie Bitcoin 0.8 zmienił swoją bazę danych z Berkeley DB na LevelDB. Następnie pojawił się blok zawierający dużą liczbę wejść transakcji. Węzły nowej wersji mogły go przetworzyć normalnie, ale niektóre węzły starej wersji, z powodu limitu liczby blokad Berkeley DB, uznały ten blok za nieprawidłowy.
Tak więc pojawiła się bardzo niezręczna scena: wszyscy uruchamiali Bitcoina, ale stare i nowe klienty zaczęły dawać różne odpowiedzi na pytanie „czy ten blok jest legalny, czy nie”.
Sieć podzieliła się więc na dwa łańcuchy, a strona nowej wersji 0.8 miała kiedyś około 60% mocy haszowania i nie mogła polegać na normalnej konkurencji mocy haszowania, aby szybko się zbiec.
Ostatecznie duże pule wydobywcze skoordynowały się, aby przełączyć się z powrotem na starą wersję, odzyskały więcej mocy haszowania po stronie starych reguł i dopiero wtedy sieć ponownie się zbiegła. Bitcoin później specjalnie przeanalizował ten incydent w BIP 50.
Do 2016 roku incydent The DAO w Ethereum popchnął problem o krok dalej.
Jak wspomniano powyżej w odniesieniu do incydentu The DAO, społeczność Ethereum ostatecznie przeprowadziła Hard Fork, wykonując na bloku 1 920 000 specjalną modyfikację stanu, którą Fundacja Ethereum nazwała wprost nieregularną zmianą stanu, przenosząc odpowiednie ETH do kontraktu odzyskiwania.
Ale nie wszyscy zgodzili się z tym rozwiązaniem. Niektórzy górnicy i członkowie społeczności, którzy odmówili zaakceptowania modyfikacji stanu, kontynuowali utrzymywanie pierwotnych zasad, co doprowadziło do powstania od dawna istniejącego Ethereum Classic (ETC).
Ten DAO Fork był również klasycznym wydarzeniem, równoważnym powiedzeniu wszystkim, że gdy wystąpią ekstremalne zdarzenia, oprócz konsensusu kodu istnieje również konsensus społeczny. Jeśli nie można wypracować wystarczająco spójnych opinii, łańcuch naprawdę może się rozdzielić na dwa.
Solana w 2021 roku pokazała inną, całkowicie odmienną ścieżkę awarii.
We wrześniu tego roku duża liczba transakcji botów zalała sieć, powodując wyczerpanie pamięci węzłów walidatorów i awarię wielu węzłów. Ostatecznie cała sieć nie mogła osiągnąć konsensusu co do bieżącego stanu i przez około 17 godzin przestała potwierdzać nowe bloki, po czym walidatorzy wspólnie skoordynowali działania, aby przywrócić sieć.
Zestawiając te incydenty razem, można zauważyć, że nie są to te same rzeczy:
- Problem Bitcoina w 2013 roku polegał na tym, że różne klienty zaczęły egzekwować różne zasady ważności;
- Problem Solany w 2021 roku polegał na tym, że duża liczba węzłów walidatorów nie mogła już dalej normalnie uczestniczyć w konsensusie, a sieć utraciła Liveness;
- To, z czym zmierzyło się Ethereum DAO, było bliższe pytaniu, czy społeczność powinna aktywnie modyfikować stan poprzez nowe zasady protokołu;
- A tym razem Cosmos Hub ma jeszcze jedną warstwę szczególności: sieć najpierw aktywnie utraciła Liveness poprzez koordynację walidatorów, aby zapobiec dalszemu przemieszczaniu się zaatakowanych aktywów; następnie wystarczająco wysoka proporcja mocy głosowania wspólnie zaakceptowała nowe oprogramowanie i stan odzyskiwania, pozwalając sieci ponownie osiągnąć konsensus;
Zatem zamiast po prostu sprowadzać te zdarzenia do „więc blockchainy faktycznie mogą się zatrzymać” lub „decentralizacja jest w całości fałszywa”, lepiej przyznać bardziej realny fakt:
Mechanizm konsensusu nigdy nie był maszyną, która nie może się zepsuć. To, co naprawdę zapewnia, to w rzeczywistości zestaw zdecentralizowanych zasad, takich jak to, kto decyduje o właściwym łańcuchu, gdy pojawiają się nieporozumienia; ilu uczestników potrzeba, aby stan uzyskał finalność; czy sieć decyduje się kontynuować działanie, czy zatrzymać się, gdy wystąpią awarie; oraz w ekstremalnych okolicznościach, jaki rodzaj zbiorowego działania może zmienić zasady działania na przyszłość.
To pozostawia również ten incydent z Cosmos z pytaniem, które dla zwykłych użytkowników jest bardziej warte rozważenia niż „czy łańcuch powinien zostać zatrzymany”.
Końcowe przemyślenia
Często mówimy: not your keys, not your coins.
To stwierdzenie oczywiście nadal jest prawdziwe, tyle że podkreśla kontrolę nad aktywami—dopóki klucz prywatny jest w twoich rękach, portfele, platformy handlowe lub inne strony trzecie nie mogą podpisać transferu w twoim imieniu.
Warunkiem jest to, że blockchain, na którym się znajdujesz, musi być w stanie przetworzyć ten podpis w dowolnym momencie.
W dniu, w którym Cosmos Hub przestał produkować bloki, użytkownicy nadal posiadali własne klucze prywatne, a aktywa nie zniknęły w powietrzu z tego powodu, tyle że nawet jeśli poprawnie podpisałeś transakcję, nie było nowego bloku, który by ją przyjął.
Proces odzyskiwania dodatkowo ilustruje, że jeśli wystarczająca liczba uczestników konsensusu zaakceptuje nowy zestaw zasad stanu, stan on-chain określonych kont może również ulec zmianie bez podpisu klucza prywatnego oryginalnego adresu.
To nie unieważnia „Not your keys, not your coins”, ale przypomina nam, że suwerenność klucza prywatnego i podstawowa moc konsensusu nigdy nie były tym samym.
A w przypadku portfeli jest tak samo.
Portfele mogą zapewnić, że klucze prywatne i prawa do podpisywania znajdują się w rękach użytkowników, mogą jak najszybciej identyfikować anomalie na poziomie łańcucha, dokładnie wyświetlać status transakcji, ustanawiać redundancję RPC i węzłów oraz ponownie potwierdzać ostateczny wynik transakcji po przywróceniu sieci.
Ale portfele nie mogą przywrócić konsensusu dla publicznego łańcucha, ani nie mogą zagwarantować, że podstawowa sieć nigdy nie zostanie przerwana, a tym bardziej nie mogą zagwarantować, że zasady i stan na łańcuchu nigdy nie ulegną zmianom na poziomie konsensusu.
Tak więc to, do czego naprawdę powinien dążyć dojrzały zdecentralizowany system, być może nigdy nie było tym, że „nic nigdy nie może zostać zmienione”; wręcz przeciwnie, powinien on w jak największym stopniu wyjaśnić te niedoskonałe granice: Kto może wstrzymać konsensus? Ile wagi potrzeba? W jakich okolicznościach dozwolona jest interwencja awaryjna?
Ponieważ prawdziwa decentralizacja nie może sprawić, że system nigdy nie napotka wypadków; kluczowe jest to, że nawet jeśli wypadek naprawdę się zdarzy, nadal możemy wiedzieć, kto, na podstawie jakich zasad i z jak dużym konsensusem zdecydował, jak ten rejestr powinien być dalej zapisany.
