Ethereum Foundation analizuje asercje transakcji, które pozwoliłyby użytkownikom dołączać do transakcji egzekwowalne warunki dotyczące jej końcowego rezultatu, zamiast polegać wyłącznie na zatwierdzeniu żądanego działania. Badania, prowadzone w ramach inicjatywy Trillion Dollar Security, dotyczą luki w bezpieczeństwie transakcji: prawidłowy podpis nie gwarantuje, że salda, uprawnienia lub kontrola nad kontem po transakcji będą zgodne z intencją podpisującego.
Najważniejsze wnioski
- Proponowane kontrole oceniałyby rezultaty transakcji podczas jej wykonywania i cofały działania naruszające podpisaną regułę.
- Ochrona zależy od reguł zatwierdzonych niezależnie od potencjalnie przejętego narzędzia do tworzenia transakcji.
- Badania mogą wesprzeć polityki bezpieczeństwa portfeli, delegowanych agentów i procesy solverów, ale nie ogłoszono wdrożenia tego rozwiązania.
Spis treści
- Dlaczego zatwierdzenie transakcji nadal może prowadzić do strat
- Jak asercje transakcji sprawdzałyby rezultat
- Jakie informacje udostępniałaby proponowana implementacja
- Jakie zmiany byłyby potrzebne w portfelach i protokołach
- Co mogłyby zyskać agenty i procesy solverów
- Podsumowanie
Dlaczego zatwierdzenie transakcji nadal może prowadzić do strat
Ethereum wykonuje żądanie autoryzowane przez użytkownika z uwzględnieniem kodu i stanu dostępnych w chwili realizacji. Warunki te mogą różnić się od tych, które użytkownik sprawdził. Na przykład implementacja proxy może ulec zmianie przed wykonaniem transakcji, a kolejność transakcji może wpłynąć na cenę uzyskaną przy wymianie.
Fundacja rozróżnia wprowadzające w błąd żądania od niepożądanych rezultatów. W atakach na Bybit i BadgerDAO przejęte interfejsy frontendowe wyświetlały żądania podpisu różniące się od tego, co użytkownicy sądzili, że zatwierdzają. Z kolei nawet prawidłowo wyświetlone żądanie może dopuszczać rezultat niekorzystny ekonomicznie.
Przykładem jest wymiana zabezpieczenia Aave i CoW obejmująca około 50,4 mln dolarów w aEthUSDT. Niewielka płynność AAVE i limit gazu CoW sprawiły, że zweryfikowana oferta wynosiła około 329 aEthAAVE. Mimo wyświetlonego ostrzeżenia o wpływie na cenę na poziomie 99,9% oraz potwierdzenia, że można stracić całą wartość, użytkownik podpisał transakcję i otrzymał tokeny warte około 36 000 dolarów.
To rozróżnienie wyjaśnia, dlaczego lepsze opisy transakcji nie rozwiązują całego problemu. Clear Signing pomaga użytkownikom zrozumieć żądane działanie. Symulacja szacuje skutki w odniesieniu do wybranego stanu łańcucha. Żadne z tych rozwiązań samo w sobie nie narzuca niezależnego warunku dotyczącego rzeczywistego rezultatu.
| Element | Szczegóły |
|---|---|
| TXTRACE | Wymienia łączne zmiany stanu transakcji i wygenerowane zdarzenia. |
| TXDIFF | Pobiera wartości początkowe i końcowe dla wskazanych adresów i slotów pamięci. |
| EVENTDATACOPY | Kopiuje dane zdarzenia do pamięci w celu ich sprawdzenia. |
| Informacje o wdrożeniu | Proponowane dane o zmianach stanu obejmują nowo wdrożone kontrakty i skróty ich kodu. |
Jak asercje transakcji sprawdzałyby rezultat
Asercja porównywałaby stan początkowy i końcowy transakcji za pomocą logiki tylko do odczytu, uruchamianej po wykonaniu jej działań. Warunek byłby uwzględniany w transakcji i podpisywany wraz z działaniami. Jego niespełnienie powodowałoby cofnięcie tych działań.
Możliwe reguły obejmują minimalną otrzymaną kwotę, limit wydatków, ograniczenia dotyczące nowych zezwoleń na tokeny lub zachowanie mechanizmu kontroli nad kontem. Proponowane możliwości inspekcji wykraczają poza salda i obejmują pamięć, kod, nowo wdrożone kontrakty oraz wygenerowane zdarzenia.
Istniejące kontrole kontraktowe już chronią wybrane rezultaty. Uniswap może odrzucać wymiany, których wynik jest niższy od określonej minimalnej wartości, a mechanizm guard w Safe może sprawdzać stan konta po wykonaniu transakcji. Ograniczeniem jest widoczność: takie kontrole muszą z góry przewidywać, co należy sprawdzić, i zazwyczaj zależą od interfejsów udostępnianych przez inne kontrakty. Proxy nie musi na przykład udostępniać funkcji ujawniającej adres jego implementacji.
Natywne asercje udostępniałyby do sprawdzenia pełne łączne skutki transakcji, w tym zmiany, których zwykły mechanizm guard mógłby nie przewidzieć. Szerszy wgląd jest jednak przydatny tylko wtedy, gdy reguła jest wiarygodna. Złośliwy interfejs frontendowy mógłby dostarczyć warunek dopuszczający własny atak, dlatego polityka musi wynikać z niezależnie zatwierdzonej intencji, polityki konta lub chronionej logiki protokołu.
Jakie informacje udostępniałaby proponowana implementacja
Ogłoszenie Ethereum Foundation dotyczące natywnych asercji transakcji przedstawia EIP-7906 jako możliwą implementację, a nie ustalony projekt. Rozwiązanie opiera się na transakcjach ramowych z EIP-8141, które porządkują kroki walidacji i działania. EIP-8141 zaplanowano na Hegotá; EIP-7906 otrzymał status „Considered for Inclusion”, ale nie potwierdzono jego uwzględnienia w tej aktualizacji.
W tym podejściu ramka POST_TX działająca wyłącznie w trybie odczytu sprawdzałaby rezultaty na końcu wykonania. Proponowane instrukcje dostępu do danych działałyby wyłącznie w tej ramce, a nie w całej maszynie EVM.
Informacje opisywałyby łączne skutki, a nie historię każdej pośredniej zmiany zapisu. Slot pamięci zmieniany wielokrotnie byłby przedstawiony za pomocą wartości początkowej i końcowej; slot przywrócony do pierwotnej wartości nie zostałby uwzględniony. Dlatego istotne jest rozróżnienie między egzekwowaniem warunków dotyczących stanu końcowego a monitorowaniem każdego etapu wykonania.
W razie niespełnienia warunku wykonanie transakcji zostałoby cofnięte, ale sama transakcja pozostałaby w bloku jako nieudana. Podmiot opłacający gaz nadal ponosiłby koszt zużytego gazu, co zapobiegałoby narzucaniu twórcom bloków bezpłatnej pracy przez celowo nieudane transakcje.
Jakie zmiany byłyby potrzebne w portfelach i protokołach
Propozycja zapewnia mechanizm kontroli, a nie automatyczny obowiązek jego użycia. W przypadku transakcji użytkownika portfel musiałby uwzględniać swoją politykę bezpieczeństwa podczas tworzenia transakcji, zamiast pozwalać narzędziu do jej budowania na pominięcie tej polityki. Zasady mogłyby wynikać z własnej symulacji portfela lub obowiązywać jako stała reguła konta.
W przypadku protokołów ochronę należałoby wbudować w warunki dostępu do chronionej funkcji. Samo dostarczenie transakcji obsługującej asercje nie wystarczyłoby: wywołanie musiałoby zawierać konkretną kontrolę wymaganą przez protokół. Zmieniłoby to wymagania integracyjne wobec wywołujących, natomiast wdrożonych już niezmiennych kontraktów nie dałoby się dostosować do egzekwowania takiego warunku dostępu.
Zależności te pokazują różnicę między potencjalnie potężną funkcją EVM a gwarancją dla użytkownika. Skuteczna ochrona wymagałaby zarówno poprawnego warunku, jak i oprogramowania, które konsekwentnie uniemożliwiałoby jego pominięcie.
Co mogłyby zyskać agenty i procesy solverów
Delegowanych agentów można byłoby ograniczać nie tylko przez uprawnienia, lecz także przez rezultaty ich działań. Limity dotyczące kontraktów, z których agent może korzystać, lub kwoty, jaką może wydać, mogłyby zostać uzupełnione wymaganiami określającymi stan pozostawiony po każdej transakcji.
W przypadku realizacji opartej na solverach protokół mógłby określić akceptowalny rezultat, pozostawiając solverowi wybór ścieżki. Gwarancja ograniczałaby się do transakcji w jednej sieci, a nie do ścieżki obejmującej wiele łańcuchów.
Asercje mogłyby również weryfikować porządkowanie procesu, na przykład zwrot niewykorzystanych tokenów i cofnięcie pozostałych zezwoleń. Fundacja zbiera opinie zespołów portfeli i protokołów w miarę dalszych prac nad projektem, dlatego są to potencjalne kierunki badań, a nie zapowiedziane funkcje produktu.
Podsumowanie
Natywne asercje transakcji przeniosłyby część odpowiedzialności za bezpieczeństwo transakcji Ethereum z interpretacji żądania na egzekwowanie jego rezultatu. Ich praktyczna wartość zależałaby od wiarygodnych polityk oraz od ich wdrożenia przez portfele i protokoły odpowiedzialne za ich stosowanie.
Czytaj więcej wiadomości
Więcej wiadomości FinanceVelix
Zastrzeżenie
Ten artykuł FinanceVelix zawiera ogólne informacje, a nie spersonalizowane porady finansowe, inwestycyjne, prawne ani podatkowe. Ceny kryptowalut mogą szybko się zmieniać, a zainwestowane środki można stracić w całości. Przedstawione fakty odzwierciedlają informacje dostępne w chwili publikacji i mogą ulec zmianie. Ważne informacje należy niezależnie zweryfikować, a w razie potrzeby skonsultować się z wykwalifikowanym specjalistą. Wzmianka o aktywie, firmie lub usłudze nie stanowi rekomendacji.
