Deweloperzy Ethereum zaproponowali rozwiązanie, które da kodowi on-chain możliwość weryfikacji tego, co transakcja faktycznie zmieniła — oraz cofnięcia całej transakcji, jeśli wynik naruszy reguły określone wcześniej przez użytkownika. Koncepcja, znana jako natywne asercje transakcyjne, została wskazana przez Ethereum Foundation we wpisie na blogu opublikowanym 5 października 2026 roku.

Propozycja celuje w jeden z najstarszych i najbardziej uporczywych słabych punktów bezpieczeństwa kryptowalut: ślepe podpisywanie.

Problem ślepego podpisywania

Ślepe podpisywanie to kryptowalutowy odpowiednik akceptowania regulaminu bez jego czytania. Portfel wyświetla żądanie, szczegóły są nieczytelne lub niejasne, a użytkownik i tak je zatwierdza. Najczęściej nic złego się nie dzieje, ale gdy już się wydarzy, skutki bywają kosztowne. Słabość ta wynika ze sposobu budowy transakcji Ethereum: podpisywany ładunek to dane w formacie maszynowym, a nie zwykły język, więc to, co pojawia się na ekranie portfela, jest jedynie interpretacją tych danych przez interfejs.

Ethereum Foundation przedstawiła nową pracę jako bezśrednią odpowiedź na te ryzyka, które zostały zidentyfikowane w ramach inicjatywy Trillion Dollar Security. Program ten obejmuje już działania takie jak Clear Signing, koncentrujące się na tym, by żądania transakcyjne były zrozumiałe, zanim użytkownik je zatwierdzi.

Natywne asercje transakcyjne działają na innym etapie procesu. Clear Signing ma pomóc użytkownikom zrozumieć transakcję przed jej wykonaniem. Asercje sprawdzają natomiast, czy wynik po wykonaniu odpowiadał oczekiwaniom.

Wewnątrz EIP-7906

Technicznym rdzeniem propozycji jest EIP-7906, który wprowadza trzy nowe opkody do Ethereum Virtual Machine: TXTRACE, TXDIFF i EVENTDATACOPY. Opkody to niskopoziomowe instrukcje rozumiane przez EVM, więc dodanie nowych rozszerza możliwości kodu smart kontraktów.

W tym przypadku nowe instrukcje dają kodowi on-chain sposób na zbadanie rzeczywistych zmian stanu wywołanych przez transakcję. To przesuwa weryfikację z tego, co transakcja deklaruje, że zrobi, na to, co faktycznie zrobiła.

Jak integruje się z EIP-8141

EIP-7906 nie funkcjonuje w izolacji. Opiera się na frameworku określonym w EIP-8141, znanym jako format transakcji ramkowych. Formaty transakcji to podstawowa infrastruktura: każdy węzeł, portfel i narzędzie deweloperskie musi umieć je przetwarzać, więc zmiany na tej warstwie sięgają całego stosu.

Transakcje ramkowe dzielą pojedynczą transakcję na wyodrębnione segmenty, czyli ramki. EIP-7906 dodaje do tej struktury nowy element: ramkę POST_TX.

Ramka POST_TX działa podczas wykonania jako static call — operacja tylko do odczytu, która może badać stan, ale nie może go modyfikować. Jeśli warunki zdefiniowane w tej ramce nie zostaną spełnione, skutki transakcji mogą zostać cofnięte.

Status i harmonogram

Nic z opisanego tutaj nie jest jeszcze aktywnie wdrożone. EIP-7906 pozostaje w statusie szkicu. Zgodnie z procesem rozwoju Ethereum szkic musi przejść przegląd i uzyskać akceptację deweloperów koordynujących aktualizację, zanim jego zmiany trafią do sieci. Celem jest włączenie go do aktualizacji Hegotá, której wdrożenie jest przewidywane na 2027 rok.

Wstępne demonstracje zostały już przeprowadzone na sieci deweloperskiej, co sugeruje, że mechanizm działa nie tylko na papierze. EIP-7906 zależy również od EIP-8141, więc jego losy są związane z tym, czy format transakcjikowych również zostanie przyjęty.

Dlaczego to ma znaczenie poza kodem

Natywne asercje przeniosłyby część ciężaru ryzyka związanego z podpisywaniem na warstwę bazową. Jeśli protokół będzie mógł bezpośrednio egzekwować sprawdzenie wyniku, użytkownicy będą mniej zależni od tego, czy pojedynczy portfel idealnie opanuje swoją logikę wyświetlania.

Dla instytucji i firm atrakcyjność jest oczywista. Organizacje przenoszące duże kwoty zazwyczaj oczekują gwarancji, a nie starań na najlepsze. Mechanizm zdolny do automatycznego cofnięcia transakcji, której wynik wykracza poza zdefiniowane parametry, dobrze wpisuje się w kontrolę ryzyka, jaką te podmioty już stosują gdzie indziej.

Pozostają otwarte pytania. Deweloperzy będą musieli też rozwiązać, jak zwykli użytkownicy mają definiować reguły, którym ich transakcje muszą sprostać, ponieważ siatka bezpieczeństwa wymagająca konfiguracji na poziomie eksperckim może skończyć jako ochrona głównie ekspertów. Warstwa użyteczności zbudowana na EIP-7906 może mieć znaczenie równie duże jak same opkody.

Trzeba też rozważyć pewien kompromis. Każdy nowy opkod rozszerza obszar, który musi zostać zaimplementowany i poddany audytowi w wielu klientach Ethereum. Ulepszenia bezpieczeństwa wprowadzające nowe przypadki brzegowe muszą uzasadniać ten koszt.

Kluczowe punkty do obserwacji to: czy EIP-7906 opuści status szkicu, czy EIP-8141 znajdzie miejsce w Hegotá oraz czy po wczesnych demonstracjach odbędą się kolejne testy na sieci deweloperskiej.