ZK‑KYC dla DeFi pod MiCA: prywatne bramki zgodności z revokacją i ERC‑4337 bez utraty decentralizacji

Kategorie: DeFi, Bezpieczeństwo, Regulacje & Prawo, Web3 & DAO, Stablecoiny

Wprowadzenie: czy da się połączyć prywatność, DeFi i zgodność z prawem?

MiCA w UE i wytyczne FATF (tzw. Travel Rule) wymuszają weryfikację użytkowników w obrębie usług krypto. DeFi historycznie opiera się na bezpozwoleniowym dostępie i pseudonimowości. Pytanie brzmi: jak włączyć zgodność regulacyjną, nie zamieniając protokołu w scentralizowaną bramkę? Odpowiedzią są dowody zerowej wiedzy (ZK) oraz wzorce ZK‑KYC, które pozwalają udowodnić „jestem uprawniony”, nie ujawniając „kim jestem”.

Dlaczego to temat na teraz?

• MiCA formalizuje kategorie usług i wymogi AML w UE – integracje będą punktowane przez audytorów i instytucje płatnicze.
• Instytucjonalna płynność oczekuje filtrów sankcyjnych/AML z poszanowaniem prywatności – bez nich nie przyjdą do AMM/pożyczek.
• ERC‑4337 (Account Abstraction) i paymasterzy pozwalają płacić gaz w stablecoinach i wstrzykiwać reguły zgodności przy podpisie – bez łamania UX.

Trzon rozwiązania: co naprawdę oznacza ZK‑KYC w praktyce?

1) Poświadczenie poza łańcuchem (Wydawca → Użytkownik)

Użytkownik przechodzi jednorazowy KYC u wydawcy poświadczeń (np. dostawca AML/KYC, bank, giełda). Zamiast przechowywać jego dane on-chain, wydawca wystawia Verifiable Credential (VC) lub dodaje hash jego tożsamości do drzewa Merkle uprawnionych.

2) Dowód bez ujawnienia (Użytkownik → Protokół)

Przed złożeniem transakcji użytkownik generuje dowód ZK (np. Groth16/Plonk) potwierdzający: „należę do zbioru X, nie jestem na liście Y, mam wiek > 18” itd., bez ujawniania dokumentów. Dowód zawiera nullifier – unikalny identyfikator, który zapobiega nadużyciom (np. multi-claim) bez deanonymizacji.

3) Weryfikacja on-chain i egzekwowanie reguł

Kontrakt DeFi posiada moduł weryfikacji (verifier), który akceptuje transakcję tylko, gdy: (a) proof jest poprawny, (b) korzeń drzewa Merkle uprawnionych jest aktualny, (c) dany nullifier nie był użyty w sposób naruszający politykę (np. nałożony limit dzienny), (d) adres nie jest obecny w drzewie revokacji.

Architektury ZK‑KYC: cztery wzorce, które działają

• Allowlista Merkle + ZK membership – najprostszy mechanizm: on-chain przechowuje tylko root; użytkownik dowodzi przynależność do liścia. Plus: tani w gazie i audycie. Minus: aktualizacja i revokacja wymagają sprawnego zarządzania drzewem.
• W3C VC + Iden3/Polygon ID – selektywne ujawnienie atrybutów (np. obywatelstwo, wiek). Plus: interoperacyjność z DID/VC. Minus: więcej ruchomych części (portfele, weryfikatory, schematy atrybutów).
• Semaphore (grupy anonimowe) – użytkownik dowodzi członkostwo w grupie i emituje sygnał z nullifierem. Plus: świetne do głosowań/limitu 1‑osoba‑1‑aktywność. Minus: wymaga warstwy mapowania „grupa ↔ polityka AML”.
• TEE‑attestation + ZK – wrażliwe sprawdzenia w TEE (np. SGX), a na łańcuch trafia tylko krótki dowód/attestation. Plus: dobra wydajność. Minus: zależność od sprzętu i modeli zaufania.

Porównanie podejść (prywatność, koszt, revokacja, złożoność)

Wzorzec	Prywatność	Gaz (weryfikacja)	Revokacja	Złożoność operacyjna
Merkle + ZK	Wysoka (brak ujawniania atrybutów)	Niska–średnia (dowód członkostwa)	Łatwa przez aktualizację root + drzewo blokad	Niska
VC + Iden3/Polygon ID	Wysoka (selektywne ujawnienie)	Średnia (weryfikacja schematów/issuerów)	Wbudowana (unieważnienia VC)	Średnia–wysoka
Semaphore	Wysoka (anonimowa grupa)	Niska–średnia	Przez rekonfigurację grupy	Średnia
TEE + ZK	Wysoka (pozałańcuchowo)	Niska	Po stronie operatora TEE	Wysoka

Integracja z ERC‑4337: gaz w stablecoinach i polityki w paymasterze

• Paymaster zgodności – odrzuca UserOperation bez ważnego proofa ZK lub gdy nullifier/adr jest w drzewie revokacji.
• Opłaty w stablecoinach – paymaster pokrywa gaz i ściąga opłatę w USDC/DAI; UX jak w Web2.
• Hooki polityk – różne poziomy (np. tylko wypłaty z puli > X wymagają KYC; swapy < Y bez dowodu).
• ERC‑1271 – weryfikacja podpisów portfeli kontraktowych: proof ZK może warunkować ważność podpisu.

Gdzie trzymać revokację, by była prywatna i szybka?

Najlepszą praktyką jest podwójne drzewo:

• Drzewo uprawnień – root publikowany periodycznie; obejmuje hash(e) wydanych poświadczeń.
• Drzewo revokacji – zawiera nullifiery lub identyfikatory poświadczeń unieważnionych. Weryfikator sprawdza, czy nullifier nie jest liściem tego drzewa.

Aktualizacje można dystrybuować przez Eventy on-chain, a off-chain klienci (portfele) buforują najnowsze rooty, podpisane przez zaufanych issuerów (lista dozwolonych DID/kluczy publicznych).

Rzadko opisywany, ale kluczowy problem: mapowanie jurysdykcji i celów użycia

Nie każdy dowód „przeszedłem KYC” znaczy to samo. Potrzebne są schematy atrybutów (credential schemas) i polityki po stronie protokołu, np.:

• Poziom 0: brak KYC – wolny dostęp do mikropłatności do 100 EUR/24h.
• Poziom 1: KYC‑lite (wiek, sankcje) – limity do 1 000 EUR/dzień.
• Poziom 2: pełne KYC + źródło środków – dostęp bez limitów, ale z monitoringiem ryzyka.

W ZK‑KYC zamiast przechowywać szczegóły, kontrakt oczekuje predykatów (np. „wiek ≥ 18”, „jurysdykcja ≠ zabroniona”) dowodzonych w proofie.

Bezpieczeństwo: gdzie się wywracają wdrożenia ZK‑KYC?

• Re‑identyfikacja przez metadane – nawet z ZK, fingerprinting przeglądarki/portfela może deanonymizować. Minimalizuj telemetry, standaryzuj ścieżki UX.
• Nieaktualne rooty – akceptowanie starych korzeni drzew podważa revokację. Wymuś okno ważności (np. ostatnie N bloków lub podpisany timestamp).
• Słaba entropia nullifierów – nullifier musi być deterministyczny per‑polityka, ale nie odwracalny do DID. Używaj saltów po stronie użytkownika.
• Zaufanie do issuerów – lista dozwolonych wydawców musi być zarządzana przez DAO z jawnie opisaną procedurą wejścia/wyjścia.

Studium wdrożeniowe (projekt referencyjny): AMM z prywatnymi bramkami

• Cel: dopuścić płynność instytucjonalną do puli > 5 mln USD bez przechowywania danych osobowych on-chain.
• Stack: Merkle + Groth16, moduł verifier, paymaster ERC‑4337, VC w standardzie W3C dla poziomów 1–2.
• Przepływ:
  1. Użytkownik pobiera VC od zatwierdzonego wydawcy (portfel mobilny z modułem ZK).
  2. Przy pierwszym dodaniu płynności generuje proof: „posiadam VC poziomu ≥ 1 oraz nie jestem z listy sankcyjnej”.
  3. Paymaster weryfikuje proof i opłaca gaz w USDC, po czym AMM zapisuje nullifier polityki (anti‑Sybil).
  4. Unieważnienia VC publikowane są jako aktualizacje rootów revokacji co godzinę.
• Efekt: publiczny dostęp do cen i płynności, prywatne atrybuty zgodności; brak danych PII w łańcuchu.

Regulacje & Prawo: gdzie ZK‑KYC styka się z MiCA i FATF

• MiCA – dla dostawców usług krypto w UE, ZK‑KYC może stanowić techniczną implementację polityk AML bez transferu PII do łańcucha.
• FATF R.16 (Travel Rule) – wymiana informacji VASP↔VASP może pozostać poza łańcuchem; on-chain trafia tylko sygnał zgodności (proof/potwierdzenie).
• RODO – brak PII na łańcuchu upraszcza obowiązki. Dane przetwarzane są u wydawcy poświadczeń; użytkownik kontroluje prezentację.

Uwaga: to nie jest porada prawna. Skonsultuj wdrożenie z prawnikiem w swojej jurysdykcji.

Praktyczne narzędzia i checklist przed startem mainnetu

• Biblioteki: circom/snarkjs, Halo2/Plonk implementacje, Iden3/Polygon ID SDK, Semaphore.
• Audyt: kontrakty verifier, aktualizacja rootów, listy issuerów (DID/klucze), logika nullifierów.
• Monitoring: alerty na zmiany rootów i anomalie nullifierów; dashboard ryzyka (off-chain).
• UX: paymaster z płatnością w stablecoinie, fallback na zwykły gaz, jasne komunikaty dot. poziomów KYC.

Najczęstsze pytania (FAQ) z perspektywy zespołu DeFi

• Czy proofy są drogie w gazie? Weryfikacja Groth16 bywa rzędu setek tysięcy gas; często akceptowalne przy transakcjach o większej wartości. AA+paymaster pomaga ukryć koszt dla użytkownika.
• Co z chainami L2? Tańsza weryfikacja i lepszy UX. Pamiętaj o synchronizacji rootów i tożsamej liście issuerów cross‑chain.
• Jak uszanować sankcje? Zamiast jawnej listy adresów – ZK‑dowód „nie należę do zbioru Z”, utrzymując prywatność uczciwych użytkowników.

Wnioski i następne kroki

ZK‑KYC pozwala budować bezpozwoleniowe protokoły z programowalną zgodnością, nie wyciekając PII do łańcucha. Kluczem jest dobrze zaprojektowana revokacja, zarządzanie issuerami przez DAO i ergonomia ERC‑4337. Zaczynaj od puli wysokiego ryzyka/wartości i stopniowo rozszerzaj polityki na cały produkt.

CTA: Planujesz wdrożyć ZK‑KYC w AMM lub pożyczkach? Przygotujemy referencyjną specyfikację polityk, drzew revokacji i paymastera w 2 tygodnie – skontaktuj się z nami po checklistę audytu i PoC.