MultiversX zawiesił działanie swojego mainnetu po tym, jak atakujący próbował wykorzystać problem atomowości transakcji w warstwie maszyny wirtualnej sieci, pozostawiając nieprawidłowe zmiany zapisane na łańcuchu. Zespół wyłączył produkcję bloków, wprowadził łatkę do testów w środowisku shadow fork i poinformował, że ocenia ukierunkowane odzyskiwanie. Potwierdzona wysokość strat nie została ujawniona.

Co MultiversX potwierdził

• Problem dotyczył atomowości transakcji.
• Nieprawidłowe zmiany zostały zapisane na łańcuchu.
• Działanie mainnetu zostało zawieszone.
• Łatka trafiła do testów w środowisku shadow fork.
• Oceny podlegało ukierunkowane odzyskiwanie.

Co pozostaje nieznane

• Czy użytkownicy trwale utracili środki.
• Które konta lub kontrakty zostały dotknięte.
• Jak atakujący wywołał awarię.
• Która metoda odzyskiwania zostanie przyjęta.
• Kiedy wszystkie usługi zostaną przywrócone.

Zatrzymanie zamroziło problem — nie cofnęło go

W swoim komunikacie o incydencie MultiversX poinformował, że atakujący próbował wykorzystać problem atomowości w warstwie masz wirtualnej mainnetu. Deweloperzy zawiesili działanie sieci, gdy śledzili powstałe zmiany stanu i przygotowywali łatkę. Potwierdzona wysokość strat nie została ujawniona.

Zatrzymanie produkcji bloków zapobiega opieraniu nowych transakcji na rekordach, które mogą być już nieprawidłowe. Blokuje to również kolejną próbę wykorzystania tej samej metody, podczas gdy inżynierowie ustalają, które salda lub wpisy kontraktów zostały dotknięte.

Wstrzymanie nie cofa zmian, które sieć już zaakceptowała. Te rekordy pozostają punktem wyjścia używanym przez portfele, aplikacje i mosty, dopóki MultiversX nie przyjmie planu odzyskiwania.

Sprawdzone 20 września strona statusu MultiversX klasyfikowała system jako częściowo obniżony. Publiczne API, xPortal, Explorer, Wallet, Bridge, xExchange i xLaunchpad wykazywały obniżoną wydajność, natomiast brama i indeks były wskazane jako działające.

Te etykiety opisują poszczególne usługi i nie potwierdzają, że normalne przetwarzanie transakcji zostało wznowione. Przywrócenie interfejsów również nie rozwiąże leżącego u podstaw problemu księgowego. Aby zrozumieć dlaczego, warto zacząć od atomowości transakcji.

Atomowość to blockchainowa wersja zasady „wszystko albo nic”

Transakcja smart kontraktu może zawierać kilka powiązanych operacji. Jedno saldo może zostać pomniejszone, inne powiększone, a pula płynności zaktualizowana. Atomowe wykonanie wymaga, aby cała sekwencja zakończyła się sukcesem, zanim którakolwiek z tych zmian stanie się trwała.

Oczekiwany rezultat: każdy wymagany krok kończy się sukcesem i wszystkie zmiany są zatwierdzane razem. Jeśli którykolwiek krok zawiedzie, żadna ze zmian transakcji nie powinna zostać zatwierdzona.

Awaria atomowości: jedna operacja zawodzi, ale wcześniejsza zmiana stanu pozostaje. Sieć może wtedy zapisać częściowy rezultat, który sam w sobie nie powinien istnieć.

To uproszczony przykład atomowości, a nie rekonstrukcja incydentu MultiversX. Błędna transakcja mogłaby pozostawić saldo konta, podaż tokena lub rekord kontraktu niespójne z zamierzonym rezultatem. MultiversX nie ujawnił, jaki typ danych został zmieniony, więc nie ma wystarczających dowodów, aby stwierdzić, że atakujący utworzył tokeny, opróżnił konkretny kontrakt lub ukradł znaną kwotę.

Finalność dowodzi zgody, a nie wykonania bez błędów

Finalność w blockchainie oznacza, że walidatorzy uzgodnili, który blok i wynikowy stan należą do łańcucha kanonicznego. Nie dowodzi ona, że oprogramowanie użyte do obliczenia tego stanu było wolne od wad.\nWalidatorzy wykonują te same reguły protokołu i porównują swoje wyniki. Jeśli te reguły zawierają tę samą wadę na każdym węźle, walidatorzy mogą konsekwentnie uzgodnić rezultat, którego protokół nigdy nie miał dopuszczać. Konsensus może ustalić, jaki stan sieć zaakceptowała; nie może zagwarantować, że błąd oprogramowania nie przyczynił się do jego powstania.

Zainstalowanie poprawionego oprogramowania uniemożliwia ponowne zadziałanie tej samej ścieżki wykonania, ale nie rozstrzyga, co powinno stać się z już zapisanymi zmianami. MultiversX musi zidentyfikować dotknięte wpisy i dać walidatorom powtarzalny sposób weryfikacji, że niezwiązana aktywność pozostała bez zmian.

Shadow fork zapewnia próbę generalną przed restartem mainnetu

MultiversX przygotował łatkę do testów w środowisku shadow fork. Shadow fork kopiuje odpowiednią historię i stan mainnetu do izolowanego środowiska, co pozwala inżynierom odtworzyć rzeczywiste warunki sieciowe bez eksperymentowania na rzeczywistych saldach.

Zespół może zastosować łatkę, odtworzyć dotkniętą sekwencję i przetestować proponowane odzyskiwanie, zanim walidatorzy zainstalują ją na mainnecie. Ten proces powinien ustalić:

• Czy węzły obliczają ten sam naprawiony stan.
• Czy niedotknięte salda pozostają bez zmian.
• Czy aplikacje poprawnie odczytują skorygowane rekordy.
• Czy mosty i giełdy mogą uzgodnić swoje dane.
• Czy walidatorzy mogą wznowić działanie bez tworzenia konkurencyjnych łańcuchów.

Pomyślne przejście tych testów nie przywróci automatycznie wszystkich usług. Wdrożenie nadal wymaga koordynacji między walidatorami, giełdami, mostami i dostawcami infrastruktury łączącymi użytkowników i aplikacje z MultiversX.

Ukierunkowana naprawa pozwoliłaby uniknąć cofania całego łańcucha

MultiversX poinformował, że ocenia ukierunkowane odzyskiwanie mające na celu zachowanie sfinalizowanej historii transakcji i prawidłowych rekordów użytkowników, przy jednoczesnym adresowaniu wyłącznie zmian związanych z incydentem. Projekt nie wyjaśnił, jak ta korekta zostałaby wdrożona.

Ukierunkowana korekta stanu. Naprawione zostałyby tylko salda, storage kontraktów lub inne rekordy związane z incydentem, a niezwiązane transakcje mogłyby pozostać w sfinalizowanej historii. Główna trudność polega na udowodnieniu, że korekta obejmuje każdą nieprawidłową zmianę — i nic poza tym.

Szerokie cofnięcie łańcucha. Sieć wróciłaby do wcześniejszego bloku i odbudowałaby się od tego punktu. Transakcje zakończone po tym momencie mogłyby zniknąć, nawet jeśli nie miały związku z incydentem. Główna trudność: prawidłowe przelewy i aktywność aplikacji mogą wymagać powtórzenia lub uzgodnienia.

Koszt szerszego cofnięcia był widoczny po wykorzystaniu lukiectonic, gdy walidatorzy Cronos usunęli prawie 11 000 bloków obejmujących niemal dwie godziny. Cofnięcie odwróciło większość związanego z incydentem pożyczania nadal zapisanego na Cronos, ale odwróciło również niezwiązane transakcje zrealizowane w tym okresie. Oba incydenty mają różne przyczyny; przykład Cronos ma tu znaczenie, ponieważ pokazuje uboczny koszt cofania współdzielonego rejestru.

MultiversX twierdzi, że rozważa węższą naprawę, ale jak dotąd nie pokazał, jak dotknięte rekordy zostałyby wyodrębnione. Ukierunkowana naprawa niekoniecznie usunęłaby oryginalne bloki: historia transakcji mogłaby pozostać widoczna, podczas gdy skoordynowana zmiana protokołu ustala stan, który aplikacje i walidatorzy uznają po restarcie. Tej metody nie można właściwie ocenić, dopóki MultiversX nie opublikuje projektu odzyskiwania.

Co użytkownicy MultiversX powinni robić podczas wstrzymania

Dla zwykłych posiadaczy najprostszą instrukcją jest czekanie. MultiversX nie prosił użytkowników o migrację tokenów, łączenie portfeli ze stroną odzyskiwania ani zatwierdzanie transakcji korygującej.

• Nie wysyłaj ani nie ponownie rozgłaszaj transakcji.
• Nie dokonuj wpłat ani wypłat EGLD ani ESDT przez giełdy.
• Unikaj przenoszenia tych aktywów przez mosty międzyłańcuchowe.
• Zachowaj hash transakcji dla wszystkiego wysłanego w pobliżu zatrzymania.
• Ignoruj linki odzyskiwania, migracje i niezamówione wiadomości wsparcia.
• Czekaj, aż zarówno MultiversX, jak i dana platforma potwierdzą wznowienie działania.

Naprawa sieci zostałaby przyjęta przez walidatorów i operatorów infrastruktury. Nie wymagałaby od użytkowników ujawniania fraz seed ani wysyłania aktywów na nowy adres.

Portfele i eksploratory mogą również potrzebować czasu na ponowną synchronizację po wznowieniu produkcji bloków. Nieaktualne saldo lub brakująca ostatnia transakcja w interfejsie nie oznaczają same w sobie, że bazowe aktywa uległy zmianie.

Restart musi być weryfikowalny

Wznowienie produkcji bloków przywróci dostępność, ale samo w sobie nie rozstrzygnie kwestii finalności. MultiversX nadal musi ujawnić, które konta lub kontrakty zostały dotknięte, jak obliczono naprawiony stan i jak walidatorzy niezależnie doszli do tego samego rezultatu.

Jeśli ten zapis pokaże, że skorygowano wyłącznie zmiany związane z incydentem, ukierunkowane odzyskiwanie może zachować więcej prawidłowej aktywności niż szerokie cofnięcie. Bez tego sieć mogłaby wznowić działanie, podczas użytkownicy nadal nie będą w stanie zweryfikować, dlaczego niektóre sfinalizowane zmiany zostały zmienione, a inne zachowane.

Ten artykuł ma wyłącznie charakter informacyjny i nie stanowi porady finansowej ani inwestycyjnej. Warunki sieciowe i instrukcje odzyskiwania mogą ulec zmianie w miarę publikowania kolejnych aktualizacji przez MultiversX.