EIP-7702 pozwala zwykłemu adresowi Ethereum delegować swoje zachowanie do kodu smart-kontraktów bez przenoszenia aktywów na nowy adres portfela. Aktywowany wraz z aktualizacją Pectra w maju 2026 roku, może obsługiwać działania grupowe, sponsorowane gazy, uprawnienia do sesji oraz projekty portfeli nastawione na odzyskiwanie. Ta sama moc sprawia, że nieznany podpis delegacji jest wyjątkowo niebezpieczny.
Szybka odpowiedź: EIP-7702 dodaje nowy typ transakcji, dzięki któremu konto zewnętrzne (EOA) autoryzuje wskaźnik do wdrożonego kodu. Adres i klucz prywatny pozostają, ale połączenia do konta mogą podążać za delegowaną logiką. Używaj tylko tych implementacji zarządzanych portfelem, które zweryfikowałeś; złośliwy kod delegowany może kontrolować każdy zasób na tym adresie.
EOA i konta smart-kontraktów
Historycznie większość użytkowników Ethereum prowadziła EOA kontrolowany jednym kluczem prywatnym. Jej reguły walidacji były ustalone przez protokół: ważna transakcja wymagała podpisu klucza, nonce oraz ETH dla gas. Konta inteligentne mogą implementować bardziej rozbudowane reguły, ale zazwyczaj wymagają wdrożenia i innego adresu.
EIP-7702 tworzy ścieżkę hybrydową. EOA podpisuje autoryzację, która wskazuje konto na kod już wdrożony na łańcuchu. Ethereum traktuje wtedy konto jako posiadające mały kodowy oznacznik, który deleguje wykonanie tej implementacji.
Klucz prywatny nie znika. Ethereum.org wyraźnie podkreśla, że klucz zachowuje pełną kontrolę po delegacji. Delegowanie do kodu w stylu multisig nie eliminuje więc oryginalnej autorytetu pojedynczego klucza.
Jak działa autoryzacja EIP-7702
Nowa transakcja typu 4 zawiera listę autoryzacji. Na wysokim poziomie autoryzacja obejmuje:
- identyfikator łańcucha;
- adres wdrożonego kodu delegacji;
- konto nonce, aby zapobiec powtórce; oraz
- podpis z EOA jest autoryzowany.
ID łańcucha może powiązać autoryzację z jednym łańcuchem. Wartość zero może sprawić, że będzie ważny dla wszystkich identyfikatorów łańcuchów, co wymaga szczególnej ostrożności. Właściciel konta może zresetować delegację, delegując ją do adresu null, ale usunięcie nie jest automatyczne tylko dlatego, że jedna sesja dApp się kończy.
Użytkownicy nie powinni potrzebować rozumienia surowych krotek autoryzacyjnych w normalnym użyciu. Bezpieczny portfel powinien jasno wyjaśniać cel delegacji oraz żądaną funkcjonalność.
Co umożliwia EIP-7702
Grupowanie transakcji
Portfel może łączyć powiązane działania, takie jak zatwierdzenie tokena i jego użycie, w jeden przepływ użytkownika. Grupowanie atomowe może zapobiec nieukończonej sekwencji, w której zatwierdzenie się powiodło, ale zamierzona akcja nie.
Sponsorowana opłata za gaz i alternatywne opłaty
Relayerzy i paymasterzy mogą sponsorować transakcję lub zaakceptować opłatę z innym tokenem. Może to zmniejszyć potrzebę, by nowy użytkownik pobierał niewielką ilość ETH przed interakcją. Sponsoring nadal wiąże się z kosztami i wprowadza zależności od infrastruktury i polityki.
Klucze sesji i ograniczone uprawnienia
Logika konta delegowanego może autoryzować tymczasowy klucz dla ograniczonej akcji, kwoty, aplikacji lub czasu. To może poprawić grę i powtarzające się interakcje, unikając podpisu klucza podstawowego przy każdym kliknięciu. Bezpieczeństwo zależy od tego, czy implementacja prawidłowo egzekwuje te limity.
Odzyskiwanie i walidacja modularna
Oprogramowanie portfelowe może budować moduły odzyskiwania lub alternatywnego podpisu wokół kodu delegowanego. Jednak ponieważ oryginalny klucz prywatny EOA zachowuje kontrolę na poziomie protokołu, użytkownicy muszą zrozumieć, czy dana funkcja stanowi prawdziwą ochronę przed utratą klucza, wygodę warstwy aplikacji, czy jedno i drugie.
EIP-7702 i ERC-4337
EIP-7702 to funkcja protokołu umożliwiająca przypisanie delegowanego zachowania do EOA. ERC-4337 to system abstrakcji kont oparty na UserOperation obiekty, bundlery, kontrakt EntryPoint oraz opcjonalni paymasterzy. Mogą współpracować.
Wytyczne implementacyjne Ethereum zalecają kompatybilność z infrastrukturą ERC-4337 tam, gdzie jest to stosowne. Portfel może używać EIP-7702 do programowania istniejącego adresu oraz używać bundlerów ERC-4337 do przekazywania operacji lub sponsorowania gazu.
Główne zagrożenia bezpieczeństwa
Złośliwa delegacja
Kod delegacji staje się w praktyce rozszerzeniem konta. Jeśli zawiera złośliwą logikę, atakujący może być w stanie przenieść tokeny i NFT. Traktuj autoryzację delegacji jako decyzję o dużym wpływie bezpieczeństwa, a nie jako rutynowy podpis logowania.
Ryzyko wdrażania podlegające aktualizacji
Jeśli można zaktualizować wyznaczony cel lub jego zależności, zachowania przeanalizowane dzisiaj mogą się później zmienić. Wzorce proxy mogą zapewniać utrzymanie i modułowość, ale jednocześnie budzą zaufanie administratorom aktualizacji. Kod niezmienny zmniejsza ryzyko tej formy, ale nie można go załatać, jeśli zostanie znaleziona wada. Portfele muszą jasno określać ten kompromis.
Ataki inicjalizacyjne
Logika konta delegowanego może wymagać ustawień początkowych. Jeśli inicjalizacja nie jest powiązana z parametrami podpisanymi przez użytkownika, inna strona może próbować najpierw zainicjować konto lub zmienić konfigurację krytyczną. Oficjalne wytyczne omawiają inicjalizację uwarunkowaną podpisem oraz ograniczone połączenia EntryPoint jako środki łagodzące dla deweloperów.
Kolizje pamięci
Zmiana delegowanych implementacji nie usuwa automatycznie przechowywania konta. Nowy kod może inaczej interpretować stary slot pamięci, co powoduje nieoczekiwane zachowania. To ryzyko związane z projektowaniem i ulepszeniem, którego użytkownicy nie mogą łatwo sprawdzić z poziomu portfela.
Powtórki międzyłańcuchowe i założenia dotyczące adresowania
Autoryzacja o szerokim zakresie może stwarzać ryzyko dla wielu łańcuchów EVM, zwłaszcza jeśli kod na tym samym adresie się różni. Twórcy smart-kontraktów muszą również przestać zakładać, że tx.origin zawsze oznacza EOA wolne od kodu, ponieważ EOA może teraz wykonywać kod delegowany.
Lista kontrolna bezpieczeństwa użytkownika
- Utrzymuj oprogramowanie portfela aktualne. Stare interfejsy mogą słabo wyświetlać nowe typy autoryzacji.
- Niech portfel zarządza delegowaniem. Ethereum.org zauważa, że dApps powinny korzystać ze standaryzowanych interfejsów portfeli, zamiast prosić użytkowników o arbitralne surowe autoryzacje EIP-7702.
- Zweryfikowaj umowę docelową. Porównaj dokładny adres z oficjalną dokumentacją dostawcy portfela.
- Sprawdź lunetę łańcuchową. Zrozum, czy autoryzacja jest ograniczona do jednego łańcucha.
- Przeczytaj każdą umiejętność. Uprawnienia do grupowania, wydawania, sesji, odzyskiwania i aktualizacji nie są równoważne.
- Odrzuć pilność. Częste są wzorce wyrzutów lub wsparcia wymagające natychmiastowej delegacji.
- Stosuj zabezpieczenia sprzętowe i portfelowe. Oficjalne wytyczne zalecają, aby portfele sprzętowe unikały ujawniania arbitralnych delegacji i dokładnie przeglądały wspierane kontrakty.
- Wiedz, jak usunąć delegowanie. Postępuj zgodnie z oficjalnym procesem portfela i później weryfikuj kod konta w łańcuchu.
Aby poznać ogólną sieć sieci, przeczytaj nasze Przewodnik po Ethereum. EIP-7702 nie zastępuje podstawowej higieny zasiłków; kontynuuj Przeglądaj zatwierdzenia tokenów Po użyciu dApp.
Najczęściej zadawane pytania
Czy EIP-7702 zmienia mój adres Ethereum?
Nie. Istniejący adres deleguje zachowanie kodowi. Aktywa mogą pozostać pod tym samym adresem.
Czy delegacja usuwa kontrolę nad kluczem prywatnym?
Nie. Klucz EOA zachowuje kontrolę na poziomie protokołu. Logika specyficzna dla portfela może dodawać polityki, ale użytkownicy nie powinni zakładać, że przekształca adres w czystą multisig.
Czy delegacja EIP-7702 jest stała?
Pozostaje do momentu zmiany lub resetu; Nie jest usuwana przez odłączenie strony internetowej. Konto może ponownie delegować, także na adres null, aby zresetować wskaźnik.
Czy EIP-7702 to to samo co ERC-4337?
Nie. To różne mechanizmy, które można łączyć. EIP-7702 to funkcja delegacji na poziomie protokołu; ERC-4337 definiuje infrastrukturę abstrakcji rachunków wyższych warstw.
Ten artykuł odzwierciedla publiczną dokumentację Ethereum przejrzaną 31 lipca 2026 roku. Implementacje portfeli różnią się, a kod inteligentnych kont może niesć ze sobą krytyczne ryzyka.