Symulacja transakcji: co transakcja zrobi, zanim ją podpiszesz

Adres się zgadza. Kwota się zgadza. Sprawdziłeś jedno i drugie. A transakcja nadal nie jest tym, czym ci się wydaje.

To nie jest hipoteza. To zwyczajny kształt większości strat w kryptowalutach, w których uczestniczy osoba uważna. Nikt jej nie namówił na wysłanie pieniędzy nieznajomemu. Zatwierdziła coś, czego wszystkie widoczne części były poprawne, a konsekwencje leżały zupełnie gdzie indziej — w pozwoleniu na wydawanie tokenów, w wywołaniu kontraktu, w jednym znaku adresu, który widziała już sto razy.

Symulacja to próba zasypania tej luki: pokazania ci skutków transakcji zamiast jej zawartości, zanim twój podpis uczyni ją rzeczywistą.

Luka między tym, co miałeś na myśli, a tym, co podpisujesz

Transakcja nie jest zdaniem. Jest bajtami.

Gdy te bajty to zwykły przelew, luka między tym, co mówią, a tym, co robią, jest niewielka: adres, kwota, opłata. Gdy są wywołaniem kontraktu, luka bywa ogromna. approve wygląda jak pozwolenie. Jest stałym prawem innego adresu do przenoszenia twoich tokenów, a w standardzie ERC-20 nic w tym wywołaniu nie wymaga ograniczenia ani kwoty, ani czasu. Jedno zatwierdzenie, podpisane raz, może zostać opróżnione miesiące później.

Interfejs, na który patrzysz przy podpisywaniu, musi przetłumaczyć te bajty na zdanie. To tłumaczenie jest powierzchnią ataku. Jeśli tworzy je ten, kto chce twojego podpisu, może powiedzieć cokolwiek.

Próba generalna, nie obietnica

Symulacja oznacza wykonanie transakcji wobec bieżącego stanu łańcucha bez rozgłaszania jej i zapisanie, co się zmienia.

W SSP Enterprise dzieje się to przy tworzeniu propozycji, zanim ktokolwiek podpisze. Symulację buduje się z tego, co wyprodukował konstruktor propozycji — z odbiorców, kwot, kontraktu tokena i danych wywołania, które złożyła sama SSP — nigdy z surowego, podpisanego hexa dostarczonego przez klienta. Działa wyłącznie do odczytu. Trzy silniki obsługują różne rodziny łańcuchów:

• Łańcuchy EVM wykonują wywołanie tylko do odczytu wobec węzła i odczytują wynikające z niego zmiany sald oraz zdekodowane wywołanie.
• Łańcuchy UTXO nie potrzebują żadnego węzła. Wejścia i wyjścia są już znane, więc „przed i po" to arytmetyka na wybranych monetach, a odbiorcy są klasyfikowani jako reszta wracająca do ciebie albo naprawdę zewnętrzni.
• Solana deserializuje niepodpisaną transakcję wytworzoną przez konstruktora i uruchamia sieciowe simulateTransaction z wyłączoną weryfikacją podpisów, a następnie odczytuje z wyniku salda tokenów skarbca przed i po.

Wraca podgląd: jakie było saldo każdego aktywa przedtem, jakie będzie potem i — na EVM — czym wywołanie naprawdę jest, zdekodowane na metodę i jej argumenty.

Dwie rzeczy, którymi nie jest. Nie jest gwarancją: stan łańcucha się zmienia, a symulacja wykonana w chwili propozycji to zdjęcie łańcucha z tamtego momentu. I nie jest blokadą. To ciekawsza połowa projektu i jeszcze do niej wrócimy.

Czternaście rzeczy, o których warto wiedzieć

Podgląd, który pokazuje same liczby, wciąż każe ci samodzielnie wypatrzyć problem. Dlatego podglądowi towarzyszą ostrzeżenia — jest ich czternaście, w czterech stopniach istotności.

Zatwierdzenia — kategoria, która opróżnia najwięcej portfeli. Nieograniczone lub niedomknięte pozwolenie jest krytyczne. Każde niezerowe pozwolenie na wydatek dla adresu spoza twojej listy dozwolonych jest wysokie. A zatwierdzenie dla zwykłego konta osobowego zamiast dla kontraktu jest wysokie, bo praktycznie nie ma legalnego powodu, by to robić: to kontrakty wydają pozwolenia, nie ludzie.

Odbiorcy — oznaczany jest odbiorca, którego nie ma ani w kontaktach organizacji, ani na białej liście skarbca. Tak samo taki, do którego twój skarbiec nigdy wcześniej nie wysyłał. Żadna z tych rzeczy sama w sobie nie jest błędem. Obie warte są drugiego spojrzenia.

Ryzyko kontraktu — kontrakt docelowy o niezweryfikowanym źródle, wdrożony w ciągu ostatnich siedmiu dni, natywna wartość wysyłana do kontraktu w ogóle oraz każdy adres, który dostawca oznacza jako wprost złośliwy.

Wykonanie — transakcja cofająca się w symulacji, co znaczy, że zawiedzie w łańcuchu i zmarnuje opłatę. Albo symulowany odpływ niezgodny z kwotami deklarowanymi przez propozycję: skarbiec traci więcej albo mniej, niż mówi ekran.

Degradacja — i, wyraźnie opisany, przypadek, w którym symulacja nie mogła się wykonać. Nieosiągalny węzeł daje „niedostępne", a nie ciszę i nie zmyślone świadectwo zdrowia.

Rozróżnienie między tymi stopniami znaczy więcej niż ich liczba. Krytyczny i wysoki mówią o transakcji, która najpewniej nie jest tym, na co wygląda. Średni i informacyjny mówią o transakcji nietypowej, a legalne transakcje bywają nietypowe.

Zatruwanie adresów: atak, który pokonuje ludzi uważnych

Jedno ostrzeżenie zasługuje na własną sekcję, bo celuje dokładnie w nawyk, który zaleca większość porad bezpieczeństwa.

Zatruwanie adresów działa tak. Atakujący wysyła do twojego skarbca maleńką lub zerową transakcję z adresu spreparowanego tak, by dzielił pierwsze sześć i ostatnie cztery znaki z adresem, z którym już masz do czynienia. Nic nie zostaje skradzione. Nic właściwie nie zostaje nawet zrobione. Transakcja istnieje po to, by łudząco podobny adres pojawił się w twojej historii.

Później — dni później, gdy znów płacisz temu samemu kontrahentowi — kopiujesz adres z własnej historii transakcji, tak jak robią ludzie uważni, zamiast przepisywać go ręcznie. Sprawdzasz go tak, jak sprawdzają ludzie uważni: kilka pierwszych znaków, kilka ostatnich. Oba się zgadzają. Środek nie, a środek jest tym, dokąd idą pieniądze.

SSP porównuje każdego odbiorcę propozycji z adresami, które twój skarbiec już zna, dokładnie tym porównaniem prefiksu i sufiksu, które wykonuje ludzkie oko, i podnosi krytyczne ostrzeżenie z nazwą podszywanego adresu. Ta sama kontrola działa w drugą stronę na historii przychodzącej, więc zatruty adres jest oznaczany już przy nadejściu, a nie dopiero wtedy, gdy masz go użyć.

Powód, by znać ten atak, nawet jeśli nigdy nie użyjesz SSP: nawyk weryfikacji, który zatrzymuje każdy inny atak na adres, jest właśnie tym, który ten atak ma pokonać. Porównuj całe adresy albo nie porównuj nic.

Dlaczego ostrzeżenia liczy serwer — i dlaczego mimo to niczego nie blokują

Zestaw ostrzeżeń ustala się po stronie serwera, biorąc kontakty organizacji i białą listę skarbca jako źródło prawdy. To celowe: gdyby o tym, co uchodzi za dozwolone, decydował klient, przejęty klient mógłby po cichu uznać, że dozwolone jest wszystko.

A mimo to nic z tego nie może zatrzymać transakcji. Symulacja nigdy nie warunkuje podpisu ani rozgłoszenia. Dostawca, który zwróci błąd, przekroczy czas albo nie dosięgnie węzła, zwraca „niedostępne", a propozycja pozostaje w pełni podpisywalna. Cały podsystem jest odizolowany na wypadek awarii, żeby awaria podglądu nigdy nie mogła osadzić propozycji na mieliźnie.

Zabrzmi to jak dziwny wybór, więc warto wyłożyć rozumowanie wprost. Podgląd, który może blokować, to podgląd, który da się zmusić do blokowania — przez powalenie węzła, przez wyprodukowanie fałszywego krytycznego, przez którykolwiek z tysiąca sposobów, na jakie psuje się oprogramowanie. Środki, które nie mogą się ruszyć, bo usługa doradcza choruje, to środki częściowo utracone. To próg w multisigu chroni pieniądze; symulacja jest po to, by poinformować ludzi trzymających klucze. Co naprawdę zatrzymuje transakcję to długa wersja tego argumentu.

Gdy serwer i twoje urządzenie się nie zgadzają

Wszystko powyżej to odczyt serwera. Twoje urządzenie robi własny.

Gdy SSP Wallet pokazuje ci propozycję do podpisu, sam dekoduje bajty i wyświetla to, co on znalazł — nie streszczenie serwera. Potem porównuje jedno z drugim. Jeśli zdekodowane przez serwer wywołanie implikuje inny zbiór odbiorców niż ten, który wyprowadziło urządzenie, urządzenie podnosi własne krytyczne ostrzeżenie o rozbieżności i wizualnie degraduje podgląd serwera.

Dekodowanie urządzenia jest rozstrzygające. Kontrola jest celowo zachowawcza: brakująca lub oczekująca symulacja serwera to degradacja, a nie sprzeczność, i nie jest jako sprzeczność zgłaszana. Dotyczy też wyłącznie łańcuchów EVM, gdzie serwer w ogóle produkuje zdekodowane wywołanie; na łańcuchach UTXO nie ma z czym porównywać i własne dekodowanie urządzenia po prostu stoi samo.

To właśnie ta własność jest warta zapamiętania, niezależnie od portfela. Druga opinia jest coś warta tylko wtedy, gdy pochodzi z miejsca, którego nie mógł przejąć ten sam czyn, co pierwsze. Dwa streszczenia z tego samego serwera to jedno streszczenie.

Jak czytać pasek ryzyka, nie ucząc się go ignorować

Ostrzeżenia działają dopóty, dopóki nie staną się tapetą. Kilka nawyków utrzymuje je w formie.

Najpierw czytaj istotność, potem szczegół. Krytyczne i wysokie są warte zatrzymania się. Ostrzeżenie średnie albo informacyjne przy pierwszej płatności do nowego dostawcy to system działający poprawnie, a nie powód do niepokoju.

Każde ostrzeżenie o zatwierdzeniu traktuj jako pełne zatrzymanie. Przelewy przenoszą to, co deklarują. Zatwierdzenia przyznają prawo, które przeżywa transakcję. Jeśli nie zamierzałeś dawać stałego pozwolenia, odpowiedź brzmi nie.

Wierz urządzeniu bardziej niż ekranowi. Jeśli oba się rozchodzą, telefon w twojej dłoni jest tym, który działa na sprzęcie, który atakujący musiałby przejąć osobno.

Nie czytaj „niedostępne" jako „w porządku". To znaczy, że nikt nie sprawdził. To powód, byś sam przyjrzał się uważniej, zwłaszcza przy dużej albo nietypowej płatności.

Wszystko tutaj dotyczy chwili przed podpisem. O tym, co dzieje się potem — kto może podpisywać, ilu podpisów trzeba i które operacje znów żądają obu urządzeń — zacznij od konfigurowania pierwszego skarbca firmowego i działań krytycznych oraz ponownego podpisu. A jeśli chodzi o wzorce ataków, wokół których te ostrzeżenia są ukształtowane, ataki phishingowe wymierzone w użytkowników kryptowalut obejmują ludzką połowę problemu.