Jak Polygon zwróci 70 milionów skradzionych POL do portfeli odzyskiwania

Dwie kradzieże pozostawiły miliony POL na pięciu zablokowanych adresach. Propozycja Polygon miałaby przenieść te salda do portfeli odzyskiwania poprzez zmianę zasad sieci w określonym bloku. Umieszczenie tam tokenów rozwiązałoby jedną część odzyskiwania. Zwrócenie ich klientom to osobne zadanie.

Propozycja ulepszenia Polygon zidentyfikowała 70,49 miliona POL na pięciu zablokowanych adresach, które skoordynowany hard fork mógłby przenieść do portfeli odzyskiwania wyznaczonych dla Binance i Polymarket.

Propozycja opisuje zmianę sald natywnego POL w ustalonym bloku. Oprogramowanie wyzerowałoby pięć wymienionych sald i uznałoby odpowiednie kwoty na zweryfikowanych adresach odzyskiwania.

Rozróżnienie dotyczy salda, którego sieć uniemożliwiła przeniesienie, oraz salda, które zespół odzyskiwania może kontrolować. Dla klientów istnieje dodatkowe rozróżnienie między tokenami docierającymi do portfela odzyskiwania a platformą uznającą i wypłacającą roszczenie.

Jak sumują się oba incydenty

Propozycja przypisuje 46,63 miliona POL na jednym adresie do incydentu Binance oraz 23,86 miliona na czterech adresach do incydentu Polymarket. Zsumowanie tych zaokrąglonych liczb daje 70,49 miliona POL. Dzieląc każdą z nich przez tę sumę, udział Binance wynosi około 66,2%, a Polymarket 33,8%.

Są to udziały w proponowanym odzyskiwaniu, a nie miary całkowitych strat obu incydentów. Szacunek w dolarach zależy również od użytego znacznika czasu i ceny. Ilości w propozycji są denominowane w POL.

Adresy mają większe znaczenie niż nagłówkowa kwota w dolarach

Salda referencyjne w propozycji wynoszą łącznie 70 489 329,34 POL. Adres Binance odpowiada za 46 626 593,27 POL, podczas gdy cztery adresy Polymarket odpowiadają za 23 862 736,07 POL. Są to salda w blokach referencyjnych wybranych przez autorów. Wcześniejszy transfer z gorącego portfela Binance był nieco mniejszy niż saldo później zarejestrowane na adresie odbiorcy.

Różnica czterech tokenów przy transferze ponad 46 milionów ledwie zmieniłaby nagłówkową kwotę. Ma znaczenie dla implementatora, ponieważ istnieją dwie możliwe liczby do zakodowania: kwota prześledzona od nadawcy i pełne saldo w miejscu docelowym. Propozycja opisuje tę drugą jako kwotę do odczytania ze stanu bezpośrednio przed aktywacją, z poprzedzającym zrzutem stanu do opublikowania, aby zmiany były widoczne. Projekt należy zatem czytać jako procedurę ustalania ostatecznej kwoty, wraz z tabelą ustalającą przybliżoną omawianą kwotę.

Liczba dotycząca Polymarket przedstawia odrębny problem pomiarowy. W propozycji incydent oszacowano na około 28 milionów POL, a cztery wybrane salda na około 23,86 miliona POL. W stosunku do tego zaokrąglonego szacunku incydentu wybrana kwota stanowi około 85%, pozostawiając różnicę około 4,14 miliona POL. To odejmowanie mierzy lukę między szacunkiem incydentu a wybranymi saldami. Nie może ustalić, gdzie trafiły pozostałe tokeny ani czy część z nich można by odzyskać inną drogą.

Przeliczenie na dolary dodaje kolejną zmienną. Przy 0,092 USD za POL saldo referencyjne byłoby warte około 6,49 miliona USD. Przy 0,096 USD te same tokeny byłyby warte około 6,77 miliona USD. Obliczenie mnoży referencyjną ilość z propozycji przez dwie ilustracyjne ceny. Wyjaśnia, w jaki sposób kwoty w dolarach bliskie 6,5 miliona USD i 6,8 miliona USD mogą opisywać niemal ten sam proponowany transfer. Początkowe doniesienia podawały wartość około 6,5 miliona USD. Decyzja o wypłacie wymagałaby wyraźnej daty wyceny i źródła ceny.

Co pozostawiłby proponowany fork

Proponowane odzyskanie obejmuje około 85% z około 28 milionów POL przypisanych w poście na forum do incydentu z Polymarket. Kuszące jest opisanie pozostałych 15% jako kwoty, której fork nie zdołałby odzyskać. Dokładniejsze porównanie dotyczy przybliżonej liczby incydentu i sald, które według autorów wciąż znajdują się pod czterema adresami. Do wyjaśnienia różnicy potrzebne byłoby odrębne postępowanie śledcze.

Porównanie z Binance jest inne. W propozycji wskazano jeden transfer 46 626 589,6 POL z gorącego portfela oraz saldo 46 626 593,27 POL u odbiorcy w momencie wykonania referencyjnego zrzutu. Saldo docelowe było o około 3,67 POL większe niż ten transfer. Różnica jest wystarczająco mała, by zniknąć w każdym zaokrąglonym nagłówku, ale pomaga wyjaśnić, dlaczego zrzut wykonany na określonym bloku jest bardziej użyteczny niż podawanie kwoty z pierwotnej transakcji.

Druga lekcja dotyczy jednostek. Tabela referencyjna używa natywnego POL, podczas gdy wcześniejszy transfer z Binance obejmował również 6 185 900,1 USDT. Suma w dolarach obejmująca oba elementy dotyczyłaby innego zestawu aktywów niż proponowany fork. Raport o zablokowanych środkach mógłby zasadnie omawiać oba przypadki, pod warunkiem że jasno wskaże, która organizacja podjęła każde działanie i czy środki następnie się przemieszczały.

Oba przypadki łączy również mechanizm aktywacji, choć nie dzielą jednego konta. Oprogramowanie Polygon zasiliłoby odrębne adresy odzyskiwania, zachowując rozróżnienie między saldami przypisanymi do każdego incydentu. Odbiorcy mogliby zatem uzgodnić otrzymane środki z własnymi roszczeniami i rejestrami odszkodowań. Post na forum nie łączy roszczeń wynikających z obu incydentów ani nie przyznaje jednej platformie władzy nad wpływami drugiej.

Co może nam powiedzieć zablokowane saldo

Blokada może uniemożliwić wymienionemu adresowi transfer środków, podczas gdy saldo nadal widnieje w łańcuchu. Obserwator może zobaczyć, ile pozostało pod adresem, nie będąc w stanie ustalić, ile należy się poszczególnemu klientowi.

Pięć sald określa zakres tej propozycji. Aktywo zaangażowane w którykolwiek z incydentów, ale znajdujące się poza tymi saldami, wymagałoby własnej drogi odzyskania.

Co może ustalić zapis transferów

W propozycji opisano dwa natywne transfery o 18:30:34 i 18:35:59 UTC 29 października. Razem przeniosły one 3 282 275,71 POL z jednego adresu na drugi. Oba znaczniki czasu mają znaczenie, ponieważ pomagają ustalić kolejność, w jakiej salda rozprzestrzeniały się między portfelami. Historia transakcji może pokazać ruch i kwoty, nawet gdy osoby kontrolujące klucze są trudniejsze do zidentyfikowania.

Propozycja wiąże wymienione adresy z incydentami. Do niezależnej weryfikacji recenzent musiałby prześledzić wskazane zapisy transakcji i porównać adresy źródłowe z kontami zidentyfikowanymi przez poszkodowane platformy. Jest to bardziej konkretne niż obserwowanie, jak kilka portfeli przenosi pieniądze tego samego dnia. Różni się to również od udowodnienia roszczenia prawnego do każdej monety wciąż znajdującej się na koncie.

Adres, który przechowywał natywne POL i stablecoina, może zilustrować ograniczenia języka na poziomie portfela. Emitent stablecoina może działać poprzez kontrakt stablecoina. Natywny POL jest częścią rozliczania sald sieci. Oba aktywa dzielą adres, ale osoby, które mogą zapobiec transferom, oraz mechanizm, którego mogą użyć, zależą od rodzaju aktywa.

Wniosek opisuje dodatkowe adresy dostarczone przez Binance jako Class B. Należą one do dyskusji o blokowaniu, podczas gdy zmiany stanu w projekcie są ograniczone do adresów Class A określonych do odzyskania. Liczenie każdego zablokowanego adresu jako portfela, który zostałby opróżniony, zawyżałoby zakres. Zaciemniłoby to również ważne pytanie governance: zablokowanie transakcji to jedno działanie, podczas gdy decyzja, że określone saldo powinno trafić do wskazanego odbiorcy, to inne.

Dlaczego dwa aktywa wymagały różnych reakcji

Chronologia wniosku Polygon śledzi 46 626 589,6 natywnych POL i 6 185 900,1 USDT z gorącego portfela Binance do tego samego odbiorcy w bloku 96 406 484. Tether zamroził USDT. POL pozostał przedmiotem proponowanej interwencji sieciowej.

Proponowany transfer odnosi się do różnych mechanizmów kontroli dostępnych dla tych dwóch aktywów. Emitent może nałożyć ograniczenia poprzez system, który obsługuje dla swojego tokena. W tym przypadku producenci bloków Polygon użyli zamiast tego filtra transakcji Bor dla natywnego POL, a wniosek opisuje ten filtr jako rozwiązanie tymczasowe.

Każdy producent bloków odczytuje listę przy uruchomieniu, zgodnie z wnioskiem. Zmiany wymagają wdrożenia i restartu lub rotacji, a filtr obejmuje zewnętrznych nadawców i autoryzacje EIP-7702. Wniosek mówi, że snapshot zostanie ponownie odczytany przed aktywacją, więc jego opublikowana tabela jest odniesieniem, a nie gwarancją ostatecznych kwot obciążenia.

Dlaczego filtr transakcji może działać przez dni i nadal być tymczasowy

Lista producentów bloków opiera się na konfiguracji oprogramowania. Wniosek mówi, że lista jest odczytywana przy uruchomieniu. Nowy wpis wymaga zatem zmiany operacyjnej, a operatorzy muszą zastosować tę samą konfigurację, aby ograniczenia działały zgodnie z zamierzeniem. Wysiłek z tym związany może być uzasadniony podczas trwającego incydentu, gdy każda godzina daje osobie posiadającej klucze kolejną szansę na przeniesienie środków.

Ograniczenie na poziomie producenta musi również odpowiadać sposobowi, w jaki transakcja może zostać autoryzowana. Wniosek mówi, że filtr obejmuje zewnętrznych nadawców i autoryzacje EIP-7702. To węższe twierdzenie niż stwierdzenie, że środki stały się niemożliwe do przeniesienia jakąkolwiek wyobrażalną ścieżką transakcji. Autorzy raportują, że środki zostały zatrzymane i że nie znaleźli obejścia. Wskazują ograniczenia tego podejścia jako część argumentacji za trwalszą zmianą.

Autorzy opisują oczekującą transakcję z niezwykle wysoką proponowaną opłatą oraz próby uzyskania pomocy od walidatorów. Próba transakcji jest dowodem wysiłku zmierzającego do zmiany statusu salda. Ma ona inną wagę dowodową niż wykonany transfer. Wniosek opisuje również nieodpowiedziany kanał odzyskiwania onchain. Wynegocjowany zwrot zależałby od odpowiedzi strony zdolnej do autoryzacji płatności, podczas gdy wniosek o fork działałby poprzez uczestników przyjmujących nowe zasady.

Lista bezterminowa ma praktyczne konsekwencje dla osób nią zarządzających. Musiałyby one wiedzieć, które wpisy nadal służą celowi, w jaki sposób nowi operatorzy uzyskują prawidłową konfigurację i kto jest odpowiedzialny za przegląd starych wpisów. Wniosek na forum przewiduje przegląd po odzyskaniu, w tym odrębne postępowanie dla dodatkowych adresów. Oznacza to, że wniosek dotyczy zarówno jednorazowej zmiany salda, jak i tego, co dzieje się z tymczasowymi kontrolami wokół niej.

Co zmienia się w bloku forka

Zwykle transfer zmienia salda kont po zaakceptowaniu ważnej transakcji zgodnie z zasadami sieci. Wniosek zamiast tego prosi oprogramowanie działające według zaktualizowanych zasad o zastosowanie wymienionych obciążeń i uznania jako część przetwarzania określonego bloku.

Pasujące uznania mają znaczenie. Opisana operacja pobiera tę samą liczbę natywnych tokenów z wymienionych adresów, ile przekazuje wyznaczonym adresom odzyskiwania. Zakres nie obejmuje dowolnych tokenów w portfelach.

Blok, który zapisałby odzyskanie

Proponowana zmiana stanu jest uporządkowana wokół bloku aktywacji, który projekt nazywa F. Odpowiednia kwota to saldo po F minus jeden. Zaktualizowane węzły zastosowałyby przepisane korekty salda przed zwykłymi transakcjami w F. Ta kolejność ma znaczenie, ponieważ określa dokładną granicę, której recenzent użyłby do sprawdzenia wyniku.

Zwykły transfer zazwyczaj daje eksploratorowi wpis transakcji do wyświetlenia. Zmiana zastosowana bezpośrednio zgodnie z regułami łańcucha może być natomiast widoczna poprzez porównanie sald w sąsiednich blokach. Ktoś, kto patrzy wyłącznie na listę zwykłych transferów odbiorcy, mógłby ją przeoczyć. Proponowana publikacja skryptu weryfikacyjnego pomogłaby powiązać stan przed i po ze listą zamierzonych odbiorców.

Weryfikacja musi obejmować obie strony księgi. Szukałaby pasującego obciążenia i uznania dla każdego salda. Jeśli adres odzyskiwania otrzymałby również zwykłe transakcje w tym samym bloku, surowa różnica między dwoma migawkami mogłaby obejmować te ruchy. Recenzent musiałby wtedy oddzielić je od specjalnej zmiany stanu, zamiast traktować każdy przyrost jako odzyskane środki.

Blok aktywacji jest terminem koordynacyjnym. Operator uruchamiający oprogramowanie, które oblicza stary stan, oraz operator stosujący specjalną regułę salda mogliby obliczyć różne wyniki z tego samego bloku. Praktyczna praca obejmuje zatem publikację zmiany, danie operatorom czasu na jej przegląd i jasne określenie punktu aktywacji. Tabela w propozycji nadal oznacza blok jako decyzję do podjęcia po zatwierdzeniu. Dyskusja o zarządzaniu jest okazją do ustalenia tego planu, podczas gdy stan łańcucha ustaliłby wykonanie.

Kto sprawia, że zmiana wchodzi w życie

Propozycja na forum opisuje żądaną zmianę. Osobnym kamieniem milowym byłoby wydanie, które ją implementuje i wskazuje blok aktywacji. Operatorzy musieliby wtedy przyjąć kompatybilne oprogramowanie, aby zmiana weszła w życie w łańcuchu, którego używają.

Użytkownik śledzący propozycję powinien zatem odróżnić post na forum, implementację i blok, który faktycznie odzwierciedla nowe salda. Każdy z nich odpowiada na inne pytanie dotyczące odzyskiwania.

Praca stojąca za wyborem bloku aktywacji

Numer bloku może wyglądać jak szczegół administracyjny. W praktyce to miejsce, w którym nowe oprogramowanie i stare oprogramowanie zaczynają się nie zgadzać co do sald affected kont. Wybór tego bloku daje operatorom wspólny termin instalacji aktualizacji, a eksploratorom, dostawcom infrastruktury i affected firmom wspólny punkt, od którego można sprawdzić wynik.

Przygotowanie proponowane w poście na forum obejmuje potwierdzenie miejsc docelowych, utrzymanie ustaleń blokujących do momentu aktywacji i opublikowanie świeżej migawki sald. Te kroki dotyczą różnych sposobów, w jakie odzyskiwanie mogłoby pójść źle. Nieprawidłowo zapisany adres mógłby wysłać aktywa w niezamierzone miejsce. Niewyjaśniona zmiana salda mogłaby pozostawić czytelników porównujących wynik z nieaktualną wartością. Opóźniona aktualizacja mogłaby pozostawić operatora obliczającego stan przy użyciu starych reguł.

Każda z tych kwestii wymaga innej kontroli. W przypadku miejsca docelowego ważnym dowodem jest to, jak odbiorca wykazuje kontrolę i jak publikowany adres jest weryfikowany. W przypadku kwoty jest to saldo w końcowym punkcie odniesienia. W przypadku sieci jest to, które wersje oprogramowania faktycznie przetwarzają bloki po punkcie aktywacji. Stwierdzenie, że operatorzy wspierają odzyskiwanie, samo w sobie nie odpowiedziałoby na żadne z tych pytań implementacyjnych.

Istnieje również użyteczna kontrola po zdarzeniu. Zmiana stanu wpłynęłaby bezpośrednio na salda natywne, podczas gdy zwykła płatność dokonana w tym samym bloku mogłaby wpłynąć na tego samego odbiorcę. Różnicę sald należy zatem uzgodnić ze zwykłymi transakcjami w tym bloku. W tym miejscu przydałby się skrypt weryfikacyjny proponowany przez autorów, szczególnie gdyby identyfikował zarówno obciążenie, jak i odpowiadające mu uznanie dla każdego konta.

Gdzie klienci wchodzą w proces

Odbiorcą proponowanego transferu jest adres odzyskiwania, a nie lista kont klientów. Gdy operator kontroluje środki, kolejnym pytaniem jest, jak jego własny proces odzyskiwania i zwrotu uwzględnia je.

Istotne dowody obejmowałyby harmonogram roszczeń, instrukcje dowodzenia straty i politykę dotyczącą daty wyceny. Platforma mogła już zwrócić niektórym użytkownikom środki z innych funduszy. Jej księgowość musiałaby ustalić, gdzie w takich przypadkach trafia odzyskany POL.

Co liczy się jako zwrot klientom

Portfel odbierający to miejsce, w którym zdolność sieci do przenoszenia środków spotyka się z odpowiedzialnością organizacji za ich rozliczenie. Jeśli affected klienci zostali już zwróceni z własnych zasobów giełdy, odzyskiwanie mogłoby uzupełnić te zasoby zgodnie z obowiązującymi warunkami. Jeśli mają nieuregulowane roszczenia, dystrybucja mogłaby zamiast tego zmniejszyć kwotę, którą są winni. Oba scenariusze obejmują pieniądze trafiające na adres odzyskiwania, z różnymi konsekwencjami dla użytkowników.

Może również wystąpić niezgodność między odzyskanym aktywem a aktywem, które utracił klient. Użytkownik, którego pierwotne saldo było denominowane w dolarach lub innym tokenie, musiałby wiedzieć, czy odszkodowanie jest obliczane w jednostkach tego pierwotnego aktywa, w POL czy w pieniądzu po określonej cenie. Zmienny token może przynieść istotnie różne wyniki w zależności od tego, kiedy mierzy się konwersję.

Rozróżnienie między saldami klientów a stratami platformy jest szczególnie ważne, gdy w jednej propozycji łączy się odrębne incydenty. Tabela referencyjna przypisuje salda Polygon do poszczególnych incydentów. Nie zawiera ona wspólnej puli roszczeń ani obliczenia kwot należnych poszczególnym użytkownikom. Nawet jeśli oba zestawy sald zmieniają się w tym samym bloku aktywacji, platformy mogą mieć różne zobowiązania i mogą ogłosić różne ustalenia dotyczące płatności.

Publiczne dowody można uporządkować według tego, co każdy krok by udowodnił. Wysokość wydania i aktywacji pokazałaby, że wdrożenie jest gotowe. Stan bloku pokazałby, czy księga główna uległa zmianie. Zapisy z platformy ustaliłyby, czy odzyskane aktywa zostały rozdysponowane, zatrzymane na poczet wcześniejszych odszkodowań czy w inny sposób rozliczone. Projekt na forum określa zamierzone cele na poziomie łańcucha dla każdego incydentu i przewiduje publiczną weryfikację zmian sald.

Kto może zdecydować, ile warte jest odzyskane aktywo?

Załóżmy dla ilustracji, że platforma jest winna użytkownikowi wartość gotówkową salda i otrzymuje POL po zmianie ceny. Istnieją co najmniej trzy daty, do których platforma może się odwołać: czas kradzieży, czas, w którym uzyskuje odzyskane tokeny, oraz czas, w którym dokonuje dystrybucji. Kwota gotówki reprezentowana przez tę samą ilość POL może się różnić w każdym z tych punktów.

Polityka roszczeń mogłaby zamiast tego przewidywać płatność w jednostkach aktywa, które zostało utracone. To pozwala uniknąć wyboru ceny rynkowej dla roszczenia denominowanego w tym samym aktywie, ale nadal pozostawia pytania o kwalifikowalność i wcześniejsze zwroty. Klient, który został już spłacony, mógłby mieć inną pozycję niż ktoś, którego roszczenie pozostaje nierozstrzygnięte. Sieć nie odgrywa żadnej roli w dokonywaniu tych ustaleń.

To, czego potrzebuje klient, to oświadczenie o tym, co platforma jest winna, w jakiej jednostce i jak rozlicza wszystko, co zostało wypłacone wcześniej. Łańcuch może ustalić, że adres odzyskiwania otrzymał saldo, a platforma może uzgodnić to ze swoimi zapisami. Żaden z tych dokumentów nie wykonuje pracy drugiego. To jeden z powodów, dla których potwierdzone odzyskanie może być wiadomością, nawet jeśli nadal istnieje osobne oczekiwanie na szczegóły dystrybucji.

Porównanie raportowe może zestawić liczby obok siebie. Pierwsza to natywne POL odzyskane w wyniku zmiany stanu. Druga to kwota przypisana do roszczeń klientów lub do już dokonanych zwrotów. Trzecia to wszelkie saldo pozostające w depozycie, podczas gdy platforma rozstrzyga indywidualne przypadki. Pojedyncza liczba dolarowa wzięta z pierwszego etapu niewiele powiedziałaby czytelnikom o pozostałych dwóch.

Dlaczego wąski zakres ma znaczenie

Fork, który zmienia salda, rodzi pytanie, którego zwykła aktualizacja oprogramowania nie rodzi. Jakie fakty musiałyby zaistnieć, aby uczestnicy ponownie poparli tę interwencję?

Sama propozycja opisuje działanie jako ekstremalne i ogranicza je do wymienionych natywnych sald POL. Argument za propozycją i kwestię precedensu można oceniać na podstawie tych samych konkretnych szczegółów: zidentyfikowanych adresów, proponowanego celu i bloku, w którym salda uległyby zmianie.

Co uczyniłoby ten przypadek precedensem?

Inny projekt mógłby wskazać na podejście Polygon po kradzieży, ale okoliczności w tym projekcie są wyjątkowo konkretne. Autorzy identyfikują incydenty, wymienione konta, aktywa podlegające proponowanej zmianie i to, dokąd miałyby trafić. Opisują również, dlaczego stosowane już ograniczenie było jedynie środkiem tymczasowym. Propozycja bez tych elementów stanowiłaby inny przypadek uzasadnienia zmiany sald.

Istotną kwestią jest to, kogo trzeba przekonać i jakie informacje otrzymuje. Giełda może wiedzieć, które salda klientów zostały dotknięte, podczas gdy operatorzy potrzebują dowodów dotyczących proponowanej zmiany w łańcuchu. Użytkownik, którego środki są odzyskiwane, jest zainteresowany wynikiem. Operator oceniający propozycję musi również pomyśleć o tym, jak oceniłby przyszłe żądanie od innej strony.

Najbezpieczniejsze porównanie dotyczy faktów, które mogłoby wykazać inne żądanie. Czy potrafi zidentyfikować kwotę w konkretnym bloku? Czy potrafi powiązać te środki z uznanym incydentem? Czy potrafi zweryfikować odbiorcę i określić, co dzieje się z adresami już zablokowanymi? Te pytania wynikają bezpośrednio z opublikowanego projektu i są bardziej użyteczne niż opisywanie każdej nietypowej zmiany stanu jako równoważnej.

Propozycja pozostawiłaby niektóre z tych pytań weryfikowalnymi publicznie. Wysokość aktywacji pozwoliłaby obserwatorom zidentyfikować dokładne przejście stanu. Nazwane miejsca docelowe pozwoliłyby im prześledzić, co wydarzyło się później. Autorzy proponują również przegląd wpisów na tymczasowej liście blokad po aktywacji, w tym odmienne traktowanie dodatkowych adresów powiązanych z Binance. Ten końcowy przegląd pomógłby ustalić, które ograniczenia awaryjne pozostają w użyciu po zakończeniu odzyskiwania.

Co księga główna mogłaby potwierdzić

Gdyby propozycja została wdrożona, pierwsza kontrola porównałaby salda wymienionych adresów po obu stronach bloku rozwidlenia. Zgodne uznania wykazałyby, że księga główna zastosowała transfer zgodnie z określeniem. Dystrybucje dla klientów wymagałyby dowodów od operatorów odzyskiwania.

Obecna propozycja określa pięć adresów źródłowych i wyznaczone adresy odzyskiwania dla obu incydentów.

Które zapisy odpowiadają na które pytanie dotyczące odzyskiwania

Incydent może przechodzić przez te etapy w różnym tempie. Zamrożenie USDT dotyczy na przykład innego aktywa i mechanizmu niż proponowane rozwidlenie POL. Późniejsze ogłoszenie o środkach chronionych lub odzyskanych musiałoby określić, które aktywo zostało uwzględnione i co się z nim stało.

Salda mogą się również zmieniać między datami użytymi w raportowaniu. Propozycja, która podaje wcześniejszą migawkę, powinna zachować numer bloku, aby czytelnicy mogli odtworzyć kwotę, nawet jeśli bieżące saldo się zmieni. Gdy wynik będzie znany, porównanie bloku wykonania z opublikowaną migawką ustaliłoby, czy zwrócona kwota różni się od kwoty omówionej w propozycji.

Najważniejszym uzgodnieniem dla czytelników jest porównanie kwoty obciążonej i kwoty uznanej. Opublikowanie tej kontroli osobno dla obu incydentów pozwoliłoby porównać późniejsze relacje każdej platformy o wpływach z kwotą, nad którą faktycznie przejęła kontrolę. Pojedyncza łączna suma utrudniłaby śledzenie, które wpływy były dostępne na pokrycie których roszczeń.

Wąskie odzyskiwanie daje również platformom sposób na zakomunikowanie, co stało się z aktywami poza rozwidleniem. Kwota Polymarket w poście na forum obejmuje więcej POL niż wymieniono w proponowanej zmianie stanu. Transfer do Binance obejmował USDT, którym Tether zajął się osobno. Aktualizacja dotycząca odzyskiwania, która wskazuje odpowiednie aktywo, adres i podjęte działanie, pozwoliłaby czytelnikom uzgodnić oba incydenty bez zakładania, że wszystkie skradzione środki podążały jedną drogą.

Chronologia podaje trzy daty o różnych znaczeniach. Data incydentu ustala, kiedy środki zostały przeniesione. Blok referencyjny ustala, co zaobserwowano na adresach, gdy autorzy kompilowali propozycję. Data aktywacji, jeśli zostanie uzgodniona, ustaliłaby, kiedy sieć stosuje regułę odzyskiwania. Token może być chroniony przed określonymi transferami między tymi datami, mimo że w międzyczasie nie został zwrócony.

Zapisy adresów mogą również służyć jako kontrola oświadczeń składanych po aktualizacji. Jeśli operator twierdzi, że środki zostały wysłane na opublikowany cel, łańcuch powinien pokazywać odpowiadającą temu zmianę salda na wysokości aktywacji. Jeśli twierdzi, że klienci otrzymali zwrot, bardziej przydatnym dowodem jest zapis dystrybucji lub jasne zestawienie zwrotów. Jedno jest oświadczeniem o sieci, drugie o zobowiązaniach platformy.

Dlatego dowody z księgi są szczególnie cenne, gdy publiczna dyskusja skupia się na tym, czy fork zadziałał. Daje to obserwatorom wąskie pytanie, które mogą zweryfikować bez czekania, aż każda dotknięta firma zakończy własną księgowość. Propozycja określa procedurę publikowania sald wykorzystanych w zmianie stanu oraz sprawdzania kredytów odbiorców po niej. Te zapisy dałyby użytkownikom również punkt wyjścia do śledzenia, co każda platforma zrobiła, gdy przejęła kontrolę nad pieniędzmi.

Na co zwrócić uwagę

• Propozycja wydania: Ilości specyficzne dla incydentu, proponowane adresy odbiorców i instrukcje wykonywalne przedłożone do zarządzania.
• Blok aktywacji: Potwierdzona wysokość bloku i wersja oprogramowania, którą operatorzy Polygon musieliby zainstalować przed nim.
• Kredyty odzyskiwania: Natywny POL obciążony z każdego zablokowanego adresu i odpowiadający mu kredyt zapisany u wyznaczonego odbiorcy.
• Roszczenia klientów: Instrukcje każdej platformy dotyczące kwalifikowalności, wyceny i sposobu rozliczenia wcześniejszych zwrotów.

Najczęściej zadawane pytania