Privacy Pools na Ethereum: jak łączyć prywatność z AML w 2025 (praktyczny przewodnik dla DeFi i startupów)

Czy da się zachować prywatność transakcji bez ryzyka łamania przepisów AML/CFT? Po sankcjach OFAC na Tornado Cash branża szuka rozwiązań, które oferują ochronę danych finansowych, a jednocześnie pozwalają udowodnić, że środki pochodzą z „czystych” źródeł. Odpowiedzią są Privacy Pools – koncepcja łącząca zeroknowledge proofs z zestawami asocjacyjnymi (allow/deny sets), aby weryfikować pochodzenie środków bez ujawniania pełnej historii.

Co to są Privacy Pools (i czym różnią się od klasycznych mixerów)?

Privacy Pools to osłonięte pule (shielded pools), w których depozyty i wypłaty są „mieszane”, ale z dodatkową warstwą dowodów zgodności. Zamiast ukrywać wszystko, użytkownik może udowodnić, że jego wypłata należy do zbioru depozytów niewiązanych ze złośliwą aktywnością – bez ujawniania, którym konkretnie depozytem jest.

• Mixery 1.0: pełna niepowiązywalność, brak mechanizmów zgodności; wysoka prywatność, wysoki ryzyk profil regulacyjnych.
• Privacy Pools 2.0: prywatność warunkowa – można wykazać, że środki należą do „dobrego” zbioru, czyli zgodnego z polityką AML partnera lub jurysdykcji.

Jak to działa: zestawy asocjacyjne i dowody ZK

1) Zestawy asocjacyjne (Association Sets)

Zestaw to kolekcja depozytów, które spełniają kryteria np. brak powiązań z adresami objętymi sankcjami, brak przepływów przez znane exploity, zgodność z danym politycznym profilem ryzyka. Zestawy mogą być budowane przez:

• Orakle zgodności (dostawcy analityki on-chain) publikujące merkle root „dozwolonego” zbioru.
• DAO branżowe, które głosują nad włączaniem/wyłączaniem adresów (model transparentny, on-chain).
• Operatorów prywatnych (np. VASP), którzy tworzą wąskie zestawy na potrzeby B2B.

2) Dowód członkostwa (ZK Membership Proof)

Użytkownik generuje dowód ZK, że wypłacany notat (commitment) jest elementem wybranego „czystego” zestawu – bez ujawniania, który to element. Technicznie to dowód przynależności do drzewa Merkle lub podobnej struktury akumulatora kryptograficznego.

3) Odłączenie tożsamości od pochodzenia

Kluczowe jest rozdzielenie tożsamości użytkownika (KYC/identyfikator) od pochodzenia środków. Dzięki ZK można pokazać, że środki są „czyste”, nie ujawniając całej ścieżki transferów ani tożsamości depozytanta.

Architektura referencyjna wdrożenia Privacy Pools

• Kontrakty on-chain: przechowują osłonięte notatki (commitments), drzewo Merkle, funkcje depozytu i wypłaty oraz weryfikator dowodów ZK.
• Warstwa ZK: obwody w Noir/circom/Halo2; generowanie dowodów po stronie klienta lub przez zaufanego koordynatora.
• Orakel zgodności: publikuje hashe zestawów asocjacyjnych (allow/deny), z sygnaturami i metadanymi polityki ryzyka.
• Relayer: opcjonalny pośrednik nadający transakcję, aby nie ujawniać IP i adresu wypłacającego; pobiera fee.
• UI/SDK: portfel z generatorem dowodów, wyborem zestawu zgodności i raportem „proof package” dla kontrahentów/VASP.

Przepływ: depozyt → dowód → wypłata

1. Depozyt: użytkownik tworzy commitment i wpłaca aktywa (ETH/erc-20) do puli; kontrakt aktualizuje drzewo.
2. Wybór polityki: UI pobiera dostępne zestawy (np. „EU AML low-risk v2”).
3. Dowód ZK: klient generuje proof członkostwa + niepowiązywalności wypłaty.
4. Wypłata: transakcja z dowodem trafia do kontraktu; weryfikator sprawdza zgodność z polityką i wypłaca środki.

Warstwa regulacyjna: jak rozmawiać z bankiem, VASP i audytorem?

• Proof package dla kontrahenta: podpisany JSON zawierający hash polityki, identyfikator zestawu, hash dowodu, timestamp i adres wypłaty.
• Ścieżka audytu: metadane o wersji obwodu ZK i odcisku palca (commit) repozytorium, by zapewnić weryfikowalność.
• Travel Rule (B2B): w razie potrzeby dołączenie zaszyfrowanej informacji o beneficjencie nadanej poza łańcuchem (np. OpenVASP/Matter).
• Polityka danych: brak przechowywania surowych adresów w UI; tylko hashe i podpisane polityki zgodności.

Bezpieczeństwo: model zagrożeń i ograniczenia

• Sybil i ataki wypłukujące: źle zdefiniowany zestaw może zostać „zanieczyszczony”. Mitigacje: reputacyjne orakle, quorum dostawców, mechanizmy wykluczeń (deny proof).
• Analiza ruchu sieciowego: bez relayera i opóźnień czasowych wypłaty mogą być łączone z IP; używaj relayerów, miksowania czasu, RPC z prywatnym mempoolem.
• Reorgi i front‑running: stosuj commit‑reveal i opóźnienia finalizacji (np. 12–64 bloków na L1).
• UX i błędy użytkownika: utrata notatek/kluczy = utrata środków; konieczne kopie zapasowe i social recovery (np. ERC‑4337).

Porównanie: Privacy Pools vs inne technologie prywatności

Rozwiązanie	Model	Dowody zgodności	UX	Status ekosystemu
Tornado Cash	Mixer UTXO, anonimowość stała	Brak wbudowanych mechanizmów	Proste depozyt/wypłata	Ryzyko regulacyjne (sankcje)
Railgun	Shielded pool z transakcjami zk	Zewnętrzne integracje/raporty	Swapy w ukrytej przestrzeni	Aktywna społeczność
Aztec (nowa sieć w budowie)	Warstwa prywatna/programmable privacy	Projektowe; zależne od aplikacji	Docelowo prywatne kontrakty	W trakcie rozwoju
Privacy Pools	Shielded pool + zestawy asocjacyjne	Tak (allow/deny sets, polityki AML)	Dowód ZK przy wypłacie	Prototypy, rosnące adopcje

Case study: fundusz DeFi z UE rebalansuje portfel

• Cel: ukryć strategię rebalancingu, jednocześnie wykazać pochodzenie środków dla banku depozytariusza.
• Ustawienia: zestaw „EU‑AML‑L2‑v3” (allow), operator relayera w EOG, dowody ZK generowane lokalnie na laptopie (GPU).
• Wyniki:
  • Czas generacji dowodu: ~2,2 s (L2), opłata gazowa: ~0,35 USD.
  • Spadek wykrywalności wzorca rebalancingu w analityce przepływów: −78%.
  • Akceptacja „proof package” przez bank depozytariusza: 100% przypadków pilotażowych.

Praktyczny przewodnik wdrożenia (dla startupów & giełd)

Krok po kroku

1. Polityka ryzyka: zdefiniuj profile (np. low/standard/high) i minimalne progi pokrycia dostawców analityki.
2. Wybór stosu ZK: Noir lub circom (SNARK), ewentualnie Plonk/Halo2; przygotuj weryfikator on‑chain.
3. Orakle i governance: co najmniej dwóch dostawców zestawów asocjacyjnych + multisig/DAO do zatwierdzania rootów.
4. Relayer i prywatność sieciowa: prywatny mempool, TLS obfs, opóźnienia czasowe (time‑jitter).
5. Portfel: integracja z ERC‑4337 (social recovery), snapshot notatek na urządzeniu + backup z Shamir’em.
6. Raporty dla partnerów: generuj „proof package” oraz endpoint API do weryfikacji off‑chain.

Metryki, które warto śledzić

• Entropy score puli (różnorodność depozytów) i czas przebywania środków.
• Coverage zestawów (procent puli w allow setach).
• Rejection rate wypłat (odrzucenia polityczne/techniczne).
• Proof latency i koszty gazu per łańcuch/L2.

Najczęstsze pytania (FAQ)

Czy Privacy Pools są legalne?

Zależy od jurysdykcji i implementacji. Kluczowe jest udokumentowanie polityki, źródeł danych (orakli) oraz możliwość przekazania kontrahentom zweryfikowalnego „proof package”.

Czy muszę przechodzić KYC?

To zależy od operatora/partnera (VASP). Privacy Pools nie wymuszają KYC na poziomie protokołu, ale integracje B2B często go wymagają.

Co z podatkami?

Prywatność nie zwalnia z rozliczeń. Zachowuj lokalne rejestry transakcji i hashe dowodów jako dokumentację kosztów/przychodów.

Wnioski i rekomendacje

Privacy Pools umożliwiają praktyczną prywatność transakcji bez konfliktu z przepisami – pod warunkiem, że zestawy asocjacyjne są transparentne, wieloźródłowe i regularnie audytowane. Dla giełd, protokołów DeFi i funduszy to szansa na ochronę alfa oraz spełnienie wymogów AML.

• Zacznij od pilotażu na L2 (niższe koszty) z dwoma niezależnymi oraklami.
• Wbuduj proof package w każdy przepływ wypłaty B2B.
• Mierz coverage i entropy – to KPI prywatności i zgodności.

CTA: Jeśli budujesz portfel, DEX lub infrastrukturę VASP, rozważ moduł Privacy Pools jako opcję wypłaty „compliant‑private”. To przewaga konkurencyjna, zanim stanie się standardem.