Account Abstraction (ERC‑4337) spotyka eIDAS 2.0: jak połączyć portfele smart z europejską tożsamością cyfrową w DeFi, DAO i na giełdach

Unikalny kierunek integracji Web3 z rynkiem UE: czy portfele smart (ERC‑4337) mogą bezpiecznie współpracować z EUDI Wallet (tożsamość cyfrowa UE wg eIDAS 2.0) tak, aby poprawić KYC/AML, uprościć onboarding i nie zniszczyć prywatności? Poniżej prezentujemy praktyczne, mało omawiane wzorce architektoniczne, gotowe przepływy i checklisty dla DeFi, DAO, giełd i fintechów.

Dlaczego to ważne teraz?

Rynek Web3 dojrzewa: rośnie presja regulacyjna (MiCA, Travel Rule), a jednocześnie użytkownicy oczekują UX jak w bankowości mobilnej. Account Abstraction daje portfelom funkcje rodem z aplikacji finansowych (np. social recovery, płatność opłat gas w stablecoinach), zaś eIDAS 2.0 wprowadza europejski standard tożsamości cyfrowej. Połączenie tych dwóch światów może odblokować regulowane DeFi, członkostwo w prawnie osadzonych DAO oraz non‑custodial KYC na giełdach.

Podstawy: eIDAS 2.0 i EUDI Wallet w pigułce

eIDAS 2.0 to rama prawna UE dla zaufanych usług i tożsamości cyfrowej. Rdzeniem wdrożeń ma być EUDI Wallet – aplikacja przechowująca Weryfikowalne Poświadczenia (VC), np. wiek, rezydencję podatkową czy status firmy. Zaufanie budują kwalifikowane podpisy (QES) oraz listy zaufania dla dostawców. W Web3 te elementy mogą służyć do selektywnego ujawniania atrybutów, bez przekazywania pełnych danych osobowych.

Podstawy: Account Abstraction (ERC‑4337)

AA rozdziela klucz użytkownika od „konta” i wprowadza potok transakcji z bundlerami i paymasterami. Dzięki temu portfele zyskują:

• Elastyczne reguły podpisu (np. session keys, multisig, limity dzienne).
• Opłaty gas w stablecoinach przez paymasterów.
• Odzyskiwanie dostępu przez guardianów lub mechanizmy społecznościowe.

Wzorce integracji EUDI ↔ ERC‑4337 (3 modele)

1) Off‑chain gating: SIWE + VC z EUDI

Najprostsze: użytkownik loguje się przez Sign‑In with Ethereum (SIWE) i prezentuje wybrane VC z EUDI (np. „18+”, „PL tax resident”). Back‑end weryfikuje podpis i ważność poświadczeń, a aplikacja nadaje dostęp do funkcji (np. rynek NFT +18, staking dla rezydentów danej jurysdykcji). Zero zmian on‑chain; dane osobowe pozostają poza łańcuchem.

2) On‑chain policy: moduł kontrolny w smart kontrakcie

Portfel smart posiada moduł PolicyModule, który dopuści transfery tylko jeśli orakl zaufania potwierdzi, że adres spełnia politykę (np. „KYC passed by EU‑trusted issuer”). To minimalizuje dane – na łańcuch trafia jedynie skrót lub znacznik statusu, nie pełne dane osobowe.

3) ZK‑KYC z EUDI: selektywne ujawnianie

Zaawansowany wariant: EUDI wydaje atrybuty, a użytkownik generuje dowód zero‑knowledge (np. „wiek ≥ 18” lub „rezydent UE”), bez ujawniania daty urodzenia czy adresu. Kontrakt weryfikuje dowód, a paymaster sponsoruje transakcję, by UX był zbliżony do Web2.

Architektura hybrydowa: gdzie siedzi „zgoda” i kto jest kluczem?

• Guardian z EUDI: QES lub podpis w EUDI może być „opiekunem” konta AA, wykorzystywanym tylko do odzyskiwania lub zatwierdzania zmian zasad bezpieczeństwa.
• Codzienna płynność: drobne transakcje akceptuje lokalny klucz (telefon/klucz sprzętowy) z limitami i oknami czasowymi; powyżej progu wymagana jest ko‑autoryzacja EUDI.
• Minimalizacja ryzyka: identyfikator EUDI nigdy nie jest publikowany on‑chain; kontrakt widzi tylko wynik polityki lub skrót uprawnienia.

Przykładowy przepływ: non‑custodial onboarding na polskiej giełdzie DeFi

1. Użytkownik instaluje portfel AA i tworzy konto smart.
2. Na stronie giełdy: SIWE + prośba o VC „KYC Basic” z EUDI (selektywne ujawnienie: kraj, pełnoletniość).
3. Back‑end weryfikuje łańcuch zaufania EUDI i tworzy anonimowy token dostępu (krótko żyjący).
4. Giełda zapisuje on‑chain „status KYC: OK” w rejestrze polityki (hash + czas ważności).
5. Transakcje > określonego progu wymagają ko‑podpisu guardian‑EUDI; mniejsze pokrywa paymaster pobierając opłatę w stablecoinie.

Minimalny moduł polityki (pseudokod)

contract PolicyModule {
  mapping(address => bytes32) public kycHash;    // skrót atrybutów / statusu
  mapping(address => uint256) public expires;    // czas ważności
  address public oracle;                         // zaufany weryfikator

  function setStatus(address user, bytes32 h, uint256 ttl) external {
    require(msg.sender == oracle, "only oracle");
    kycHash[user] = h; expires[user] = block.timestamp + ttl;
  }

  function canTransfer(address user, uint256 amount) external view returns (bool) {
    bool fresh = block.timestamp < expires[user];
    bool underLimit = amount <= limitFromHash(kycHash[user]);
    return fresh && underLimit;
  }
}

Uwaga: w produkcji stosuj audyt, up‑gradability z ostrożnością, mechanizmy odwołania i listy cofnięć.

Porównanie metod podpisu w portfelach smart

Metoda	Warstwa	Moc prawna (UE)	UX	Latencja	Koszt
ECDSA klucz w telefonie	On‑device	Brak szczególnego statusu	Bardzo dobry	Niska	Niski
WebAuthn / Passkey	TPM / Secure Enclave	Techniczne, nie prawne	Świetny (biometria)	Niska	Niski
Klucz sprzętowy NFC/USB	HW token	Brak formalnej kwalifikacji	Dobry	Niska	Średni
QES przez EUDI/QSCD	Trust service	Kwalifikowany podpis	Wolniejszy (potwierdzenia)	Średnia	Średni/Wyższy

Bezpieczeństwo i prywatność: pułapki i remedia

• Korelacja tożsamości: nigdy nie zapisuj identyfikatorów EUDI on‑chain. Używaj skrótów, tokenów krótko żyjących i pseudonimizacji.
• Odwołania poświadczeń: integruj orakle list cofnięć (CRL/Status VC) – status KYC wygasa i musi być okresowo odświeżany.
• Ataki na paymastera: ustal limity sponsoringu, dynamiczne stawki i listy dozwolonych metod, by uniknąć gas drain.
• Ucieczka z kluczem: wymuś okres karencji przy zmianie guardianów/kluczy, z powiadomieniami off‑chain.
• Minimalizacja danych: stosuj selective disclosure i ZK‑proofs wszędzie, gdzie to możliwe.

Koszty, wydajność i UX

• Warstwa AA: pojedyncza userOperation bywa o kilka–kilkanaście procent cięższa niż zwykły transfer, ale bundling i paymaster poprawiają UX.
• Orakle polityki: model „write‑once short hash” minimalizuje koszty on‑chain; odświeżanie statusu tylko przy zmianach.
• UX: zachowaj zasadę „cicha autoryzacja do małych kwot, wzmocniona (EUDI/QES) dla wysokich ryzyk”.

Regulacje & prawo: o czym pamiętać

• MiCA/AML: integracja z EUDI ułatwia spełnianie wymogów KYC/AML, ale podmiot przetwarzający dane nadal odpowiada za RODO i DPIA.
• Travel Rule: status KYC można potwierdzać atrybutowo zamiast przesyłać pełne dane do kontrahenta, przy wsparciu zaufanych pośredników.
• RODO: przechowuj minimum informacji, trzymaj logikę polityk po stronie użytkownika i krótkotrwałych tokenów.

Case: DAO dla osiedla mieszkaniowego (głosowania i skarb)

• Członkostwo: VC „mieszkaniec budynku X” (EUDI), ZK‑dowód rezydencji.
• Głosowania: kontrakt weryfikuje dowód „mieszkaniec=TAK” bez ujawniania tożsamości.
• Skarb: wypłaty > 5 000 PLN wymagają ko‑autoryzacji guardian‑EUDI zarządcy wspólnoty.
• Audyt: publiczna historia decyzji bez danych osobowych.

Checklist wdrożeniowy (Polska / UE)

1. Zdecyduj model polityki: off‑chain gating, on‑chain hash, czy ZK‑KYC.
2. Wybierz portfel AA z obsługą guardianów, paymastera i session keys.
3. Skonfiguruj weryfikator EUDI (łącznik do zaufanych usług/VC, obsługa list cofnięć).
4. Zaprojektuj limity transakcyjne i progi, przy których wymagana jest ko‑autoryzacja EUDI.
5. Wdróż orakla statusu (hash + TTL), mechanizmy odświeżania i wygaśnięcia.
6. Przeprowadź DPIA i testy prywatności; loguj tylko to, co konieczne.
7. Zapewnij fallback UX (utrata telefonu/klucza, odzysk przez guardian‑EUDI).

Narzędzia & komponenty, które warto znać

• Bundler/Paymaster: infrastruktura AA z obsługą polityk i sponsorowanych transakcji.
• Biblioteki ZK: generatory dowodów dla selektywnego ujawniania atrybutów z VC.
• Adapter EUDI: warstwa integracyjna z portfelami EUDI i listami zaufania.

Pro / Contra krótkie podsumowanie

Aspekt	Pro	Contra
Bezpieczeństwo	Ko‑autoryzacja EUDI dla wysokich ryzyk	Złożoność integracji i UX
Prywatność	ZK i selective disclosure	Ryzyko korelacji przy złej implementacji
Zgodność	Ułatwia KYC/AML i Travel Rule	Wymaga kontroli RODO i DPIA
UX	Gas w stablecoinach, recovery	Dodatkowe kroki przy progu ryzyka

Najczęstsze pytania (FAQ)

• Czy muszę przechowywać dane osobowe on‑chain? Nie. Stosuj znaczniki/hashe statusu lub ZK‑dowody.
• Czy bez EUDI mogę wystartować? Tak, użyj SIWE + lokalnego KYC, a warstwę EUDI dołącz, gdy będzie dostępna dla Twojej grupy docelowej.
• Czy QES jest konieczny do każdej transakcji? Nie. Traktuj QES jako warstwę high‑risk (zmiana kluczy, duże wypłaty), nie jako codzienny podpis.

Wnioski i następne kroki

Połączenie ERC‑4337 z eIDAS 2.0/EUDI pozwala zbudować regulowane, a zarazem niepowiernicze doświadczenia w DeFi, DAO, NFT i na giełdach. Największą wartością jest granularna kontrola ryzyka: progi transakcyjne, guardian‑EUDI i ZK‑atrybuty umożliwiają zgodność bez zbędnego ujawniania danych. Jeśli tworzysz produkt Web3 w UE, zacznij od off‑chain gatingu, zaprojektuj orakla polityki z hashem + TTL i przetestuj ZK‑KYC na krytycznym przepływie. To realna przewaga konkurencyjna na rynku, który wymaga dziś jednocześnie bezpieczeństwa, prywatności i prostoty.

CTA: Zmapuj swoje przepływy wysokiego ryzyka i zdefiniuj, gdzie ko‑autoryzacja EUDI najbardziej ograniczy straty – zwykle są to zmiany kluczy, wypłaty skarbcowe i handel powyżej progu AML. Następnie wdroż proof‑of‑concept z modułem polityki i paymasterem.