e‑Paszport + zk‑SNARK w krypto: prywatne airdropy i głosowania DAO bez KYC

Jak zwalczyć farmienie airdropów i sybile bez wprowadzania scentralizowanego KYC? Czy można udowodnić, że „jestem człowiekiem i mam ważny paszport”, nie ujawniając imienia, nazwiska ani numeru dokumentu? Ten artykuł pokazuje rzadko opisywany, ale szybko dojrzewający kierunek: dowód człowieczeństwa oparty na chipie e‑paszportu (NFC) i dowodach zerowej wiedzy (zk‑SNARK), działający na publicznych łańcuchach (Ethereum/L2) w sposób prywatny, zgodny z RODO i możliwy do wykorzystania przez DAO, airdropy, IDO, web3‑loge i sybil‑resistance.

Dlaczego to ma znaczenie teraz

– Airdropy na L2 i w DeFi tracą na farmieniu adresów, nawet 20–50% puli trafia do sybili.
– DAO robią się większe, a ich głosowania padają ofiarą klonowanych tożsamości.
– Regulacje (RODO, eIDAS 2.0) przesuwają nacisk na prywatność, minimalizację danych i samostanowienie tożsamości.
– Smartfony z NFC i biblioteki do ICAO 9303 (standard e‑paszportów) są już powszechne.

Jak to działa: architektura „e‑Paszport → zk‑SNARK → on‑chain”

1) Odczyt chipa e‑paszportu (NFC)

Użytkownik w aplikacji mobilnej (iOS/Android) przykłada paszport do telefonu. Chip zawiera DG1/DG2 (m.in. dane osobowe i zdjęcie), podpisane przez urząd państwowy (DS) w łańcuchu zaufania CSCA → DS. Aplikacja wykonuje Passive Authentication i weryfikuje podpisy bez wysyłania danych do chmury.

2) Kompilacja danych do obwodu kryptograficznego

Aplikacja wyciąga tylko minimalny zestaw atrybutów (np. „dokument ważny”, „kraj X”, „data ważności > dziś”). Następnie lokalnie buduje dowód zerowej wiedzy (zk‑SNARK), że:

• istnieje poprawnie podpisany wpis DG1/DG2 zgodny z ICAO 9303,
• klucze DS/CSCA pasują do opublikowanych rootów (lista urzędów),
• spełnione są polityki: np. „jedna tożsamość → jeden mint”, „obywatel z regionu Y”, „wiek ≥ 18”.

Żadne dane osobowe nie opuszczają urządzenia, a do łańcucha trafia jedynie skrótowy dowód matematyczny.

3) Weryfikacja dowodu on‑chain

Kontrakt weryfikujący (Ethereum/L2) ma wpisane klucze weryfikacyjne do danego systemu zk (np. Groth16, Plonk, Halo2). Po złożeniu dowodu przez użytkownika kontrakt w ułamku sekundy sprawdza jego poprawność i wydaje poświadczenie on‑chain w formie NFT/SBT lub po prostu zapisuje bit „uprzywilejowany adres”.

Zastosowania: airdropy, DAO, giełdy i portfele

• Airdropy & Giveaway’e: „One human, one claim” z geofencingiem (np. tylko dla mieszkańców EOG) bez ujawniania nazwisk.
• DAO: Głosowanie z wagą 1/1 dla unikalnych osób; ochronna warstwa anty‑sybilowa ponad token‑wagą.
• KYC‑lite na DEX/CEX: Zgodność z limitami (np. dzienny withdraw) przez dowód „wiek ≥ 18 i kraj ≠ sankcjonowany” – bez przechowywania kopii dokumentu.
• Portfele (Wallets): Tryb „Proof‑of‑Human” dla odzyskiwania konta (guardians), bez przejmowania kluczy.

Porównanie metod odporności na Sybil

Metoda	Prywatność	Koszt/Gaz	Wdrożenie	Odporność na Sybil
SMS/Email	Niska	Niski	Bardzo łatwe	Niska (farmione na masę)
Selfie + KYC	Niska (przechowywanie PII)	Średni/Wysoki	Integracja z dostawcami	Wysoka, ale scentralizowana
Biometria (tęczówka)	Kontrowersyjna	Wysoki (sprzęt)	Trudne, UX barierowy	Wysoka
CAPTCHA / social graph	Wysoka	Niski	Łatwe	Niska/Średnia
e‑Paszport + zk‑SNARK	Wysoka (zero‑knowledge)	Średni (dowód + weryfikacja)	Średnie (NFC + listy DS/CSCA)	Wysoka

Warstwa techniczna: wybór krzywych i systemu dowodów

• Krzywe: BN254 (kompatybilna z EVM, najtańsza w gazie) vs BLS12‑381 (silniejsze bezpieczeństwo, większe koszty), zaawansowani użyją zk‑SNARK recursion do łączenia wielu polityk.
• Systemy: Groth16 (małe dowody, setup per obwód), Plonk/Halo2 (uniwersalny setup, większe dowody, łatwiejsze iteracje).
• Gaz (L1 vs L2): L2 (Arbitrum/Optimism/zkSync/Scroll) drastycznie obniża koszt on‑chain weryfikacji.

Bezpieczeństwo i ryzyka

• Utrata/kradzież paszportu: system może wymagać okresowego ponowienia dowodu; opcjonalnie on‑chain „revocation list”.
• Zakres danych: obwód musi wymuszać minimalizację: tylko polityki (wiek/kraj/ważność), bez ujawniania PII.
• Trust anchors: listy kluczy CSCA/DS muszą być aktualizowane i audytowane (on‑chain registry + multisig/DAO).
• UX i wykluczenie: alternatywy dla osób bez e‑paszportów (mDL/eID, weryfikacja lokalna w urzędzie/partnerze).
• Anti‑replay: dowody muszą zawierać nonce/session ID i powiązanie z adresem portfela (np. podpis EIP‑191).

Minimalny MVP: krok po kroku

Metryki wydajności (orientacyjne na 2026)

Parametr	Telefon klasy średniej	L2 (Arbitrum/Optimism)	L1 (Ethereum)
Czas budowy dowodu (Groth16)	4–12 s	—	—
Rozmiar dowodu	~200–800 B	—	—
Weryfikacja on‑chain	—	~0,05–0,2 USD	~2–6 USD
Pamięć kontraktu (klucze DS/CSCA)	—	kilkadziesiąt kB	kilkadziesiąt kB

Zgodność z RODO i regulacjami

• Minimalizacja danych: brak PII on‑chain; tylko dowody predykatów (np. wiek/kraj/ważność).
• Celowość: osobne obwody/poświadczenia dla różnych celów (airdrop ≠ KYC‑limit na DEX).
• Prawa użytkownika: nic do „usuwania” on‑chain (brak PII); off‑chain klucze/dane pozostają lokalnie.
• eIDAS 2.0 i mDL: możliwość rozszerzenia na e‑ID Wallet i mobilne prawo jazdy (ISO 18013‑5) z selektywnym ujawnianiem (BBS+).

Przykład wdrożenia: Miejski DAO i lokalny airdrop

• Cel: 1 token obywatelski na mieszkańca, prawo głosu 1:1 w budżecie obywatelskim.
• Polityka dowodu: „obywatel kraju X” + „adres zamieszkania w gminie (z e‑ID/mDL)” + „wiek ≥ 18”.
• Rezultat: 93% spadek duplikatów w pre‑teście, brak przechowywania PII; czas claimu ~30 s.
• Fallback: punkt w bibliotece miejskiej z czytnikiem NFC i stewardem (self‑custody, bez kopii danych).

Integracja z DeFi, NFT i giełdami

• DeFi: tiered APY/limity na podstawie predykatów (np. rezydentura), bez ryzyka PII‑leak.
• NFT airdropy: claim tylko dla unikalnych osób; Soulbound dla proof‑of‑human bez transferu.
• Giełdy & Kantory: „KYC‑lite on‑chain” jako wstęp do pełnego KYC dopiero przy wyższych progach.

Alternatywy i komplementarne podejścia

• Verifiable Credentials (BBS+): selektywne ujawnianie atrybutów, dobre dla scenariuszy off‑chain → on‑chain.
• TEE (SGX/TrustZone): generowanie dowodów w bezpiecznym enclave; mniejsza transparencja, zależność sprzętowa.
• Graph‑based sybil scoring: social/przepływy kapitału; dobry sygnał pomocniczy, ale podatny na manipulacje.

Pro / Contra krótko

Aspekt	Pro	Contra
Prywatność	Zero‑knowledge, brak PII on‑chain	Złożoność audytów obwodów zk
Skalowalność	Szybka weryfikacja na L2	Koszt budowy dowodu na słabszych telefonach
Zgodność	Zbieżne z RODO/minimalizacją danych	Utrzymanie list CSCA/DS on‑chain
UX	Jednorazowe potwierdzenie, potem „tap & go”	NFC nie na wszystkich urządzeniach/rynkach

Najczęstsze pytania (FAQ)

Czy mogę sprzedać lub przenieść taki „proof‑of‑human”?

Poświadczenie powinno być nieprzenoszalne (SBT) i powiązane kryptograficznie z kluczem użytkownika (podpis/nonce).

Co jeśli paszport wygaśnie?

Wymagaj ponowienia dowodu (np. co 12 miesięcy). Kontrakt może wygaszać stary status po przekroczeniu TTL.

Czy projekt musi przechowywać dane?

Nie. PII pozostaje lokalnie; on‑chain jest jedynie dowód matematyczny predykatu.

Roadmapa wdrożenia dla projektów web3

1. Pilot na L2 (arbitralny airdrop/whitelist): wybór systemu zk, implementacja minimalnych polityk.
2. Audyt obwodów i kontraktów, bug bounty, formalne metody dla krytycznych części.
3. UX: wsparcie Passkeys/WebAuthn i wallet recovery; instrukcje „tap NFC”.
4. Rozszerzenie na mDL/eID i BBS+ dla scenariuszy wiek/kraj/wspólnota.
5. DAO‑governance: wspólne utrzymanie rejestru kluczy CSCA/DS i polityk.

Wnioski i działania

e‑Paszport + zk‑SNARK to praktyczny balans między prywatnością a zgodnością, który pozwala projektom kryptowalutowym ograniczyć sybile, udostępniać airdropy sprawiedliwiej i wzmacniać governance DAO – bez rezygnacji z idei samostanowienia. Jeśli prowadzisz DApp lub giełdę, zacznij od pilota na L2, z jedną prostą polityką (np. 1 osoba = 1 claim) i iteracyjnie rozszerzaj przypadki. Użytkownikom zapewnij jasny UX „dotknij paszportem telefon” i pełną transparentność co do braku przechowywania PII.

CTA: Szukasz gotowych komponentów? Rozważ integrację z bibliotekami NFC e‑paszportów oraz weryfikatorami Groth16/Plonk dla EVM. Zbuduj prywatny airdrop w 2–4 tygodnie pilotażu i zmierz spadek sybili w swoim projekcie.