EIP-7702: delegowanie kodu EOA i ryzyka

Zwykłe EOA podpisuje transakcje kluczem prywatnym i nie ma kodu pod własnym adresem. EIP-7702 pozwala wskazać kod wdrożony gdzie indziej i uruchamiać go w kontekście konta. Adres, saldo i pamięć pozostają powiązane z EOA. Nie jest to migracja do nowego kontraktu ani wymiana klucza.

Specyfikacja EIP-7702 definiuje transakcję set-code typu 4 i listę autoryzacji; przewodnik Pectra w Ethereum.org opisuje wskaźnik do wdrożonego kodu. Etykieta „smart account” nie wyjaśnia zasad walidacji ani odzyskiwania dostępu. Sprawdź, kto kontroluje kod, może go aktualizować i jak wpływa on na aktywa oraz pamięć konta.

Transakcję set-code identyfikuje bajt 0x04. Każdy wpis listy autoryzacji zawiera identyfikator łańcucha, adres kodu, nonce konta autoryzującego i jego podpis. Konto autoryzujące podpisuje wpis; nadawca osobno podpisuje transakcję zewnętrzną. Role mogą należeć do różnych kont.

Identyfikator łańcucha zwykle ogranicza autoryzację do jednej sieci. Wartość 0 pozwala na szerszy zakres na łańcuchach obsługujących EIP-7702, ale nie gwarantuje powodzenia: nonce i stan konta nadal muszą pasować. Sprawdź sieć, konto i pełny adres celu w podglądzie podpisu. Błędny nonce może sprawić, że wpis zostanie pominięty.

Dokumentacja transakcji Ethereum.org wymienia listę autoryzacji typu 4. Transakcja zewnętrzna nadal ma warunki gasu i płatnika. Type 4 różni się od ERC-4337-UserOperations i paymasterów opisanych w przewodniku po smart accountach.

Znacznik składa się z prefiksu 0xef0100 i adresu celu. Klient rozpoznaje go i ładuje kod docelowy podczas wykonania; adres konta i adres kodu są różne. Kod pochodzi z bieżącego łańcucha, a ten sam adres może mieć na różnych sieciach inny kod lub nie mieć go wcale.

Kod działa w kontekście EOA i może używać jego pamięci, wysyłać ETH lub tokeny, wywoływać inne kontrakty i zmieniać stan. EIP-7702 sam nie ogranicza go do jednego tokenu ani określonej liczby działań. Jeśli celem jest proxy, sprawdź administratora, uprawnienia aktualizacji i procedurę zmiany kodu.

Błąd kontroli może pozwolić na transfery, zgody tokenów, dowolne wywołania lub zmiany pamięci. Uwagi bezpieczeństwa EIP wskazują, że delegowany kod może wiązać z podpisem ochronę przed powtórzeniem, cel, calldata, wartość ETH i warunki gasu. Bez tych danych sponsor może przesłać inne wywołanie albo doprowadzić do błędu.

Sprawdź walidację podpisów, wywoływane kontrakty, administratorów awaryjnych i aktualizacji oraz zgodność kodu ze zweryfikowanym źródłem. Przy operacjach łączonych, takich jak zgoda i wymiana, sprawdź oba wywołania i ogranicz zgodę do potrzebnej kwoty. Sama odznaka audytu nie potwierdza, że sprawdzono dokładnie adres i wersję z twojej prośby.

Lista autoryzacji jest przetwarzana przed wykonaniem transakcji zewnętrznej. Według specyfikacji znaczniki już przetworzone nie są cofane, gdy wykonanie później zawiedzie lub nastąpi revert. Dlatego komunikat o błędzie nie gwarantuje powrotu konta do poprzedniego stanu. Sprawdź potwierdzenie i aktualny kod konta oddzielnie.

Autoryzacja może się powieść, a późniejsze wywołanie inicjalizacyjne zawieść, pozostawiając aktywną delegację. Sprawdź hash transakcji, konto autoryzujące, nonce i wskaźnik kodu przed ponowieniem; nonce może się zmienić i unieważnić wcześniejszy podpis.

Nowa autoryzacja może wskazać inny kod; autoryzacja adresu zerowego usuwa znacznik i pozostawia pusty kod konta. Nie kasuje jednak pamięci konta, zgód zapisanych w kontraktach ERC-20, wykonanych transferów ani zmian w zewnętrznych kontraktach. Allowance tokenu trzeba sprawdzić i w razie potrzeby cofnąć osobno.

Nowy kod może inaczej interpretować pamięć pozostawioną przez poprzedni. Sprawdź układ pamięci i plan migracji. W sprawie zgód przeczytaj przewodnik po approvals i allowance; przy ujawnionym kluczu skorzystaj z przewodnika odzyskiwania portfela, bo usunięcie kodu nie odzyskuje klucza.

Potwierdź w dokumentacji portfela obsługę EIP-7702 na wybranej sieci. Sprawdź identyfikator łańcucha, konto, adres celu, zweryfikowany kod i administratora proxy. Odróżnij podpis autoryzacji od nadawcy i płatnika transakcji zewnętrznej; sponsorowanie nie czyni kodu bezpiecznym.

Jeśli delegacja już działa, sprawdź aktualny znacznik i adres kodu, a nie tylko status transakcji. Przy niezgodności wstrzymaj dalsze wywołania i zgody. Mechanikę opłat omawia przewodnik po gasie Ethereum, a nonce i transakcje oczekujące — przewodnik po transakcjach oczekujących.

EIP-7702 standaryzuje połączenie EOA z wdrożonym kodem. Grupowanie, sponsorowanie opłat, uprawnienia sesji i odzyskiwanie zależą od konkretnego kodu i usług, a nie od gwarancji protokołu. Ogłoszenie Pectra mainnet Ethereum Foundation opisuje możliwość zamiany lub cofnięcia autoryzacji. ERC-4337 to odrębny mechanizm.

Etykieta „smart account” nie wskazuje, kto ma klucz lub może zmienić kod i odzyskiwanie. Sprawdź konfigurację i wsparcie portfela przed zmianą konta z aktywami. Ten przewodnik opisuje mechanikę i nie poleca konkretnego portfela ani delegata.