Kryptocenter – miejsce, gdzie znajdziesz wszystko, czego potrzebujesz, by zrozumieć kryptowaluty

Krypto Center
Ethereum (ETH) & Smart-contracty

ERC‑7702 kontra ERC‑4337: portfele bez seedów i „intencje” transakcyjne – cicha rewolucja UX w Ethereum i DeFi

Patryk

ERC‑7702 kontra ERC‑4337: portfele bez seedów i „intencje” transakcyjne – cicha rewolucja UX w Ethereum i DeFi

Czy portfele bez seedów, logowanie passkey i transakcje sponsorowane staną się domyślnym standardem? Wokół propozycji ERC‑7702 wyrosła nowa fala narzędzi AA (Account Abstraction), która może skrócić dystans między Web2 a Web3. W tym artykule krok po kroku wyjaśniamy, jak 7702 różni się od ERC‑4337 i historycznego EIP‑3074, co to oznacza dla DeFi, NFT, giełd, bezpieczeństwa i regulacji – oraz jak już dziś testować nowe możliwości.

Dlaczego klasyczne portfele (EOA) hamują adopcję

Standardowe konta EOA (Externally Owned Account) wymagają seeda, płacenia opłat własnym gazem i mają ograniczoną logikę bezpieczeństwa. To powoduje bariery:

  • UX: onboarding przez seed i frazę 12/24 słów zniechęca nowych użytkowników.
  • Opłaty: brak natywnego gas sponsorship – trudno o „klik i gotowe”.
  • Funkcje: brak wbudowanego social recovery, limitów wydatków, sesji czy reguł podpisów.

Account Abstraction (AA) rozwiązuje to, przenosząc walidację transakcji do kodu smart‑portfela. Najbardziej znany standard to ERC‑4337 (mempool użytkownika, bundlery, paymasterzy). ERC‑7702 proponuje inny, bliższy protokołowi sposób, by tymczasowo nadać kontu EOA możliwości inteligentnego portfela – bez trwałej migracji.

Jak działa ERC‑7702 – w praktyce, w 7 krokach

  1. Użytkownik w portfelu wybiera akcję (np. „Zamień 500 USDC na ETH na DEX”).
  2. Portfel formułuje intencję i zestaw reguł (limit kwoty, ważność, adresy dApps).
  3. EOA podpisuje autoryzację (np. EIP‑712) pozwalając w tej transakcji użyć logiki smart‑portfela.
  4. Węzeł/bundler tworzy transakcję, która niesie tę autoryzację oraz odniesienie do kodu walidacji portfela.
  5. Walidacja dzieje się w oparciu o reguły kontraktu (limity, listy dozwolonych celów, sponsor opłat).
  6. Wykonanie akcji (np. swap) jest atomowe – wszystko albo nic, w ramach jednej intencji.
  7. Po zakończeniu, EOA wraca do normalnego trybu – brak trwałego przeprogramowania konta.

Efekt: użytkownik może korzystać z passkey, limitów wydatków, sesji, paymasterów i innych funkcji smart‑portfeli, nadal posiadając swoje klasyczne EOA.

ERC‑7702 vs ERC‑4337 vs EIP‑3074 – co jest czym

  • ERC‑4337: AA bez zmian konsensusu; transakcje typu UserOperation w oddzielnym mempoolu, potrzebne bundlery i paymasterzy.
  • EIP‑3074: autoryzacja kontraktu do działania w imieniu EOA (opcodes AUTH/AUTHCALL); krytykowane za ryzyko „przejęcia” autoryzacji.
  • ERC‑7702: jednorazowa, odwracalna autoryzacja logiki smart‑portfela dla EOA w obrębie transakcji; cel – połączyć wygodę 3074 ze zgodnością bezpieczeństwa i ducha 4337.

Porównanie: kiedy 4337, a kiedy 7702?

Cecha ERC‑4337 ERC‑7702 EIP‑3074 Uwagi
Onboarding Smart‑portfel od startu EOA + chwilowa logika AA EOA deleguje kontraktowi 7702 ułatwia miękką migrację
Opłaty (gas) Paymaster natywnie Paymaster możliwy przez logikę Zależne od implementacji Oba wspierają sponsorowanie
Mempool UserOp/bundlery Klasyczny tx + autoryzacja Klasyczny tx 7702 zmniejsza tarcie integracji
Bezpieczeństwo Dojrzały ekosystem Safe/Guardians Jednorazowe uprawnienia, reset po tx Ryzyko nadmiernych uprawnień 7702 redukuje „approval rug”
Zgodność dApps Wymaga wsparcia UserOp Współpracuje z istniejącym UX Różnie, zależnie od dApp 7702 szybsze wdrożenia
Zaaw. logika Pełny smart‑portfel W granicach sesji/tx Ograniczone wzorce 4337 dla stałych zasad, 7702 dla sesji

Co to zmienia dla ekosystemu

DeFi

  • Subskrypcje i DCA on‑chain: cykliczne zlecenia z limitami i wygaśnięciem, bez ręcznego gazu.
  • Intencje rynkowe: „Chcę 5% więcej ETH do piątku” – warunki egzekwuje smart‑portfel.
  • Lepsza ochrona: limity per dApp, whitelisty tokenów, sesje z 2FA.

NFT & Digital Art

  • Mint sponsorowany: artysta/rynek pokrywa gaz, użytkownik akceptuje jednym kliknięciem.
  • Sesje galerii: podpisy tylko dla wybranego rynku przez 10 minut.

Giełdy & Kantory

  • On‑chain off‑ramp: KYC‑paymaster pokrywa gaz w zamian za prowizję i weryfikację.
  • Atomic swap intents: jedna zgoda – wiele kroków (approve + swap + transfer) atomowo.

Portfele & Bezpieczeństwo

  • Passkey/FIDO2: logowanie jak w aplikacjach bankowych, bez seedów.
  • Guardian/Recovery: odzysk przez zaufane klucze lub urządzenia.

Case study: DAO z limitem ryzyka i sesjami tradingowymi

  • Kontekst: Małe DAO zarządza skarbcem 500 000 USDC na L2. Trzech traderów działa w dni robocze 9:00–17:00.
  • Cel: Ograniczyć ryzyko i koszty, zwiększyć szybkość egzekucji.
  • Rozwiązanie (ERC‑7702 + logika AA):
    • Każdy trader dostaje sesyjny klucz ważny 8 godzin, z limitem 25 000 USDC/dzień.
    • Dozwolone kontrakty: 2 giełdy DEX i 1 agregator. Inne adresy – blokowane.
    • Paymaster pokrywa gaz z budżetu DAO, raportuje koszty do arkusza księgowego.
    • Transakcje powyżej 10 000 USDC wymagają drugiej autoryzacji (co‑sign).
  • Wynik (symulacja): 38% mniej błędów podpisu, 24% szybsze wykonanie zleceń, spójne logi do audytu.

Ryzyka i jak je ograniczać

  • Phishing sesyjny: fałszywe dApps proszą o szeroką autoryzację. Mitigacja: czytelne ekrany zgód, zakres domeny (EIP‑712 domain), krótkie TTL, whitelisty.
  • Replay cross‑chain: ponowne użycie podpisu na innym łańcuchu. Mitigacja: silne chainId w danych podpisu, nonce per sesja.
  • Utrata urządzenia/passkey: ryzyko dostępu. Mitigacja: guardiany, multi‑device, polityki „cooldown + revoke”.
  • Approval rug: nadanie zbyt szerokich uprawnień. Mitigacja: limity kwotowe, zakres tokenów, autoryzacja per dApp.
  • Błędy kontraktów: bug w logice walidacji. Mitigacja: audyty, formalna weryfikacja krytycznych ścieżek.

Deweloperzy: szybki start – intencje, podpis i walidacja

Model danych (przykład EIP‑712)

{
  types: {
    Intent: [
      { name: 'dapp', type: 'address' },
      { name: 'actionsHash', type: 'bytes32' },
      { name: 'maxSpend', type: 'uint256' },
      { name: 'deadline', type: 'uint256' },
      { name: 'chainId', type: 'uint256' },
      { name: 'nonce', type: 'uint256' }
    ]
  },
  domain: { name: 'Wallet7702', version: '1', chainId },
  primaryType: 'Intent',
  message: { /* wypełnij według akcji */ }
}

Walidacja po stronie smart‑portfela (schemat)

  • Sprawdź podpis EOA i domenę (anti‑phishing).
  • Zegzekwuj limity (kwota, adresy, czas, liczba akcji).
  • Opcjonalnie wymuś co‑sign (np. guardian lub urządzenie 2/2).
  • Uruchom akcje atomowo; w razie błędu – revert całości.

W praktyce skorzystasz z istniejących SDK AA: Safe{Core}, Biconomy, Pimlico, Stackup, Alchemy Account Kit oraz bibliotek WebAuthn/FIDO2 do passkey.

Narzędzia & Ekosystem (wybór)

  • Bundlery/Paymasterzy: Stackup, Pimlico, Biconomy – sponsorowanie gazu, limity, polityki.
  • Portfele AA: Safe, Rainbow, Zerion, Sequence – różne poziomy wsparcia intencji i passkey.
  • ZK‑KYC/Tożsamość: Polygon ID, zkPass, Anon Aadhaar – compliance‑preserving w DeFi.
  • Analiza: Tenderly, Blockscout, Dune – śledzenie kosztów gazu i skuteczności intencji.

Regulacje & Prawo: sponsorowany gaz, Travel Rule i MiCA

  • Paymaster jako VASP: jeśli sponsor opłat jest powiązany z usługą wymiany lub przechowywania, może podlegać reżimowi VASP (AML/KYC).
  • Travel Rule: transakcje powyżej progów – wymóg przekazywania danych nadawcy/odbiorcy między podmiotami regulowanymi; AA ułatwia przekazywanie metadanych bez ujawniania ich publicznie (np. ZK‑poświadczenia).
  • MiCA (UE): emitenci i dostawcy usług na krypto powinni dokumentować kontrolę ryzyka – polityki limitów i sesji z AA to plus w audycie.

Strategie inwestycyjne i praktyczne przygotowanie

  • Użytkownik detaliczny: załóż portfel wspierający AA, włącz passkey, ustaw limity i listy zaufanych dApps.
  • Trader: zbuduj szablony intencji (DCA, rebalans, arbitraż) z budżetami sesji; dokumentuj wyniki.
  • DAO/Treasury: wdroż guardianów, polityki 2‑etapowe dla dużych kwot, paymaster z rejestrem kosztów.
  • Budowniczy dApp: dodaj tryb gasless i podpisy EIP‑712 z czytelną domeną i zakresem.

FAQ & Support

Czy muszę migrować EOA do smart‑portfela?

Nie. ERC‑7702 pozwala użyć logiki smart‑portfela tymczasowo, w kontekście danej transakcji/sesji. Migracja nie jest wymagana.

Co z kosztami?

Koszty walidacji mogą być nieco wyższe niż goły EOA, ale paymaster może je pokryć. Na L2 różnice są zwykle niewielkie wobec zysków UX.

Czy 7702 wyprze 4337?

Nie musi. W praktyce oba standardy będą współistnieć: 4337 dla stałych smart‑portfeli i zaawansowanych polityk, 7702 dla lekkich, szybkich sesji i miękkiego onboardingu.

Wnioski i następne kroki

Kluczowy insight: ERC‑7702 nie „walczy” z 4337, ale obniża tarcie – oferuje AA‑UX bez twardej migracji. Daje to realne korzyści w DeFi (intencje, limity, sponsoring gazu), NFT (gasless mint), giełdach (atomiczne ścieżki), portfelach (passkey, recovery) i compliance (ZK‑KYC, Travel Rule‑ready metadane).

Co zrobić dziś?

  • Zainstaluj portfel wspierający AA + passkey i przetestuj sesje na sieci testowej L2.
  • Jako deweloper – dodaj podpisy EIP‑712 z wyraźnym zakresem i obsługę gasless.
  • Jako DAO – wdroż guardianów, limity i paymastera; mierz spadek ryzyka operacyjnego.

CTA: Jeśli budujesz dApp lub portfel, zaprojektuj „ekran zgody” jak w bankowości – z zakresem, limitem i czasem – i przetestuj go z użytkownikami nietechnicznymi. To właśnie ten detal wygra Ci adopcję.