ZK‑KYC dla DeFi: Prywatna zgodność AML bez ujawniania tożsamości (praktyczny przewodnik dla giełd, DAO i protokołów RWA)

Kategorie: Regulacje & Prawo, DeFi, Bezpieczeństwo, Web3 & DAO, Narzędzia & Kalkulatory

Wstęp: Czy zgodność z AML musi oznaczać koniec prywatności?

MiCA w UE, Travel Rule, presja organów nadzoru – to fakty. Ale równie realne są oczekiwania użytkowników DeFi: kontrola nad danymi i płynność bez tarcia. Coraz więcej zespołów bada ZK‑KYC – mechanizm, który pozwala udowodnić, że jesteś zweryfikowany (KYC/AML), nie ujawniając swoich danych żadnemu smart‑kontraktowi ani losowym węzłom. Ten artykuł pokazuje, jak to działa, jakie ma koszty, gdzie są ryzyka i jak wdrożyć to w giełdzie DEX, DAO czy protokole RWA.

Co to jest ZK‑KYC i jak działa od środka

Definicja: ZK‑KYC to wzorzec, w którym wydawca poświadczeń (KYC provider) nadaje użytkownikowi zaszyfrowane poświadczenie, a użytkownik lokalnie generuje dowód zerowej wiedzy, że spełnia politykę zgodności (np. KYC zrobione, nie jest na liście sankcyjnej, ma 18+, rezydencja w dozwolonej jurysdykcji). Smart‑kontrakt weryfikuje dowód, nie poznając żadnych danych osobowych.

3 kluczowe komponenty

• Poświadczenie (VC/credential): podpis wydawcy na zestawie atrybutów (wiek, kraj, status AML). Często w formacie Verifiable Credentials lub Soulbound + ZK.
• Dowód ZK: obwód (circuit) sprawdza zasady polityki: np. age ≥ 18, country ∈ whitelist, address ∉ blacklist, bez ujawniania wartości.
• Weryfikator on‑chain: kontrakt verifier (Groth16/Plonk) zwraca true/false. Logika dostępu (guard) pozwala lub blokuje transakcję.

Architektura przepływu

1. Onboarding: Użytkownik robi KYC u zaufanego wydawcy i otrzymuje zaszyfrowane poświadczenie do portfela SSI.
2. Dowód: Portfel generuje dowód ZK spełnienia polityki (lokalnie lub z pomocą zaufanego kompilatora ZK w trybie klientowskim).
3. Weryfikacja: Transakcja do DEX/DAO zawiera krótkie dane publiczne (np. korzeń Merkle listy wydawców, nullifier przeciwko Sybil) i dowód ZK.
4. Decyzja: Kontrakt guard weryfikuje dowód i przepuszcza logikę swapu, głosowania lub mintu RWA.

Dlaczego to ma znaczenie dla DeFi (3 główne korzyści)

• Prywatność by design: brak przechowywania danych osobowych on‑chain, mniejsza powierzchnia ataku.
• Kompozytowalność: ten sam dowód działa w wielu aplikacjach (DEX, launchpady, RWA), co upraszcza UX i zgodność.
• Zgodność z przepisami: selektywne ujawnianie spełnienia polityk (MiCA/AML) bez masowej identyfikacji.

Przegląd rozwiązań: które narzędzie do czego?

Rozwiązanie	Technologia ZK	Model poświadczeń	Typowe użycie	Wady/Ograniczenia
Polygon ID (iden3)	Circom + Groth16	VC z selektywnym ujawnieniem	Gating do DEX/DAO, proof of age/residency	Wymaga kompilacji circuitów i utrzymania schematów
Sismo Connect	ZK membership/aggregations	Grupowe poświadczenia/zkBadges	Whitelisting do airdropów, prywatne sygnały reputacji	Skupienie na grupach; złożone polityki AML wymagają rozszerzeń
Semaphore‑style	Merkle membership + nullifiers	Anonimowa przynależność	Anty‑Sybil, prywatne głosowania DAO	Nie zapewnia KYC bez warstwy VC
VC + ZK (Verite/SSI)	Różne (Groth16/Plonk)	Wydawca KYC, off‑chain VC	RWA, permissioned‑DeFi, Travel Rule‑friendly	Zarządzanie odwołaniami i listami sankcyjnymi

Jak włączyć ZK‑KYC do DEX/DAO – wzorzec kontraktowy

Najczęściej stosuje się warstwę guard – cienki kontrakt stojący przed rdzeniem aplikacji.

1. Verifier.sol: zdeployowany weryfikator (np. Groth16) z kluczem weryfikacji.
2. ComplianceGuard.sol: funkcja checkProof() + polityka (korzeń Merkle wydawców, korzeń listy sankcyjnej, timestamp ważności).
3. Hook: wywołanie guarda w beforeSwap(), beforeVote(), beforeMint().

Minimalny szkic logiki guard (pseudokod)

function beforeSwap(bytes proof, PublicInputs pi) returns (bool) {
  require(verifier.verify(proof, pi));
  require(issuersRoot == pi.issuersRoot);
  require(block.timestamp <= pi.expiry);
  require(!nullifierUsed[pi.nullifier]);
  nullifierUsed[pi.nullifier] = true; // anty‑Sybil / re‑use control
  return true;
}

Uwaga: nullifier pozwala wykryć ponowne użycie tego samego uprawnienia, np. jednorazowy airdrop lub ograniczenie liczby głosów.

Listy sankcyjne bez wycieku danych: jak to się robi w ZK

• Komitment listy: wydawca publikuje hasz korzenia Merkle (Poseidon/Keccak) listy dozwolonych wydawców/poświadczeń.
• Negatywne sprawdzenia: dowód ZK może udowodnić, że adres nie znajduje się w zbiorze (np. poprzez set non‑membership proof), bez ujawnienia adresu.
• Aktualizacje: rotacja korzeni odbywa się poprzez adminless timelock albo DAO – minimalizując zaufanie.

Koszty i wydajność: co trafi do gazu, a co do telefonu

• Wielkość dowodu: Groth16 ~128–192 bajty public input + ~200–300 bajtów dowodu; Plonk/PlonKish ~1–2 kB. Weryfikacja on‑chain: kilkadziesiąt tys. gazu (Groth16) do kilkuset tys. gazu (Plonk), zależnie od łańcucha.
• Generowanie dowodu: telefon‑klient 1–5 s dla mniejszych obwodów; laptop 200–800 ms. W L2 (np. zkEVM/OP‑Stack) koszt weryfikacji jest zwykle dużo niższy.
• Cache i batching: można łączyć wiele akcji pod jednym dowodem (np. approve + swap), ograniczając koszty.

Ryzyka i wektory ataku (i jak je ograniczyć)

• Kradzież poświadczeń: używaj portfeli z izolacją klucza (MPC/HW), przypisuj credential do device binding.
• Brak odwołań: wymagaj obsługi revocation registry; proof musi zawierać sprawdzenie niewidocznego (dla kontraktu) statusu odwołania.
• Centralizacja wydawców: wiele niezależnych issuerów + DAO do zarządzania listą korzeni (governance, timelock, multisig).
• Ataki DoS gazowe: zapewnij pre‑check tanich warunków (np. deadline, nonce) przed weryfikacją ZK.
• Jurysdykcje: polityki regionów muszą być regularnie aktualizowane; automatyzuj pobieranie reguł.

Prawo: ZK‑KYC a Travel Rule i MiCA

Travel Rule wymaga wymiany danych nadawca‑odbiorca przy transferach powyżej progów. ZK‑KYC nie przesyła danych on‑chain, ale może połączyć transakcję z off‑chainowym kanałem wymiany danych między VASP‑ami (np. przez VC‑handshake i audit trail u custodianów). MiCA nie zakazuje prywatności – liczy się możliwość wykazania zgodności. Dlatego architektury hybrydowe (on‑chain dowód spełnienia polityki + off‑chain możliwość ujawnienia pod nakazem) stają się standardem dla RWA i permissioned‑DeFi.

Case study (hipotetyczne): DEX z filtrem jurysdykcyjnym i anty‑Sybil

• Polityka: wiek ≥ 18, rezydencja ∉ zakazane kraje, brak na listach sankcyjnych, 1 konto‑1 człowiek.
• Implementacja: Polygon ID dla atrybutów wieku/kraju; Semaphore‑style nullifier dla anty‑Sybil; korzeń Merkle odwołań wydawców aktualizowany co 24h.
• Wynik: 97% transakcji przechodzi pre‑check lokalnie, średni koszt weryfikacji ~65k gazu na L2; spadek bot‑sybili w programach liquidity mining o 82%.

Jak zacząć: plan wdrożenia w 14 dni

1. Dzień 1–2: Wybór stacku (np. iden3 + Groth16) i zakresu polityk. Sprawdzenie licencji i wsparcia SDK.
2. Dzień 3–5: Prototyp verifier.sol i ComplianceGuard.sol na testnecie. Konfiguracja korzeni Merkle wydawców.
3. Dzień 6–9: Integracja portfela użytkownika (SSI/SDK mobilny), generator dowodów, UX fallback (off‑ramp).
4. Dzień 10–12: Testy wydajności (czas dowodu, gaz), fuzzing kontraktów, monitoring błędów.
5. Dzień 13–14: Polityka odwołań i rotacji kluczy, audyt bezpieczeństwa, bug bounty.

Metryki sukcesu: co mierzyć po wdrożeniu

• CRP (Compliance‑Related Pass‑rate): odsetek transakcji przechodzących walidację ZK bez wsparcia supportu.
• Średni czas dowodu po stronie użytkownika: mediana < 1 s na telefonach z ostatnich 3 lat.
• Spadek nadużyć: wskaźnik multi‑claim w airdropach, farmienie punktów, sybil‑głosowania.
• Koszt gazu na weryfikację: cel: < 100k gazu na L2/L3.

FAQ: najczęstsze obawy zespołów

• Czy to wymaga przechowywania danych osobowych on‑chain? Nie. On‑chain trafia tylko dowód i niewielkie publiczne wejścia (np. korzenie Merkle).
• Co jeśli issuer zostanie wyłączony? Multi‑issuer + mechanizm odwołań i rotacji korzeni przez DAO minimalizuje ryzyko pojedynczego punktu awarii.
• Czy ZK spowalnia UX? Dobrze zbudowane SDK generują dowody w tle; batching i cache poprawiają wrażenia użytkownika.

Wnioski i następne kroki

ZK‑KYC to praktyczna droga do pogodzenia zgodności z prywatnością w DeFi, RWA i DAO. Pozwala spełnić wymagania regulatorów, jednocześnie ograniczając ryzyko wycieków danych i farmienia sybil. Największe wyzwania to zarządzanie wydawcami i ergonomia dowodów po stronie użytkownika – oba obszary szybko dojrzewają.

CTA: Jeśli prowadzisz DEX/DAO/RWA, rozważ pilotaż na testnecie: wdroż guard, dodaj minimalną politykę (wiek + rezydencja), zmierz CRP i koszt gazu. Po dwóch sprintach będziesz wiedzieć, czy ZK‑KYC podnosi Twój współczynnik zgodności przy akceptowalnym wpływie na UX.