Portfele bez seedów: Passkeys + EIP‑7212 i EIP‑7702 zmieniają UX Web3 (bezpieczeństwo, wdrożenie, prawo)

Czy za chwilę będziemy zatwierdzać transakcje twarzą lub odciskiem palca – bez seed phrase? Trzy klocki układanki sprawiają, że to przestaje być wizją, a staje się roadmapą: WebAuthn/Passkeys (FIDO2), EIP‑7212 (weryfikacja P‑256 w EVM) i inteligentne konta przez ERC‑4337 oraz nowszy EIP‑7702. Dodajmy europejski eIDAS2 i pytanie nie brzmi już „czy”, tylko „jak” i „kiedy”.

Dlaczego to temat na teraz?

UX: brak seeda to mniej porzuconych onboardów i mniej utraconych środków.
Bezpieczeństwo: passkeys są odporne na phishing i działają w bezpiecznych enklawach urządzeń.
Technika już istnieje: L2 zaczynają wspierać EIP‑7212, a 4337 jest w produkcji od 2023 r.; EIP‑7702 upraszcza AA na poziomie protokołu (status: propozycja).

Passkeys w pigułce: jak to działa kryptograficznie

Passkey to para kluczy generowana lokalnie w urządzeniu (np. iPhone Secure Enclave, Android StrongBox, YubiKey). Logika WebAuthn/FIDO2 zapewnia, że serwis (tu: portfel lub dApp) widzi tylko podpis wyzwania (challenge) powiązany z danym originem (domena/aplikacja), co eliminuje phishing przez domeny‑podróbki.

Krzywa P‑256 (secp256r1): standard w passkeys; podpis ES256.
Attestation: opcjonalny dowód klasy sprzętu (np. że to autentyczny Secure Element).
Device‑bound vs synced: klucz może być związany z konkretnym urządzeniem lub synchronizowany w chmurze (iCloud/Google) – to ważny wybór w modelu zagrożeń.

Po co EIP‑7212: P‑256 w EVM bez akrobacji

EIP‑7212 dodaje do EVM prekompilat weryfikacji podpisu secp256r1 (P‑256). Dzięki temu smart‑kontrakt może natywnie sprawdzić podpis z passkey bez kosztownych tricków ZK lub mostków kryptograficznych.

Efekt: inteligentne konto może akceptować podpisy P‑256 jako „własny” mechanizm autoryzacji.
Status: część łańcuchów L2 już eksperymentuje/wdraża; mainnet L1 – do obserwacji.
Gas: koszt niższy i stabilniejszy niż emulacja P‑256 w solidity; porównywalny rząd wielkości do ECDSA secp256k1, zależnie od implementacji L2.

ERC‑4337 i EIP‑7702: dwa szlaki do inteligentnych kont

ERC‑4337 umożliwia konta zarządzane logiką smart‑kontraktu (walidacja podpisu, limity, guardianie) bez zmian w protokole. EIP‑7702 (propozycja) wprowadza transakcje, które tymczasowo „podpinają” EOA pod logikę smart‑konta, upraszczając AA na poziomie L1.

4337 w praktyce

Bundler: składa operacje użytkownika, byle dApp nie musiała się martwić formatem transakcji.
Paymaster: sponsoruje gas (np. płatność stablecoinem lub gasless promo).
Session keys: tymczasowe uprawnienia (np. limit 50 USDC/dzień, tylko dla konkretnego dApp).

7702 – co zmienia

Prościej dla EOA: brak pełnej zależności od infrastruktury 4337, AA bliżej „warstwy bazowej”.
Elastyczna walidacja: konto może przyjąć niestandardową weryfikację (np. P‑256 via EIP‑7212) w obrębie transakcji.
Status: w toku; traktuj jako „watchlistę” dla roadmap projektów.

Architektury portfeli bez seeda

Passkey‑only: jedno źródło prawdy to klucz P‑256 w urządzeniu. Najprostsze UX, ryzyko utraty bez kopii.
Passkey + Social Recovery: guardianie (np. 2/3: partner, hardware key, własny drugi telefon) odblokowują odzysk.
Passkey + MPC: klucz dzielony na udziały (telefon + przeglądarka + serwer TEE). Pozwala wymusić polityki (limity, 2‑z‑3), ale rośnie złożoność.
Hybrid: passkey do codziennego użytku, hardware key (YubiKey/Titan) jako „zimny” guardian + limity dzienne.

Modele zagrożeń i dobre praktyki (Bezpieczeństwo)

Phishing: passkeys podpisują wyzwanie związane z originem – to mocna ochrona, ale uważaj na deeplinki i fałszywe aplikacje.
Utrata urządzenia: wybierz 2‑z‑3 (telefon + hardware key + partner) lub chmurowe passkeys plus guardian.
Attestation policy: akceptuj tylko klasy sprzętu z silnym atestem (np. FIPS/NIST, FIDO L2+), jeśli obsługujesz duże wolumeny.
RODO/biometria: biometria nie opuszcza urządzenia; serwer widzi tylko podpis. To pomaga w zgodności, ale polityki prywatności muszą to jasno komunikować.
Granularne limity: dzienne/tygodniowe budżety, białe listy adresów, opóźnienia przy zmianie guardianów.
Supply chain: weryfikuj biblioteki WebAuthn, używaj Key Transparency (jeśli dostępne) i monitoruj odciski kluczy.

Prawne niuanse: MiCA, eIDAS2, Travel Rule (Regulacje & Prawo)

MiCA: portfele self‑custody z AA i passkeys zwykle nie są CASP, o ile nie kontrolujesz kluczy użytkownika. Uwaga na paymasterów/kaszowanie – gdzie kończy się „usługa”?
eIDAS2: europejskie portfele tożsamości mogą współistnieć z krypto‑passkeys. W scenariuszach DeFi/KYC połącz lokalny podpis passkey z atrybutami z eIDAS2 (np. wiek, kraj) – najlepiej off‑chain + ZK‑proof.
Travel Rule: dotyczy CASP i transferów powyżej progów – passkeys nie zwalniają z obowiązków AML przy transferach z/do podmiotów regulowanych.

Implementacja: proof‑of‑concept krok po kroku (Deweloperzy)

Wybierz łańcuch z EIP‑7212 lub planem wdrożenia (często L2). Skonfiguruj bundler 4337 (np. Stackup, Alchemy) i paymastera testowego.
WebAuthn w frontendzie:
- Utwórz credential (alg ES256/P‑256), preferuj resident keys, userVerification=required.
- Przechowaj publicKey i credentialId u użytkownika (zaszyfrowane) oraz w backendzie (mapowanie konta).
Smart‑konto:
- Zdeplojuj kontrakt konta z metodą validateUserOp() (4337) lub walidacją pod 7702, która wywołuje prekompilat P‑256 (EIP‑7212).
- Dodaj guardianów, limity kwotowe, białe listy i session keys.
Podpisywanie:
- Twórz challenge związaną z dApp originem i danymi transakcji (hash UserOperation).
- Weryfikuj authenticatorData i clientDataJSON po stronie kontraktu (część logiki w off‑chain adapterze, część on‑chain przez 7212).
Gas & UX:
- Paymaster sponsoruje pierwsze N transakcji; fallback na stablecoina.
- Wprowadź tryb offline z session key o małych limitach dla gier/metaverse.
Odzysk:
- Wymuś 2‑z‑3 (telefon + YubiKey + trusted person) z opóźnieniem 48 h i możliwością anulowania.

Studia przypadków (Metaverse & Gaming, DeFi, Społeczność)

Gra mobilna: onboarding 1‑klik, session key 5 USDC/dzień, brak pop‑upów. Wzrost konwersji +30–50% vs seed.
Portfel rodzinny: rodzic sponsoruje gas, dzieci mają limity 10 USDC/tydzień, guardianie: 2 z 3 (oboje rodzice + hardware key w sejfie).
DAO osiedlowe: głosowania podpisywane passkey (P‑256), a transfery skarbca wymagają 2‑z‑3 guardianów i 24 h timelock.

Koszty i wydajność (Makro & Rynek techniczny)

Aspekt	P‑256 via EIP‑7212	secp256k1 (klasyczne)	Uwagi
Weryfikacja	Natywny prekompilat	Natywna	Na części L2 koszty podobne rzędu kilkudziesięciu tys. gas
UX	Biometria/OS, anti‑phishing	Seed/hasło, podatne na phishing	Passkeys wygrywają onboarding
Odzysk	Guardianie/backup hardware	Seed‑phrase	Seed gubi się częściej niż hardware key
Złożoność dev	WebAuthn + 4337/7702	Klasyczny EOA	Więcej komponentów, ale bogatsze polityki

Checklist: gotowość produkcyjna (Portfele, Bezpieczeństwo, Narzędzia)

Łańcuch z EIP‑7212 (lub roadmapą) + bundler o gwarancjach uptime.
Passkey UX: userVerification=required, mechanizm dodania 2. urządzenia, edukacja dot. backupu.
Guardians: min. 2‑z‑3, timelock przy zmianach, log audytowy on‑chain.
Paymaster: limity sponsoringu, ochrona przed syfonowaniem, fallback fee.
Prywatność: minimalizacja telemetryki, jasna polityka RODO (biometria lokalna).
Audyt: kontrakty walidacji P‑256 i integracja WebAuthn – audyt zewnętrzny.

Ekosystem: kto już testuje

Wallety 4337 z passkeys: projekty typu smart‑wallet (np. wdrożenia w stylu Coinbase Smart Wallet, OKX Web3, biblioteki Privy/Dynamic) eksperymentują z WebAuthn i P‑256.
Infrastruktura: bundlery (Stackup/Alchemy), SDK kont (Account Abstraction kits), pierwsze L2 z EIP‑7212.

Co dalej? Kierunki R&D

WebAuthn L3: lepsze metadane i opcje polityk atestacji.
Key Transparency logi on‑chain dla publicznych kluczy passkey (detekcja podmian).
ZK‑Passkey: dowód posiadania klucza bez ujawniania podpisu (prywatność + anty‑linkowanie).
DePIN i Secure Elements w IoT: autoryzacja mikropłatności urządzeń przez passkeys sprzętowe.

Wnioski końcowe

Passkeys + EIP‑7212 + inteligentne konta (4337/7702) to realna droga do masowego UX w Web3: brak seeda, odporność na phishing i polityki bezpieczeństwa na poziomie konta. Nie czekaj, aż standardy „same się przyjmą”.

Dla builderów: zbuduj weekendowy PoC – passkey signin, smart‑konto z limitem dziennym, paymaster sponsoring 1. transakcji.
Dla zespołów compliance: zaplanuj, gdzie kończy się self‑custody, a zaczyna CASP; oceń RODO dla biometrii.
Dla użytkowników: dodaj drugi nośnik (hardware key) i włącz limity. To dwie minuty, które mogą uratować środki.