Arbitrum przejął skradzione środki z Binance – ich zwrot wymaga głosowania

Rada Bezpieczeństwa Arbitrum użyła tymczasowej aktualizacji kontraktu, aby przenieść kryptowalutę powiązaną z atakiem hakerskim na Binance. Jej działania awaryjne powstrzymały atakującego przed przeniesieniem tych aktywów, ale decyzja o ich miejscu docelowym należy do odrębnego procesu zarządzania.

Rada Bezpieczeństwa Arbitrum przeniosła 8 425 ETH i 74 559 805,2 ARB powiązanych z atakiem hakerskim na Binance na adres przechowujący, którego środki wymagają głosowania zarządzania DAO, aby mogły zostać ponownie przeniesione.

Komunikat o działaniu awaryjnym Arbitrum podaje, że interwencja miała miejsce o 08:08 czasu HKT 30 października. Współtwórcy przygotowali tymczasową zmianę w kontrakcie inbox sieci Ethereum, członkowie rady zweryfikowali ją i podpisali, a pierwotna implementacja została przywrócona po transferach.

Działanie przyciągnęło uwagę, ponieważ nie wymagało klucza prywatnego atakującego. Arbitrum wykorzystało uprawnienia nad własną infrastrukturą do utworzenia wiadomości, które przeniosły aktywa w Arbitrum One.

Jego publiczny komunikat opisuje wynik jako zamrożenie i zastrzega dalsze przenoszenie zarządzaniu ArbitrumDAO. Przeniesienie funduszy od exploitatora i zwrócenie ich uprawnionemu odbiorcy są zatem odrębnymi decyzjami.

Interwencja Arbitrum wykorzystała uprawnienie ponad portfelem

Zwykła płatność kryptowalutą jest autoryzowana przez konto, które ją wysyła. Komunikat o incydencie Arbitrum opisuje wyjątkową drogę: zmianę infrastruktury, która określa, jak wiadomości z Ethereum są obsługiwane na rollupie.

Dodana funkcja sendUnsignedTransactionOverride mogła imitować transakcję międzyłańcuchową, podszywając się pod jej nadawcę. Dwie wiadomości przeniosły ETH i ARB ze zidentyfikowanego adresu na adres przechowujący kończący się na 0DA0.

Rozróżnienie polega na tym, czy chodzi o przejęcie klucza atakującego, czy o wykorzystanie uprawnień administracyjnych nad systemem, w którym to konto istnieje. Opublikowane wyjaśnienie Arbitrum opisuje to drugie.

Jego konstytucja przyznaje przywileje właściciela łańcucha DAO i Radzie Bezpieczeństwa. Przywileje te obejmują zmianę podstawowych implementacji i parametrów protokołu, w tym powiązanych kontraktów na Ethereum.

Rola właściciela łańcucha znajduje się ponad regułami konkretnej aplikacji. Jest częścią architektury zarządzania Arbitrum, więc uprawnienia dostępne dla niej nie mogą być wnioskowane wyłącznie z uprawnień widocznych w portfelu użytkownika.

Ethereum zapewniło miejsce dla transakcji administracyjnej, podczas gdy aktywa były przechowywane w Arbitrum One. Zdarzenie nie wykazało uprawnienia do przepisywania niepowiązanych kont Ethereum ani zabierania natywnego bitcoina z innej sieci.

Dokumentacja dla deweloperów Arbitrum wyjaśnia, że wiadomości z łańcucha nadrzędnego wchodzą do rollupa przez infrastrukturę inbox. Użytkownicy mogą wysyłać transakcje przez opóźniony inbox, gdy sekwencer jest niedostępny lub ich nie uwzględnia.

Należy odróżnić tę zwykłą ścieżkę wiadomości od tymczasowego nadpisania z incydentu. Dostęp zwykłego użytkownika do opóźnionego inbox nie przyznaje specjalnego uprawnienia do podszywania się pod nadawcę, utworzonego na potrzeby działania awaryjnego.

Interwencja Rady Bezpieczeństwa była możliwa, ponieważ mogła zatwierdzić aktualizację odpowiedniego kontraktu. Zmiana kodu dostarczyła wyjątkowej funkcjonalności; portfel atakującego nie zatwierdził transferu dobrowolnie.

Posiadanie klucza prywatnego przez właściciela portfela opisuje zatem tylko jedną część układu bezpieczeństwa. W systemie podlegającym aktualizacjom użytkownicy zależą również od sposobu rozdzielania i ograniczania uprawnień administracyjnych.

Tymczasowa aktualizacja połączyła ratunek i przywrócenie

Arbitrum stwierdził, że aktualizacja, transfery i przywrócenie stanowiły jedno działanie atomowe. W kategoriach transakcji operacje zostały połączone w taki sposób, że wdrożenie awaryjne nie miało pozostać aktywnym wdrożeniem po zakończeniu operacji.

W zawiadomieniu Arbitrum transakcja administracyjna została zidentyfikowana jako 0xb69c81774f507d46ce776aeaed8b4d31df96dd66ce6fd05073481011835355d6. Oświadczenie identyfikuje operacje i miejsce docelowe oddzielnie od jakiejkolwiek interpretacji ich skutków prawnych.

Przywrócenie wcześniejszego wdrożenia usunęło funkcję specjalną z aktywnego wdrożenia używanego po tej transakcji. Nie usunęło to jednak podstawowego uprawnienia do aktualizacji, które pozwoliło radzie je wprowadzić.

Analogia jest przydatna, jeśli pozostaje w tych granicach: wycofanie tymczasowej instrukcji nie znosi urzędu uprawnionego do wydania kolejnej instrukcji. Użytkownicy oceniający ryzyko przyszłej interwencji potrzebują zarówno stałych zasad zarządzania, jak i czasu życia tymczasowego kodu.

Fundacja w swojej architekturze zarządzania opisuje wykonawców aktualizacji oraz podmioty upoważnione do ich wywoływania. Uprawnienia awaryjne i wolniejsza ścieżka DAO to różne sposoby dotarcia do uprzywilejowanych operacji kontraktowych.

Zapis techniczny może ustalić, które wdrożenie zostało zainstalowane i przywrócone oraz które wiadomości zostały utworzone. Nie rozstrzyga jednak samodzielnie, czy adres został prawidłowo zidentyfikowany jako posiadający skradziony majątek.

Ta identyfikacja zależy od dowodów dotyczących incydentu i podmiotów, które je oceniły. W zawiadomieniu Arbitrum adres został zidentyfikowany jako powiązany z exploitacją Binance i stwierdzono, że środki i aplikacje innych użytkowników nie zostały naruszone.

Wąski zakres opublikowanego działania jest istotny. Rada obrała za cel zidentyfikowane aktywa w swoim zarządzanym łańcuchu; nie ogłosiła sieciowego wycofania całej aktywności podczas kradzieży.

Dla czytelnika weryfikującego odzyskanie trzy informacje należą do siebie: wykonana transakcja administracyjna, transfery, które spowodowała, oraz stan kontraktu przechowującego afterwards. Zrzut ekranu samego salda nie może wyjaśnić uprawnienia, które je przeniosło.

To samo podejście ma zastosowanie do każdego późniejszego uwolnienia. Wynik zarządzania, wykonywalne instrukcje i zakończony transfer tworzą łańcuch dowodów; zatwierdzenie na jednym etapie nie jest dowodem, że wszystkie późniejsze etapy miały miejsce.

Dziewięciu sygnatariuszy może działać przed pełnym głosowaniem DAO

Rada Bezpieczeństwa liczy 12 członków, a działania awaryjne wymagają 9 zatwierdzeń. FAQ dotyczące zarządzania odróżnia tę natychmiastową ścieżkę od dłuższej sekwencji stosowanej w zwykłych propozycjach.

Dziewięć z 12 to próg podpisów wynoszący 75%. Pozwala on na przeprowadzenie działania, gdy 3 członków jest niedostępnych lub przeciwnych, podczas gdy wstrzymanie zatwierdzenia przez 4 członków uniemożliwiłoby osiągnięcie tego progu, gdyby pozostałych 8 go popierało.

Ta arytmetyka opisuje zasadę zatwierdzania, a nie niezależność zaangażowanych osób. Niezależność zależy od powiązań, konfliktów interesów, kontroli kluczy oraz tego, czy rzekomo odrębni sygnatariusze mogą w praktyce być kierowani przez ten sam podmiot.

Arbitrum publikuje skład rady, w tym doświadczenie zawodowe członków i przypisanie do kohort. Lista pozwala użytkownikom zidentyfikować decydentów, zamiast traktować „radę” jako anonimową usługę techniczną.

Jej konstytucja wymaga raportowania przejrzystości po działaniach awaryjnych i ogranicza mandat awaryjny do rzeczywistych zagrożeń bezpieczeństwa. DAO może zmienić lub znieść uprawnienia rady w drodze procesu propozycji konstytucyjnych.

Szybsza ścieżka ma wyraźne uzasadnienie operacyjne. Oczekiwanie na pełne głosowanie tokenowe może pozostawić środki dostępne dla atakującego, podczas gdy delegaci omawiają propozycję i trwa okno głosowania.

Konto stopniowej decentralizacji Arbitrum opisuje radę jako mechanizm na wypadek krytycznych sytuacji awaryjnych w miarę rozwoju zarządzania. Przedstawia szybką reakcję i rozproszone zarządzanie jako części tej samej architektury.

Przeciwstawna obawa jest odnotowana w ocenie Arbitrum przygotowanej przez L2BEAT, która traktuje natychmiastowe uprawnienie do aktualizacji jako istotne założenie zaufania. Jej klasyfikacja na poziomie Stage 1 dopuszcza interwencję rady ds. bezpieczeństwa; nie oznacza to, że każda ważna operacja jest poza ludzkim uznaniem.

Te relacje opisują to samo uprawnienie z różnych perspektyw. Arbitrum podkreśla zdolność do reagowania na krytyczne zdarzenie, podczas gdy ocena ryzyka wskazuje konsekwencje, gdyby uprzywilejowani decydenci działali w złej wierze lub gdyby ich klucze zostały skompromitowane.

Operacja Binance pokazuje interwencję skierowaną na podejrzane skradzione aktywa. Ocena architektury wymaga rozważenia, kto mógłby zatwierdzić kolejną interwencję i jakie egzekwowalne ograniczenia mają zastosowanie do tego uprawnienia.

Zamrożenie środków i wybór odbiorcy mają różne terminy

Awaryjne zamrożenie odpowiada na natychmiastowe pytanie: czy zidentyfikowanym aktywom można uniemożliwić opuszczenie systemu? Zwolnienie odpowiada na inne pytanie: który odbiorca powinien je otrzymać, na jakiej podstawie dowodowej i poprzez jakie instrukcje?

Zawiadomienie Binance określa wymóg zarządzania, ale nie wyznacza terminu zwrotu środków klientom. Głosowanie DAO musi zostać przygotowane wokół proponowanego miejsca docelowego i wykonalnego działania, zanim będzie mogło rozstrzygnąć ten kolejny krok.

Czas początkowej interwencji można jednak obliczyć na podstawie dwóch zawiadomień o incydencie. Binance wskazał początek kradzieży na 20:05 UTC 29 października; 08:08 HKT 30 października to 00:08 UTC, czyli odstęp około 4 godzin i 3 minut.

Obliczenie dotyczy początku zgłoszonej kradzieży i podanego przez Arbitrum czasu działania. Nie jest to pomiar tego, ile czasu rada potrzebowała na działanie po otrzymaniu alertu, ponieważ zawiadomienie nie określa, kiedy ten alert nadszedł.

Nie ustala również, że wszystkie aktywa z szerszego ataku hakerskiego pozostały odzyskiwalne w ciągu tych godzin. Interwencja dotyczyła zidentyfikowanych zasobów na Arbitrum One, podczas gdy kradzież i późniejsze transfery obejmowały inne sieci.

Czas, który upłynął do zamrożenia, oraz czas, który upłynął do zwrotu środków, wymagają zatem odrębnych zdarzeń początkowych i końcowych. To drugie wymagałoby zakończonego zwrotu upoważnionemu odbiorcy, a nie jedynie ogłoszenia, że aktywa zostały unieruchomione.

Propozycja z datą dostarczyłaby kolejnej części tej chronologii, po której nastąpiłoby jej głosowanie, obowiązujące okresy oczekiwania i wykonanie. Dopóki te zdarzenia nie nastąpią, znacznik czasu zamrożenia nie zapewnia automatycznej daty wypłaty dla klientów.

Przewodnik po głosowaniu nad propozycjami Arbitrum rozróżnia dyskusję, sygnalizację poza łańcuchem i formalne głosowanie on-chain. Pozytywny wątek dyskusji lub sondaż temperatury nie jest tym samym zdarzeniem co wykonanie poprzez kontrakty zarządzania.

Konstytucja osobno klasyfikuje propozycje, które zmieniają oprogramowanie lub wymagają uprawnień właściciela łańcucha, jako konstytucyjne. Przyznaje tym propozycjom etapy głosowania, oczekiwania i wdrażania, przy czym obowiązująca ścieżka jest określana przez to, co propozycja faktycznie robi.

Propozycja transferu wymaga zatem więcej szczegółów niż stwierdzenie, że środki powinny zostać zwrócone. Adres odbiorcy, kwota, uprawnienie i wszelkie warunki muszą odpowiadać instrukcjom, które głosujący mają zatwierdzić.

Ta precyzja jest szczególnie istotna w przypadku odzyskiwania środków z udziałem giełdy. Binance obiecał pokryć straty klientów ze środków firmy, więc odbiorcą odzyskanych aktywów może być giełda lub inny upoważniony mechanizm odzyskiwania, a nie każdy posiadacz konta otrzymujący bezpośrednią dystrybucję on-chain.

Jego program wymiany aktywów był kontynuowany, podczas gdy oryginalne aktywa pozostawały zamrożone gdzie indziej. Wpływy z odzyskiwania i zobowiązania wobec klientów wymagają zatem uzgodnienia, aby ta sama kwota nie była przedstawiana jako dwa odrębne zwroty.

Rozważmy hipotetyczną giełdę, która zastępuje 100 skradzionych tokenów ze swojego skarbca. Jeśli DAO później zwróci 20 oryginalnych tokenów, klienci nie otrzymali 120 tokenów restytucji; giełda odzyskała część kosztu przywrócenia pierwotnego zobowiązania wynoszącego 100 tokenów.

Jeśli tokeny nie zostały jeszcze wymienione, to samo odzyskanie może zamiast tego zmniejszyć pozostały niedobór wobec klientów. Prawidłowy opis zależy od rzeczywistego zobowiązania i ustaleń dotyczących spłaty w momencie dokonania transferu.

Proces decyzyjny powinien uwidocznić te ustalenia. Adres odzyskiwania wskazuje, dokąd trafiają aktywa w łańcuchu, natomiast towarzysząca dokumentacja wyjaśnia, kto nad nim sprawuje kontrolę i czyje roszczenie transfer ma zaspokoić.

Ratunek KelpDAO już pokazał, co może opóźnić zwrot

Arbitrum zastosowało porównywalną interwencję po wykorzystaniu KelpDAO w kwietniu. Jego zawiadomienie o działaniach z kwietnia wskazało 30 765,667501709008927568 ETH przeniesionych na ten sam adres przechowywania i stwierdziło, że zarządzanie będzie musiało zatwierdzić zwolnienie.

Jak wcześniej informował crypto.news, rada unieruchomiła ETH powiązane z Kelp bez ogłoszenia ogólnego przerwania dla innych użytkowników lub aplikacji. Wartość podana wówczas wynosiła około 71 milionów dolarów.

Kolejne etapy obejmowały proponowane skoordynowane odzyskanie dla posiadaczy rsETH. Aave Labs, KelpDAO, LayerZero, EtherFi i Compound wspólnie opracowały propozycję zwolnienia z 25 kwietnia.

Jej deklarowanym celem było skierowanie unieruchomionego ETH na przywrócenie zabezpieczenia rsETH. Propozycja określała, że aktywa są już zamrożone, a ich miejsce docelowe stanowi pozostałe pytanie zarządcze.

Roszczenia prawne skomplikowały następnie proces. Zawiadomienie o zakazie z 1 maja, opisane w relacji z sądowego zamrożenia, dotyczyło roszczeń wierzycieli z wyrokami dotyczącymi terroryzmu, którzy argumentowali, że aktywa mogą zaspokoić wyroki przeciwko Korei Północnej.

Ważne rozróżnienie historyczne polega na różnicy między tym zarzutem a ustalonym orzeczeniem o własności. Przypisanie wykorzystania podmiotowi powiązanemu z państwem samo w sobie nie odpowiada na wszystkie pytania dotyczące własności aktywów zabranych innej stronie.

Relacja z głosowania zarządczego z 8 maja opisywała silne poparcie dla propozycji odzyskania i postanowień o indemnifikacji. Wsparcie dla planu i ekspozycja prawna osób go wdrażających były rozwiązywane poprzez odrębne ustalenia.

Zmieniona dyskusja na publicznym forum odnosiła się następnie do transferu do depozytu Aave LLC pod nadzorem sądowym. Ta majowa dyskusja stanowi kontekst historyczny, a nie dowód, że aktywa Binance obecnie stoją w obliczu tego samego roszczenia lub procedury sądowej.

Porównanie wskazuje udowodnione źródło opóźnienia: rada może usunąć aktywa spod bezpośredniej kontroli atakującego, zanim zostanie ustalony prawowity odbiorca i zgodna z prawem droga transferu. Z szybkości początkowego zamrożenia nie wynika automatycznie żaden stały harmonogram zwrotu.

Przedwczesne byłoby zatem przypisywanie statusu prawnego odzyskania KelpDAO do nowego depozytu Binance. Odpowiednia propozycja i wszelkie rzeczywiste nakazy prawne muszą wskazywać, których aktywów i stron dotyczą.

Adres przechowywania może zawierać więcej niż jedno odzyskanie

Zawiadomienia Arbitrum wskazują ten sam cel kończący się na 0DA0 dla działań Binance i KelpDAO. To sprawia, że zapisy transferów i przypisanie aktywów są szczególnie istotne, gdy czytelnicy próbują śledzić odzyskanie za pośrednictwem eksploratora.

Wyświetlane saldo ETH jest sumą dla adresu w momencie zapytania. Bez historii transakcji i odpowiednich ograniczeń nie wskazuje, która część należy do którego incydentu ani czy wcześniejsza alokacja już się zmieniła.

Kwota 8 425 ETH z zawiadomienia Binance jest zatem ilością specyficzną dla incydentu, którą należy śledzić. Zastąpienie jej całym bieżącym saldem ETH adresu przechowywania mogłoby połączyć niepowiązane wpływy, pozostałe zasoby lub późniejsze transakcje.

Saldo ARB wymaga własnego rekordu transferu tokenów. Dodanie natywnego ETH i liczby tokenów nie daje użytecznej pojedynczej wielkości, chyba że oba zostaną wycenione przy użyciu ujawnionej ceny i znacznika czasu.

Na przykład wycena alokacji Binance wynosiłaby 8 425 pomnożone przez wybraną cenę ETH plus 74 559 805,2 pomnożone przez wybraną cenę ARB. Kwota zmienia się, gdy zmienia się którakolwiek z cen, nawet jeśli żaden token nie opuszcza adresu przechowywania.

Przy ilustracyjnej cenie ETH wynoszącej 2200 USD i cenie ARB wynoszącej 0,16 USD wzór daje około 30,46 mln USD. Są to hipotetyczne dane wejściowe wyceny, a nie kwotowane ceny rynkowe ani księgowanie straty przez Arbitrum.

Obliczenie wyjaśnia, dlaczego nagłówek w dolarach może się zmieniać, podczas gdy odzyskana ilość pozostaje stała. Raportowanie ilości tokenów zachowuje stabilny punkt odniesienia dla rekordu odzyskiwania.

Podobne rozróżnienie dotyczy opłat i liczby transakcji. Jedna administracyjna transakcja Ethereum może utworzyć wiele wiadomości i transferów na rollupie, więc liczenie wyłącznie transakcji łańcucha nadrzędnego nie opisuje każdego wynikowego ruchu aktywów.

Dokumentacja cyklu życia transakcji sieci rozdziela złożenie i włączenie w łańcuchu nadrzędnym i podrzędnym. Badanie interwencji wymaga śledzenia tej relacji, a nie traktowania obu łańcuchów jako niezależnych dowodów duplikujących się odzyskiwań.

Użyteczny rekord dla czytelników jest zatem specyficzny dla incydentu: oryginalny adres, przeniesione ilości, miejsce docelowe przechowywania, autoryzacja zwolnienia i końcowy odbiorca. Każda pozycja odpowiada na inną część pytania, dokąd trafiły aktywa.

Samodzielne przechowywanie i zarządzanie siecią obejmują różne uprawnienia

Samodzielne przechowywanie oznacza, że użytkownik kontroluje poświadczenia zwykle wymagane do autoryzacji transakcji z konta. Nie obiecuje, że każdy blockchain, na którym istnieje konto, ma niezmienne zasady lub nie ma uprawnień administracyjnych.

Opublikowana architektura Arbitrum obejmuje sekwencer, mechanizmy walidacji i rozstrzygania sporów, uprawnienia do aktualizacji oraz zarządzanie. Każdy komponent odpowiada za inną część sposobu akceptowania transakcji i zmian w systemie.

Jej dokumentacja sekwencera opisuje alternatywne rozwiązania dotyczące włączania, gdy sekwencer zawodzi lub cenzuruje wiadomości. Te zabezpieczenia dotyczą kolejności i dostępności transakcji w ramach zasad protokołu.

Awaryjna aktualizacja oprogramowania dotyczy samych zasad i uprzywilejowanych kontraktów. Obejście niedostępnego sekwencera nie usuwa odrębnej zdolności upoważnionych podmiotów zarządzających do zmiany aktualizowalnej implementacji.

Dokumentacja kontroli dostępu OpenZeppelin dokonuje podobnego rozróżnienia na poziomie kontraktu. Własność i role określają, które konta mogą wywoływać uprzywilejowane funkcje, a blokada czasowa może opóźniać przypisane jej operacje.

Praktyczne pytanie dotyczące bezpieczeństwa brzmi, dokąd prowadzą te uprawnienia. Aplikacja może używać multisig, podczas gdy kontrakt sieci wyższego poziomu pozostaje aktualizowalny przez odrębny zestaw sygnatariuszy, z których każdy ma własne zasady.

Aave zapewnia użyteczny kontrast w swojej dokumentacji zarządzania. Rozróżnia strażników awaryjnych protokołu od strażników awaryjnych zarządzania, przypisując różnym organom różne mandaty interwencyjne.

To rozdzielenie nie dowodzi, że każdy system korzystający ze strażnika jest równie bezpieczny. Pokazuje, dlaczego nazwa roli jest mniej informacyjna niż dokładne funkcje, które może wywoływać, wymagane zatwierdzenia i proces jej zastąpienia.

Sam exploit Binance obejmował inny rodzaj uprawnień. Śledczy opisali ważne autoryzacje portfela w sekwencji ataku na Ethereum, podczas gdy odzyskiwanie przez Arbitrum wykorzystało ścieżkę administracji siecią po dotarciu aktywów do jej łańcucha.

Tych dwóch zdarzeń nie należy sprowadzać do twierdzenia, że klucze prywatne nie mają już znaczenia. Pokazują one, że uprawnienia do podpisywania, zachowanie delegowanego konta i uprawnienia do aktualizacji sieci są odrębnymi częściami środowiska bezpieczeństwa aktywów.

Członkostwo w radzie i klucze podpisujące wymagają odrębnej analizy

Publiczny skład identyfikuje osoby, podczas gdy multisig wymaga podpisów od określonych kluczy. Oba rekordy są istotne: nazwisko na stronie członkostwa samo w sobie nie pokazuje, że klucz jest bezpiecznie przechowywany lub dostępny podczas incydentu.

Obowiązki członków Arbitrum wymagają bezpieczeństwa operacyjnego, w tym nowego portfela sprzętowego dedykowanego tej roli. Opublikowane oczekiwania obejmują różnorodność organizacji, lokalizacji i stref czasowych, aby wspierać niezależność i szybką reakcję.

Te dwa cele mogą ciągnąć w różnych kierunkach operacyjnych. Podpisujący potrzebują wystarczającego rozdzielenia, aby oprzeć się powszechnemu naruszeniu bezpieczeństwa, a jednocześnie wystarczająca ich liczba musi być osiągalna, aby osiągnąć próg, gdy wystąpi sytuacja awaryjna.

Zasada 9 z 12 nie eliminuje tego problemu koordynacji. Jeśli 3 członków jest niedostępnych, każdy pozostały członek musi zatwierdzić, aby działanie mogło zostać przeprowadzone; jeśli 4 jest niedostępnych, natychmiastowy próg podpisania nie może zostać osiągnięty.

To jest kalkulacja dostępności, a nie dowód, że którekolwiek z tych zdarzeń miało miejsce podczas reakcji Binance. Opublikowana transakcja odnotowuje interwencję, która rzeczywiście została przeprowadzona.

Przegląd rady opisuje ustalenia dotyczące wyborów i usuwania. Mówi, że członek może zostać usunięty w drodze głosowania DAO spełniającego obowiązujące warunki uczestnictwa i superwiększości, lub poprzez zatwierdzenie przez co najmniej 9 członków rady.

Usunięcie decydenta i usunięcie uprawnienia kontraktu to różne akty. System administracyjny musi zapewnić, że uprawnienia odpowiadają autoryzowanemu członkostwu po wyborach, rezygnacji lub zastąpieniu.

Arbitrum publikuje rejestr adresów wdrożeniowych identyfikujący kontrakty zarządzania, w tym infrastrukturę wyborów i usuwania. Pozwala czytelnikom odróżnić interfejs głosowania od kontraktów, które rejestrują i wdrażają wynik.

Ogłoszenie wyborów nie jest zatem pełnym zapisem instalacji. Odpowiednia zmiana on-chain ustala, które klucze mogą następnie pełnić tę rolę.

Ta sama różnica ma zastosowanie, gdy podpisujący rotuje klucz. Osoba może pozostać członkiem rady, podczas gdy autoryzowane poświadczenie podpisywania się zmienia, więc samo porównywanie nazwisk pominęłoby ważne zdarzenie bezpieczeństwa.

Dokumenty zarządzania Arbitrum opisują oddzielne instancje multisig w Ethereum i łańcuchach zarządzanych. Ich uprawnienia mają zastosowanie do odpowiednich kontraktów, więc wymienione adresy rady nie są wymienne w każdej operacji.

W przypadku działania Binance opublikowane zawiadomienie identyfikuje aktualizację kontraktu w Ethereum oraz transfery w Arbitrum One. Ta relacja określa, które uprawnienia i zapisy transakcji są istotne dla interwencji.

Istnieje dalsza różnica między przynależnością a kontrolą podpisu. Publiczny stosunek zatrudnienia może pomóc czytelnikom ocenić koncentrację, ale nie dowodzi, że pracodawca kontroluje klucz danej osoby lub nakazał konkretne głosowanie.

Dowód rzeczywistego polecenia, ustalenia wspólnego przechowywania lub wspólnej infrastruktury podpisywania odpowiadałby na inne pytanie niż biografia zawodowa. Analiza nie powinna przekształcać jednego w drugie bez informacji potwierdzających.

Raport przejrzystości może ułatwić zbadanie tych granic poprzez identyfikację podpisujących, działania, czasu i powodu pilności. Relacja z raportu może następnie zostać porównana z transakcją administracyjną i deklarowanym mandatem konstytucyjnym.

Zmiana długoterminowych uprawnień rady byłaby odrębną decyzją zarządczą. Nie określiłaby automatycznie, dokąd powinny trafić już unieruchomione aktywa Binance, ponieważ zwolnienie nadal wymaga zdefiniowanego odbiorcy i instrukcji.

Głosowanie musi dokładnie określać, co zostanie wykonane

Dla posiadaczy tokenów następnym konkretnym zdarzeniem odzyskiwania jest propozycja określająca alokację Binance i jej miejsce docelowe. Obecne zawiadomienie przypisuje tę decyzję zarządzaniu, ale samo nie zapewnia zakończonego transferu z powrotem do giełdy.

Konstytucja Arbitrum zaleca, aby propozycje określały specyfikacje, kroki wdrożenia, koszty i harmonogram. Propozycja involving strona trzecia powinna również zawierać odpowiednią dokumentację prawną i procedury.

Wyborcy muszą porównać tekst opisowy z instrukcjami wykonywalnymi. Propozycja może podawać kwotę w prozie, podczas gdy ładunek transakcji wywołuje kontrakt z własnymi parametrami aktywów, odbiorcy i uprawnień.

Przewodnik zarządzania OpenZeppelin rozróżnia liczenie głosów, kworum, wykonanie propozycji i komponenty timelock. Główny wynik głosowania jest tylko jednym etapem systemu zbudowanego z tych oddzielnych kontraktów i reguł.

Propozycja odzyskania powinna jasno określać, czy jej miejscem docelowym jest portfel kontrolowany przez giełdę, multisig odzyskiwania czy pośrednik podlegający dalszym warunkom. Strona kontrolująca miejsce docelowe decyduje o tym, kto może działać po zakończeniu transferu DAO.

Wszelkie odrębne ustalenia dotyczące przechowywania lub indemnizacji powinny być przypisane do ich rzeczywistych warunków. Dyskusja KelpDAO pokazuje, że takie ustalenia mogą być częścią procesu odzyskiwania, ale nie dostarcza domyślnych warunków dla nowego incydentu.

Odpowiedzialność sygnatariuszy trwa po transferze awaryjnym. Konstytucyjny wymóg przejrzystości dotyczy zarówno tego, dlaczego działanie zostało uzasadnione, jak i tego, co zrobił kod.

Ten raport można porównać z zapisem transakcji, podaną identyfikacją adresu powiązanego z eksploatatorem oraz ograniczeniami opisanymi w publicznym ogłoszeniu. Ostateczne zwolnienie dodaje kolejne obserwowalne zdarzenie do tej sekwencji.

Oświadczenie Arbitrum z 30 października umieszcza aktywa powiązane z Binance pod adresem 0x0000000000000000000000000000000000000DA0 i stwierdza, że do ich przeniesienia wymagane jest głosowanie governance.

Na co uważać

• Propozycja zwolnienia: Ilości specyficzne dla incydentu, proponowany odbiorca i wykonalne instrukcje przedłożone do zarządzania.
• Raport rady: Udokumentowana podstawa działania awaryjnego i zaangażowane zatwierdzenia.
• Ruchy wstrzymanych środków: Transfery przypisywane alokacji Binance, oddzielnie od innych aktywów pod tym samym adresem.
• Warunki prawne: Wszelkie rzeczywiste nakazy lub ustalenia dotyczące przechowywania regulujące proponowane zwolnienie.
• Wykonanie: Ostateczna transakcja przenosząca środki po zatwierdzeniu i zakończeniu obowiązujących okresów oczekiwania.

FAQ