ZK‑KYC bez selfie: jak wbudować prywatnościowe sprawdzenie AML w portfele i DeFi (bez ujawniania tożsamości)

Czy da się spełnić wymogi AML/KYC bez wysyłania skanów dokumentów i zdjęć twarzy na serwery pośredników? Rosnąca presja regulacyjna (MiCA/AMLR w UE, sankcje OFAC) ściera się z filozofią samodzielnej kontroli nad kluczami. Odpowiedzią staje się ZK‑KYC – wykorzystanie zero-knowledge proofs (ZKP), aby udowodnić fakt (np. „nie jestem na liście sankcyjnej”, „jestem rezydentem UE”, „mam powyżej 18 lat”) bez ujawniania danych źródłowych. Ten artykuł to praktyczny przewodnik po architekturach, narzędziach i wdrożeniach, które już dziś można testować w portfelach, DEX-ach i DAO.

Co to jest ZK‑KYC i co rozwiązuje?

ZK‑KYC (zero‑knowledge Know Your Customer) to paradygmat, w którym wydawca poświadczeń (np. licencjonowany dostawca KYC lub instytucja publiczna) wystawia użytkownikowi cyfrowe poświadczenie (credential). Użytkownik (posiadacz) przechowuje je lokalnie w portfelu i na żądanie tworzy dowód ZK, że spełnia określone kryteria – bez ujawniania numeru dokumentu, nazwiska czy adresu. Kontrakt DeFi lub front‑end weryfikuje poprawność dowodu, ale nie poznaje danych osobowych.

• Cel: spełnienie minimalnych wymogów AML/KYC i sankcyjnych, ograniczając ryzyko wycieków danych.
• Dla kogo: DEX-y, rynki NFT, DAO (głosowania), launchpady, dostawcy airdropów, portfele non‑custodial.
• Korzyść: prywatność użytkownika + brak przechowywania masowych baz PII po stronie protokołów.

Architektura referencyjna ZK‑KYC

Trzon rozwiązania tworzą trzy role oraz mechanizm unieważniania (revocation):

• Issuer (Wydawca): instytucja potwierdzająca atrybuty (np. wiek, rezydencja, status sankcyjny „OK”).
• Holder (Posiadacz): użytkownik przechowujący credential w portfelu i generujący dowody ZK.
• Verifier (Weryfikator): kontrakt/serwis, który sprawdza ważność dowodu względem polityki (policy).
• Revocation: mechanizm wycofania/odświeżenia poświadczeń (akumulatory kryptograficzne, drzewa Merkle, CRL).

Standardy i prymitywy kryptograficzne

• W3C Verifiable Credentials (VC): format interoperacyjnych poświadczeń; wspiera zarówno tryb jawny, jak i selective disclosure.
• BBS+ i AnonCreds: podpisy pozwalające na wybiórcze ujawnianie atrybutów i powiązane dowody wiedzy zerowej.
• SNARK/PLONK/Groth16: popularne systemy ZK do udowadniania złożonych predykatów (np. sprawdzenie w zbiorze bez ujawniania elementu).
• Drzewa Merkle/akumulatory RSA: wydajne dowody członkostwa/wykluczenia oraz mechanizmy unieważniania (revocation) bez publikacji PII.

Gdzie to się przydaje? 4 wzorce użycia

1) DEX: limity i listy sankcyjne bez PII

Przed wykonaniem swapu użytkownik prezentuje dowód ZK braku przynależności do listy sankcyjnej (dowód „nie‑członkostwa” w zbiorze). Dodatkowo można wymagać progu wartości (np. próg dobowy) poprzez politykę portfela, a nie logowanie do CEX‑a.

2) NFT marketplace: gating + anty‑sybil

Kupujący dowodzi, że nie jest wielokrotną tożsamością (proof‑of‑uniqueness) bez zdradzania adresu e‑mail. Seller otrzymuje mniejsze ryzyko chargebacków/banów, a rynek zachowuje krajowe ograniczenia (np. zakaz dla rezydentów określonych jurysdykcji) w trybie ZK.

3) DAO & głosowania

Dowód, że członek jest uprawniony (np. posiada credential „DAO‑Member‑2026”) i głosuje raz – bez powiązania z jego kluczem publicznym, co utrudnia targetowanie polityczne i sprzedaż głosów.

4) Airdropy & IDO/IEO

Filtrowanie sybili i rezydentów zabronionych krajów przy jednoczesnym zachowaniu prywatności. Organizator widzi tylko „spełnia/nie spełnia”, nie widzi danych osobowych.

Portfele: jak to działa w praktyce

• Przechowywanie poświadczeń lokalnie: credential VC w zaszyfrowanym keystore portfela.
• Generowanie dowodów offline: portfel buduje SNARK/PLONK lokalnie, wysyła tylko krótki dowód do kontraktu.
• WebAuthn/Passkeys/MPC: polityki podpisów (np. wymóg „dowodu ZK ważnego <24 h” przy transakcjach > X) egzekwowane przez MPC lub sesyjne klucze.
• Brak linkowania: stosowanie nullifierów i jednorazowych identyfikatorów, aby uniemożliwić korelację wielu użyć tego samego credentialu.

Implementacja: minimalny proof‑of‑concept (PoC) na testnecie

Poniższy plan pozwala zbudować prototyp „swap dostępny tylko dla osób 18+ i poza listą sankcyjną” – bez wgrywania PII do łańcucha.

Krok 1: Model danych i polityka

• Zdefiniuj credential VC z atrybutami: birthYear, country, sanctionsStatus=OK.
• Polityka weryfikatora: birthYear ≤ (bieżącyRok − 18) oraz sanctionsStatus=OK.

Krok 2: Warstwa kryptograficzna

• Zbuduj obwód ZK (np. w Circom/Noir) sprawdzający powyższe warunki na podpisanym credentialu (BBS+ lub inny schemat z selective disclosure).
• Dodaj nullifier pochodzący z klucza użytkownika i contextID (np. ID puli), aby zapobiec replay i linkowaniu między pulami.

Krok 3: Weryfikator on‑chain

• Wdróż kontrakt Verifier na L2 (niższe koszty), publikując verification key i endpoint verifyProof(bytes proof, bytes publicSignals).
• Kontrakt puli wywołuje Verifier przed wykonaniem swap(). W razie niepowodzenia rzuca revert bez logów z PII.

Krok 4: Warstwa Issuer i revocation

• Issuer wystawia VC podpisane swoim kluczem i publikuje Merkle root/akumulator ważnych credentiali (bez PII) na IPFS/on‑chain.
• Przy unieważnieniu credentialu – aktualizacja root; portfel wymusza odświeżenie dowodu (TTL).

Krok 5: UX portfela

• Dodaj ekran „Dowód zgodności”: „Wygeneruj dowód dla Puli #42 (ważny 24 h)”.
• Użyj passkey do potwierdzenia i wygeneruj SNARK lokalnie. Wyślij tylko dowód do kontraktu.

Porównanie metod prywatnościowego on‑boarding’u

Metoda	Co dowodzi	Zalety	Wyzwania	Zastosowania
Merkle allowlist	Członkostwo w liście	Prosta, tania w weryfikacji	Issuer zna listę adresów; słaba prywatność	Airdropy, whitelisty NFT
zkEmail	Posiadanie skrzynki/warunku w treści	Brak PII on‑chain; łatwy onboarding	Zależność od dostawcy poczty; dowody kontekstowe	Dostęp do beta/klubów, anty‑sybil
VC + BBS+ (selective disclosure)	Atrybuty (wiek/kraj) bez ujawniania całości	Standard W3C, interoperacyjność	Obsługa po stronie portfeli; revocation logika	DEX limity, NFT KYC‑light
SNARK (Groth16/PLONK)	Złożone predykaty i nie‑członkostwo	Bardzo krótki dowód; szybka weryfikacja	Setup/trusted ceremony; generacja dowodu po stronie klienta	On‑chain compliance, DAO głosowania

Koszty i wydajność: na co uważać

• Czas generacji dowodu: na laptopie/telefonie zwykle od setek ms do kilku sekund – zależnie od złożoności obwodu i bibliotek.
• Weryfikacja on‑chain: weryfikacja SNARK na L2 to z reguły ułamki centa do kilku centów; na L1 może być istotnie droższa (setki tysięcy gasów).
• Rozmiar dowodu: SNARK to zwykle kilkadziesiąt–kilkaset bajtów; wpływa na koszty calldata.
• Aktualizacje revocation: częstsze aktualizacje rootów = wyższe koszty publikacji, ale większe bezpieczeństwo.

Ryzyka i pułapki

• Korelacja: używaj nullifierów i kontekstów specyficznych dla puli, by uniknąć linkowania wielu interakcji.
• Revocation: zaprojektuj politykę TTL dowodów i częstotliwość odświeżania; rozważ akumulatory z efektywnym wykluczaniem.
• Akceptacja regulacyjna: nie każda jurysdykcja uzna ZK‑dowód za wystarczający; projektuj tryby hybrydowe (ZK‑light + eskalacja do pełnego KYC przy ryzyku).
• UX i odzyskiwanie: zgubienie urządzenia ≠ utrata prywatności, ale wymaga procedury re‑issuance credentialu i aktualizacji kluczy.

Mini‑studium przypadku: DEX w UE z progiem 1 000 EUR

• Polityka: transakcje powyżej 1 000 EUR wymagają ważnego dowodu ZK (wiek 18+, status sankcyjny OK, rezydencja UE).
• Przepływ:
  • Portfel generuje dowód (ważny 24 h) i dołącza go do wywołania swap().
  • Kontrakt Verifier sprawdza dowód oraz timestamp i nullifier.
  • Jeśli nullifier był użyty w tej samej dobie – odrzucenie (mitigacja nadużyć).
• Wydajność (przykładowo): generacja dowodu na telefonie: ~1–3 s dla prostych reguł; weryfikacja na L2: koszt niski (centy) — zależnie od sieci i obciążenia.
• Dane wrażliwe: żadne PII nie trafia on‑chain; na łańcuch wchodzą jedynie: rodzaj polityki, skrót credentialu/klucza Issuera, nullifier, znacznik czasu i dowód SNARK.

Narzędzia i ścieżka wdrożenia (praktyczna checklist)

• Specyfikacja polityk: opisz atrybuty i ich predykaty (wiek, kraj, status sankcyjny) oraz TTL dowodów.
• Wybór prymitywów: VC + BBS+ dla selective disclosure; SNARK dla złożonych predykatów i nie‑członkostwa.
• Warstwa portfela: lokalny generator dowodów, pamięć credentiali, integracja z passkeys/MPC.
• Warstwa on‑chain: kontrakt Verifier (L2), bezpieczne przechowywanie klucza Issuera/korzenia Merkle.
• Obsługa revocation: harmonogram publikacji nowych korzeni/akumulatorów; wymuszanie odświeżenia w portfelu.
• Tryb awaryjny: ścieżka „fallback KYC” dla przypadków podwyższonego ryzyka lub błędów w dowodach.

FAQ: szybkie odpowiedzi

• Czy ZK‑KYC to pełny KYC? To dowodzenie atrybutów, a nie przekazywanie PII. W praktyce bywa „KYC‑light” z możliwością eskalacji.
• Co, jeśli Issuer zostanie skompromitowany? Zmień klucz Issuera i zaktualizuj politykę. Stare credentiale można unieważnić przez revocation.
• Czy mogę przenieść credential między portfelami? Tak, jeśli issuer/format na to pozwala; zalecana jest procedura re‑bind do nowego klucza.

Wnioski i kolejne kroki

ZK‑KYC przenosi ciężar zgodności z „gromadzenia i przechowywania danych” na kryptograficzny dowód atrybutu. Efekt: mniej wycieków PII, mniejsze ryzyko regulacyjne dla protokołów i lepsze UX (dowód generowany lokalnie, ważny czasowo, bez rejestracji w wielu serwisach). Najszybsza ścieżka startu:

• Zdefiniuj minimalną politykę (wiek + sankcje + region) i wybierz L2 do weryfikacji.
• Zbuduj prosty obwód ZK, wdroż Verifier i prototypuj dowody w portfelu (desktop/mobile).
• Przetestuj revocation (zmiana rootów) i TTL dowodów pod realnym ruchem.

CTA: Jeśli rozwijasz DEX, rynek NFT lub portfel, zacznij od zamkniętego canary release ZK‑KYC w jednej puli/sekcji — zbierz metryki czasu generacji i akceptacji użytkowników, a następnie skaluj do całości.