ZK‑KYC i „privacy passporty” dla DeFi: jak wdrożyć zgodność AML bez utraty prywatności (2025)
ZK‑KYC i „privacy passporty” dla DeFi: jak wdrożyć zgodność AML bez utraty prywatności (2025)
Regulacje rosną, prywatność topnieje – czy musi tak być? MiCA, Travel Rule i sankcje FATF wymuszają weryfikację użytkowników, ale Web3 nie jest skazany na pełne ujawnianie tożsamości. ZK‑KYC (weryfikacja KYC z użyciem zero-knowledge proofs) oraz „privacy passporty” pozwalają udowodnić spełnienie wymogów (wiek, rezydencja, brak na liście sankcyjnej) bez ujawniania danych osobowych kontraktowi ani giełdzie on-chain. Poniżej praktyczny przewodnik dla DeFi, giełd, projektów Web3 i startupów, jak to zrobić dziś – bez czekania na „później”.
Co to jest ZK‑KYC i dlaczego to rewolucja dla DeFi?
ZK‑KYC łączy tradycyjną weryfikację tożsamości (off-chain) z kryptograficznymi dowodami zero‑knowledge (on-chain). Użytkownik otrzymuje od zaufanego wydawcy atesty (poświadczenia) w portfelu, a następnie generuje krótki dowód (SNARK/STARK), który potwierdza warunek polityki (np. „18+ i nie z kraju X”), nie ujawniając metadanych.
- Selelektywne ujawnianie: udowadniasz, co trzeba – nie więcej.
- Niewspółdzielone dane: kontrakt weryfikuje dowód, ale nie przechowuje PII.
- Odwoływalność: wydawca może unieważnić poświadczenie (revocation list) bez deanonymizacji użytkownika.
Architektura referencyjna ZK‑KYC (Bezpieczeństwo • DeFi • Portfele)
Rola podmiotów
- Wydawca (Issuer): dostawca KYC/AML, tworzy podpisane atrybuty (wiek, rezydencja, status sankcji) i ich zobowiązania kryptograficzne (np. Merkle commitment lub Pedersen commitments).
- Użytkownik: trzyma atesty lokalnie (portfel mobilny/desktopowy, HSM/SE opcjonalnie) i generuje ZK‑dowody.
- Verifier on-chain: smart‑kontrakt (np. EVM) z kluczem weryfikatora, sprawdza poprawność dowodu i politykę.
- Oracle zgodności: aktualizuje na łańcuchu zakomitowane listy sankcyjne/revocation (hash/korzeń Merkle).
Przepływ (wysoki poziom)
- Off-chain KYC → wydawca generuje poświadczenie i publikuje jego commitment (hash) oraz listę odwołań (revocation root).
- Portfel generuje dowód ZK: „posiadam ważne poświadczenie spełniające politykę P”, oraz nullifier zapobiegający podwójnemu użyciu.
- Użytkownik woła kontrakt DApp z dowodem; kontrakt verify() sprawdza dowód, politykę, aktualność list, i zapisuje zużyty nullifier.
Które systemy ZK wybrać? (Narzędzia & Kalkulatory)
| System | Plusy | Minusy | Typowe koszty gas (EVM) |
|---|---|---|---|
| Groth16 | Najszybsza weryfikacja, najtańsza on-chain | Wymaga trusted setup per‑circuit | ~200–350k gas / dowód |
| PLONK | Uniwersalny setup, elastyczny | Wolniejsza weryfikacja niż Groth16 | ~500k–1.2M gas |
| STARK | Brak trusted setup, post‑kwantowy trend | Duże dowody, wyższy koszt weryfikacji | Częściej weryfikacja off‑chain + on-chain hash |
Uwaga: koszty zależą od implementacji i optymalizacji prekompilacji; na L2 (zk‑rollupy, optimistic) koszty są istotnie niższe.
Polityki zgodności jako obwody ZK (Regulacje & Prawo)
- Wiek 18+/21+: zakresy liczby (range proofs) bez ujawniania daty urodzenia.
- Rezydencja: dowód członkostwa w zbiorze (set membership) dla dozwolonych krajów.
- Sankcje/PEP: dowód „nie należy do zbioru” (non‑membership) względem zakomitowanej listy.
- Limit transakcji: nullifiery okresowe (np. 1/dzień) + rate‑limit nullifiers.
Takie podejście wspiera zasadę data minimization (RODO) oraz umożliwia implementację Travel Rule bez publikacji PII on‑chain – wymiana danych dzieje się wyłącznie kanałem zaszyfrowanym między VASP‑ami, zaś on‑chain widnieje tylko dowód spełnienia warunku.
Use‑case’y: DeFi, giełdy, stablecoiny (DeFi • Giełdy & Kantory • Stablecoiny)
1) DEX z prywatnym gate’em
- Wejście do puli tylko dla użytkowników z dowodem 18+ i brakiem sankcji.
- Bez allowlisty adresów: dowód „kim jestem” zastępuje „który adres mam”.
- Anty‑sybil: nullifier per użytkownik + stawka depozytowa (bond) dla nadużyć.
2) Stablecoin z mint/redeem pod ZK‑polityką
- Mint możliwy, gdy dowód potwierdza brak na liście sankcyjnej i pozytywny status KYC.
- Operator aktualizuje on‑chain korzenie list (sanctions root, revocation root) przez oracle.
- Audytowalność: każdy mint jest „zgodny”, lecz bez wycieku PII.
3) Launchpady (ICO/IDO/IEO)
- Dowód „rezydencja ∈ dozwolony region” oraz proof‑of‑cap (limit alokacji/dobę) bez ujawniania pełnej historii zakupów.
Implementacja krok po kroku (Start‑up’y & Projekty)
- Dobierz schemat ZK: Groth16 dla niskich kosztów on‑chain (EVM), PLONK dla elastyczności; rozważ L2.
- Model danych: zdefiniuj atrybuty (wiek, kraj, status sankcji), sposób ich commitmentu oraz mechanizm unieważnień.
- Wybierz wydawcę: dostawca KYC z API, podpisami i polityką prywatności zgodną z RODO (przechowywanie hashy, nie PII on‑chain).
- Obwód (circuit): zbuduj w Circom/Noir/Halo2 logikę polityki i nullifierów. Dodaj testy edge‑case (daty graniczne, rewokacje).
- Verifier: wdroż kontrakt weryfikujący i rejestr nullifierów; integruj z DApp/DEX/launchpadem.
- Oracle: automatyczna publikacja korzeni list (sankcje, revocation) z podpisem operatora.
- UX portfela: generowanie dowodu w tle, cache świadectw, ostrzeżenia o rewokacji, wsparcie QR/Deep Link.
- Audyt + testnet: proof‑fuzzing, property‑based tests, audyt kryptograficzny i smart‑kontraktów.
Bezpieczeństwo: ryzyka i mitigacje (Bezpieczeństwo)
- Udostępnianie poświadczeń: wiąż poświadczenie z kluczem urządzenia (device binding) + rate‑limit nullifiers.
- Korelacja transakcji: używaj unlinkable nullifiers per‑polityka i per‑okres; unikaj stałych identyfikatorów.
- Utrata klucza: social recovery / MPC; wydawca umożliwia re‑issue i unieważnienie starego atestu.
- Side‑channels: generacja dowodu lokalnie, stałoczasowe biblioteki, HSM/SE na urządzeniu.
- Aktualność list: wymuszaj maks. wiek korzeni (np. < 24 h) w kontrakcie verifier.
Porównanie podejść do zgodności
| Metoda | PII on‑chain | Prywatność | Użyteczność | Złożoność |
|---|---|---|---|---|
| Tradycyjny KYC + allowlista adresów | Wysoka (metadane, listy) | Niska | Średnia | Niska |
| Off‑chain podpisy dostawcy | Niska | Średnia (ryzyko korelacji u dostawcy) | Wysoka | Średnia |
| ZK‑KYC (privacy passport) | Bardzo niska | Wysoka | Wysoka | Średnio‑wysoka |
Powiązane: ZK‑Proof‑of‑Reserves (Makro & Rynek • Giełdy)
Oprócz KYC, zk‑PoR umożliwia giełdom dowód wypłacalności bez ujawniania pełnych sald użytkowników. Agregacja zobowiązań klientów i dowody zakresu dla aktywów/rezerw eliminują ryzyko deanonymizacji, a jednocześnie dają publiczny, kryptograficznie weryfikowalny wynik (np. „aktywa ≥ zobowiązania z marginesem X”). Pierwsze wdrożenia łączą Merkle‑drzewa z SNARK‑ami do weryfikacji pasywów bez ujawniania kont.
Checklist wdrożeniowy (dla CTO/PM)
- Polityka zgodności opisana jako warunki logiczne → przetłumaczona na constraints w obwodzie ZK.
- Wybór systemu dowodów i audyt kryptograficzny bibliotek.
- Proces rewokacji i aktualizacji list sankcyjnych (SLA, częstotliwość, podpisy).
- Metryki: koszt dowodu (ms), rozmiar dowodu (kB), gas verify, latency UX.
- Plan ciągłości działania dla wydawcy (multi‑issuer, failover).
FAQ & Support (FAQ & Support)
Czy ZK‑KYC jest legalne w UE?
Co do zasady tak – spełnia zasady minimalizacji danych (RODO), a zgodność AML osiąga się poprzez dowody spełnienia polityk i bezpieczną wymianę PII jedynie między uprawnionymi VASP‑ami. Kluczowe są audyty i aktualność list.
Co z wydajnością na L1?
Na Ethereum L1 koszty verify mogą być znaczące; praktyka to przeniesienie logiki na L2 (zk‑rollup) i publikacja wyniku na L1 lub użycie Groth16 dla najtańszego verify.
Czy mogę migrować z allowlist?
Tak. Utrzymuj okres przejściowy: akceptuj podpisy off‑chain i ZK‑dowody równolegle, komunikując termin „ZK‑only”.
Wnioski i następne kroki
Prywatność i zgodność nie muszą się wykluczać. ZK‑KYC pozwala DEX‑om, stablecoinom i giełdom zmniejszyć ryzyko regulacyjne, nie poświęcając anonimowości użytkowników. Największe ROI daje uruchomienie Pilot‑MVP na L2 w 4–6 tygodni:
- Tydz. 1–2: wybór schematu (Groth16/PLONK), makieta obwodu i UX portfela.
- Tydz. 3–4: integracja z wydawcą KYC, oracle list, kontrakt verifier na testnecie.
- Tydz. 5–6: audyt, testy obciążeniowe, zamknięta beta dla 500 użytkowników.
CTA: Jesteś CTO/Foundera? Zacznij od spisu polityk zgodności jako reguł logicznych i zamień je w constraints ZK. W razie potrzeby skorzystaj z audytu kryptograficznego przed produkcją.

