Dowody Zerowej Wiedzy: Jak Zcash i Altcoiny Zapewniają Pełną Prywatność

Dowody zerowej wiedzy (ZKP) stały się jednymi z najbardziej transformujących prymitywów kryptograficznych we współczesnych systemach blockchain. W przeciwieństwie do artykułów wysokiego poziomu, które rozmywają istotę techniczną, ten tekst rozbija prawdziwe mechanizmy, prawdziwą matematykę i rzeczywiste ograniczenia systemów prywatności opartych na ZK używanych w altcoinach, takich jak Zcash, Aleo i Firo — bez abstrakcji i marketingowego bełkotu.

1. Czym właściwie jest dowód zerowej wiedzy (matematycznie)

ZKP to interaktywny lub nieinteraktywny protokół pozwalający dowodzącemu P przekonać weryfikatora V, że stwierdzenie jest prawdziwe bez ujawniania jakichkolwiek informacji poza prawdziwością tego stwierdzenia.

Formalnie ZKP musi spełniać:

1. Kompletność: Jeśli stwierdzenie jest prawdziwe, uczciwy weryfikator je zaakceptuje.
2. Rzetelność: Złośliwy dowodzący nie może przekonać weryfikatora o fałszywym stwierdzeniu.
3. Zerowa wiedza: weryfikator nie dowiaduje się niczego poza prawdziwością.
   Zerowa wiedza jest definiowana za pomocą symulatora S:
   Jeśli S może wygenerować nieodróżnialny zapis bez znajomości świadka, protokół jest zerowiedzowy.

W zastosowaniach blockchain stwierdzenie zwykle wygląda tak:

„Znam sekret (świadka), który hashuje do tej publicznej wartości.”
lub
„Posiadam monety należące do zobowiązań, nie ujawniając, które dokładnie.”

2. Schematy zobowiązań — Podstawa monet prywatności ZK

Większość monet prywatności używa zobowiązań do ukrywania wartości transakcji i własności.

Zobowiązanie definiuje się jako:
C = Commit(value, randomness)

Właściwości:

• Ukrywanie: wartość nie może być wyodrębniona z C.
• Wiążące: dowodzący nie może później zmienić wartości.

Popularne schematy:

• Zobowiązania Pedersena:
  C = v·G + r·H w grupach krzywych eliptycznych (używane w Firo Lelantus / MimbleWimble).
• Zobowiązania oparte na SHA-256: używane w niektórych obwodach zk-SNARK dla efektywności.

Zobowiązania Pedersena pozwalają na:

• Homomorfizm addytywny: C1 + C2 = Commit(v1 + v2, r1 + r2).
  → W ten sposób poufne transakcje zachowują całkowitą podaż.

3. zk-SNARK i zk-STARK — Dlaczego monety prywatności używają jednego lub drugiego

3.1 zk-SNARKs (Succinct Non-Interactive Argument of Knowledge)

Używane w:

• Zcash (Sapling)
• Horizen
• Firo Lelantus Spark

Właściwości:

• Bardzo małe dowody (~192 bajty w Sapling).
• Bardzo szybka weryfikacja (~10 ms).
• Wymaga zaufanej konfiguracji (problem toksycznych odpadów).
• Używa parowania krzywych eliptycznych (głównie BLS12-381).

Szczegół techniczny często pomijany:
Zcash pierwotnie używał BN254 (Jubjub), ale przeszedł na BLS12-381 ze względu na słabości bezpieczeństwa podgrup i obawy dotyczące marginesów bezpieczeństwa 128-bit.

3.2 zk-STARKs (Scalable Transparent ARguments of Knowledge)

Używane w:

• Aleo
• StarkNet (nie moneta, ale istotne)

Właściwości:

• Brak zaufanej konfiguracji.
• Bezpieczne wobec komputerów kwantowych (oparte na funkcjach hashujących, nie na parowaniach).
• Dowody są duże (~100–500 KB).
• Weryfikacja jest szybka i skalowalna.

Mało znany fakt:
Wczesne dowody testnetu Aleo były tak duże, że przepustowość sieci stała się wąskim gardłem; optymalizacje zmniejszyły rozmiar dowodu o ~80% przed uruchomieniem mainnetu.

4. Gdzie pojawia się zerowa wiedza w transakcji prywatności

Altcoin skupiający się na prywatności zazwyczaj używa ZKP dla jednego lub więcej z poniższych:

4.1 Ukrywanie nadawcy

Mechanizmy:

• Podpisy pierścieniowe (Monero — nie ZK, ale powiązane).
• Dowody członkostwa zerowej wiedzy (Zcash, Lelantus).

Przykład (uproszczony):
Dowodzący pokazuje, że zna klucz prywatny jednego elementu w zbiorze zobowiązań bez ujawniania, który to.

4.2 Ukrywanie odbiorcy

Użycie adresów stealth lub adresów zróżnicowanych.
Zcash używa adresów płatniczych i kluczy podglądu przychodów, aby umożliwić selektywną przejrzystość.

4.3 Ukrywanie kwoty

Zobowiązania Pedersena + ZKP, który:

• sumuje zobowiązania poprawnie,
• kwoty są nieujemne (dowody zakresu),
• nie wprowadza inflacji.

Starsze dowody zakresu (Poufne transakcje, propozycje Bitcoina):
~2–3 KB na wyjście.

Bulletproofs:
~700 bajtów na wyjście (Monero używa tych).

zk-SNARKs:
Zcash ukrywa kwoty dowodami o łącznym rozmiarze zaledwie 192 bajtów.

5. Konkretne przykłady transakcji: Zcash Sapling

Zaszyfrowana transakcja Zcash Sapling dowodzi:

1. Wydawca posiada notę (ukrytą monetę).
2. Nota nie została wcześniej wydana (nullifier ZKP).
3. Całkowita wartość wyjściowa równa się całkowitej wartości wejściowej (balance ZKP).
4. Wyjściowe noty są poprawnie sformowane jako zobowiązania.

Co faktycznie jest udowadniane?

Dowodzący buduje obwód obejmujący:

• Hashy (BLAKE2s) zobowiązań not
• Hashy Pedersena
• Autoryzacja ścieżki drzewa Merkle
• Obliczenia nullifier
• Równania zachowania wartości

Całkowita złożoność obwodu to ~2 miliony ograniczeń.
Generowanie dowodu używa Groth16, wymagając:

• Obliczeń FFT
• Mnożeń wieloskalowych
• Parowania krzywych eliptycznych

Na laptopie wygenerowanie jednego dowodu zajmuje ~1–2 sekundy (optymalizowane na krzywych Pallas/Vesta w Orchard).

Rzadko wspominany fakt:
Obwód Sapling używa dekompozycji bitów dla ograniczeń zakresu, znacznie zwiększając liczbę ograniczeń; Orchard zastąpił to arytmetyzacją typu PLONK Halo 2, znacznie redukując złożoność.

6. Lelantus Spark (Firo) — Niedoceniany system ZK

System „Spark” Firo jest jednym z najbardziej zaawansowanych technicznie, ale mniej znanych publicznie.

Kluczowe innowacje:

• Czysto ZK (bez podpisów pierścieniowych).
• Używa Dowodów typu One-of-Many:
  Dowodzący udowadnia, że posiada jedną notę spośród N, a rozmiar dowodu jest logarytmiczny względem N.
• Brak zaufanej konfiguracji.
• Kwoty ukryte za pomocą zobowiązań Pedersena.
• Adresy Spark są niepowiązywalne nawet dla węzłów wykonujących analizę łańcucha.

Spark obejmuje również:

• Odświeżanie adresów:
  Właściciele mogą aktualizować adresy, zachowując kontrolę, co zmniejsza wyciek metadanych.
• Uniwersalne wiązanie:
  Zapobiega złośliwej inflacji poprzez wielokrotne powiązania kryptograficzne z tym samym zobowiązaniem.

Mało znany fakt:
Projekt Spark zmniejsza powierzchnię ataku spowodowaną „dowodami częściowego wydania”, które wcześniej umożliwiały powiązanie niektórych protokołów prywatności według określonych heurystyk.

7. Aleo — Wykonywanie ZK, nie tylko transakcje ZK

Aleo to nie tylko prywatna moneta — to blockchain L1 z w pełni prywatnymi smart kontraktami.

Jak to działa:

• Programy są pisane w Leo, DSL podobnym do Rust, kompilowanym do R1CS.
• Wykonanie odbywa się off-chain.
• Generowany jest dowód zk-STARK reprezentujący cały ślad wykonania.
• Górnicy/walidatory weryfikują dowód i aktualizują stan.

Jest to efektywnie:

Globalna, weryfikowalna, zaszyfrowana maszyna wirtualna.

Mało znany fakt:
Aleo używa hybrydowego systemu dowodów:

• STARK dla przejrzystości
• Rekurencja SNARK (styl Kimchi/Halo) dla zmniejszenia rozmiaru dowodu

Takie podejście hybrydowe jest rzadkie i technicznie skomplikowane.

8. Dlaczego ZKP są trudne do implementacji na skalę altcoinów

8.1 Koszt dowodzenia

Generowanie dowodu zk-SNARK wymaga:

• Milionów ograniczeń arytmetycznych
• FFT nad dużymi polami skończonymi
• Wieloskalarowych mnożeń EC

Nawet z optymalizacjami:

• Generowanie dowodu może być ograniczone przez CPU.
• Zużycie pamięci jest wysokie (kilkaset MB na starszych systemach).

8.2 Problemy z zaufaną konfiguracją

Monety używające Groth16 wymagają zaufanej konfiguracji.
Jeśli toksyczne odpady nie zostaną zniszczone, atakujący może:
→ tworzyć nieograniczoną liczbę fałszywych monet
bez wykrycia.

Zcash faktycznie używał ceremonii wielopodmiotowej; ostateczne toksyczne odpady zostały (rzekomo) zniszczone poprzez ekstrakcję entropii fizycznej i rygorystyczne OPSEC…
Ale jeden nieuczciwy uczestnik wystarczyłby, aby skompromitować system.

8.3 Błędy w obwodach mogą zabić monetę

Jeśli obwód systemu prywatności ma niezauważony błąd umożliwiający inflację, węzły nie mogą wykryć fałszywych monet.
Zdarzyło się to we wczesnym Zcash (naprawione przed wykorzystaniem).

Subtelny błąd w ograniczeniach arytmetycznych może zbankrutować cały ekosystem.

9. Przyszłość monet ZK

Technicznie prawdopodobne trendy:

• Dowody rekurencyjne umożliwiające grupową weryfikację transakcji.
• Hybrydowe systemy STARK–SNARK, jak w Aleo, w celu zmniejszenia rozmiaru dowodu.
• Akceleracja sprzętowa za pomocą GPU i ASIC dla generowania dowodów.
• Programowalna prywatność, umożliwiająca selektywne ujawnianie.
• ZK obwody przyjazne dla urządzeń mobilnych (obecne obwody są zbyt ciężkie).

Niektóre eksperymenty badawcze:

• ZK-szyfrowane mempoole
• Silniki dopasowujące P2P oparte na ZK
• DEX-y oparte na ZK bez ujawniania ksiąg zleceń

Są one już prototypowane w projektach takich jak Penumbra i Mina.

10. Ataki w rzeczywistości i słabości w monetach prywatności opartych na ZK

Chociaż systemy ZK mają na celu zapewnienie prywatności i poprawności, historia pokazuje, że złożoność kryptograficzna często tworzy nowe powierzchnie ataku.

Poniżej znajdują się najważniejsze rzeczywiste, udokumentowane i często niedoceniane problemy.

10.1 Wrażliwość na fałszywe monety Zcash (2018)

Odkryto poważną lukę w obwodzie Zcash Sapling:

• Parametr w obwodzie zk-SNARK był niepoprawnie ograniczony.
• Pozwalało to atakującemu na tworzenie fałszywych monet shielded.
• Monety te byłyby nie wykrywalne, ponieważ wszystkie wartości shielded są ukryte.

Kluczowe fakty:

• Odkryte przez kryptografa Ariela Gabizona.
• Naprawione w Sapling przed publicznym wykorzystaniem.
• Zcash nigdy nie ujawnił, ile (jeśli w ogóle) fałszywych monet zostało utworzonych w puli Sprout, ponieważ matematycznie nie da się tego sprawdzić.

Ten incydent jest najsilniejszym realnym przykładem:

Błędy systemów ZK = katastrofalna, niewykrywalna inflacja.

To również zmotywowało zmiany protokołu w kierunku:

• Nowszych obwodów (Sapling, Orchard)
• Bardziej modułowych systemów ograniczeń
• Więcej przeglądów przed wdrożeniem

10.2 Atak akademicki na MimbleWimble (2019)

MimbleWimble (używany przez Grin/Beam) nie używa zk-SNARK, ale wykorzystuje zobowiązania Pedersena + cut-through + brak adresów.

Badacz (Ivan Bogatyy) wykazał:

• Monitorując sieć w czasie rzeczywistym z ~200 węzłami,
• Mógł powiązać 96% transakcji Grin z nadawcami i odbiorcami.

Nie była to wada samej matematyki ZK, lecz błąd w:

• Modelu agregacji transakcji
• Braku „fałszywych” wejść
• Ujawnianiu metadanych na poziomie sieci

Ważna lekcja:

Prywatność nie zależy tylko od dowodów — topologia sieci może ujawniać tożsamość nawet przy idealnej matematyce ZK.

10.3 Wycieki czasowe w implementacjach proverów

Niektóre implementacje ZKP (szczególnie starsze obwody SNARK) ujawniają wzorce czasowe:

Przykład:

• Podczas dowodzenia transakcji z wieloma wejściami CPU lub GPU generują wykrywalne zmiany w czasie.
• Obserwator z dostępem do węzła może oszacować liczbę wydawanych not i zmniejszyć zestawy prywatności.

Częściowo obserwowano to w wczesnych klientach Zcash przed optymalizacją.

Powód:
Proverzy SNARK często używają FFT i wieloskalarowych mnożeń, gdzie struktura zależna od wejścia wpływa na czas wykonywania.

10.4 Ryzyka wielokrzywiznowe w systemach hybrydowych

Projekty takie jak Aleo używają:

• STARK → następnie kompresja przez rekurencję SNARK (Kimchi/Halo/KZG zobowiązania wielomianowe).

Rzadko omawiane ryzyko:
Jeśli którakolwiek krzywa lub schemat zobowiązań wielomianowych w stosie rekurencji zawiedzie,
cały system staje się podatny.

Ta „wielokrzywiznowa kruchość” prawie nigdy nie jest wspominana w materiałach marketingowych.

11. Projektowanie obwodu ZK dla monety prywatności (ogólny plan)

Oto rzeczywiste techniczne zestawienie, jak deweloperzy faktycznie budują protokół prywatności ZK.

Krok 1: Wybór modelu arytmetycznego

• R1CS (Zcash Sapling)
• PLONKish (Halo 2, Orchard)
• AIR/FRI (STARKs)

Każdy ma kompromisy:

• R1CS → łatwe do analizy, ciężkie ograniczenia.
• PLONK → elastyczne, obsługuje niestandardowe bramki.
• STARK → brak zaufanej konfiguracji, ale większe dowody.

Krok 2: Wybór pola skończonego

Przykłady:

• Pole skalarne BLS12-381 (255-bit) dla SNARKów.
• Pole Goldilocks (przyjazne 64-bit) dla STARKów (używane w Polygon Miden, RISC Zero).

Wybór pola wpływa bezpośrednio na:

• Rozmiar obwodu
• Akcelerację sprzętową
• Szybkość generowania dowodu

Krok 3: Budowa zobowiązań kryptograficznych

Typowy altcoin używa:

• Zobowiązań Pedersena dla wartości
• Zobowiązań opartych na SHA dla ścieżek Merkle
• Hash Poseidon/Rescue w obwodach (przyjazny FFT)

Mało znany szczegół:
Zcash odeszło od SHA-256 w obwodach, ponieważ SHA-256 jest ekstremalnie kosztowny w liczbie ograniczeń — ponad 25 000 ograniczeń na hash.
Poseidon redukuje to do ~150 ograniczeń.

Krok 4: Implementacja dowodu własności (autoryzacja wydania)

Zazwyczaj obejmuje to:

• Sprawdzenie pochodzenia kluczy
• Weryfikację znajomości klucza prywatnego
• Zapobieganie powtórnym atakom

Zcash używa RedJubjub, schematu podpisu przyjaznego SNARK (styl EdDSA, ale zoptymalizowany dla SNARKów).

Krok 5: Implementacja logiki nullifierów

Nullifier = deterministyczny, unikalny tag dla wydanej noty.

Obwód ZK musi zapewnić:

• Każda nota generuje dokładnie jeden nullifier.
• Nullifier nie może ujawniać tożsamości noty.
• Nullifier nie może umożliwiać wielokrotnego wydania.

Ta część jest bardzo podatna na błędy — i była przyczyną największego błędu Zcash.

Krok 6: Budowa równania bilansu

Udowodnij:
suma_zobowiązań_wejściowych = suma_zobowiązań_wyjściowych

Plus dowody zakresu:

• Wartości ≥ 0
• Wartości < 2⁶⁴

W nowoczesnych systemach ograniczenia zakresu używają:

• Argumenty lookup PLONK
• Bulletproofs w obwodach
• Niestandardowe bramki

Krok 7: Końcowa agregacja i generowanie dowodu

Przykład SNARK:

• Kompilacja obwodu → wielomian QAP
• FFT dla ewaluacji wielomianu
• Wieloskalarowe mnożenia
• Wygenerowanie dowodu
• Weryfikacja on-chain/węzły weryfikacyjne w milisekundach

Przykład STARK:

• Budowa śladu wykonania
• Zastosowanie zobowiązań FRI
• Wygenerowanie dużego, ale transparentnego dowodu
• Weryfikacja za pomocą operacji hashujących

12. Akceleracja sprzętowa ZK (zmieniająca grę)

Większość użytkowników nie zdaje sobie sprawy, że generowanie dowodów ZKP powoli staje się wyścigiem sprzętowym:

Dowodzenie na GPU

• Operacje FFT i MSM mapują się doskonale na GPU.
• Testnet Aleo pokazał, że >50% przepustowości dowodzenia wykonano na konsumenckich GPU (seria RTX).

Dowodzenie na ASIC

Kilka firm (Ingonyama, Cysic) projektuje ASIC-y skoncentrowane na ZKP dla:

• Jednostek MSM
• Ewaluacji wielomianów
• Obliczeń ścieżek Merkle

Istotny szczegół statystyczny:

• Specjalizowany prover ASIC może generować dowody SNARK 20–50× szybciej niż CPU.

Oznacza to, że przyszłość monet prywatności może w dużej mierze opierać się na ekosystemach specjalistycznego sprzętu, podobnie jak w przypadku kopania Bitcoina.

13. Problem przejrzystego audytu w monetach ZK

Monety prywatności napotykają paradoks:

1. Użytkownicy chcą prywatności.
2. Deweloperzy muszą zapewnić brak inflacji lub ukrytych luk.
3. ZK wszystko ukrywa.

Kilka technik próbuje to rozwiązać:

13.1 Klucze podglądu (Zcash, Aztec)

Pozwalają audytorom sprawdzać konkretne konta bez ujawniania innych.

13.2 Audyty podaży

• Zcash może audytować przejrzystą pulę podaży.
• Pula shielded nie może być audytowana bezpośrednio.
• Deweloperzy polegają na poprawności obwodu, aby zagwarantować brak inflacji.

Dlatego błędy protokołów ZK stanowią zagrożenie egzystencjalne.

14. Rzadkie, ale ważne fakty kryptograficzne

14.1 Pierwotne artykuły ZKP używały protokołów interaktywnych

Nowoczesne SNARKi są nieinteraktywne (heurystyka Fiat–Shamir).
Jednak najwcześniejsze ZKP wymagały wielu rund komunikacji.

14.2 Fiat–Shamir nie jest dowodowo bezpieczny

Jeśli funkcja skrótu użyta w Fiat–Shamir jest złamana lub podatna na modyfikacje,
spójność może się zawalić.

Dotyczy to każdej monety prywatności opartej na SNARK.

14.3 STARKi oparte są wyłącznie na funkcjach skrótu

Oznacza to:

• Uważa się je za bezpieczne post-kwantowo.
• Ich bezpieczeństwo zależy tylko od odporności na kolizje funkcji skrótu (np. Rescue, Poseidon).

14.4 Dowody rekurencyjne redukują obciążenie blockchaina

Halo 2 (używany w Zcash Orchard) pozwala na:

• Dowody weryfikujące inne dowody
• Nieskończoną rekurencję
• Brak zaufanej konfiguracji

To eliminuje wiele wcześniejszych ograniczeń systemów SNARK.

15. Tabela porównawcza: systemy ZK w głównych monetach prywatności

Monero zostało uwzględnione tylko dla porównania — nie używa dowodów zerowej wiedzy, co zaskakuje wielu początkujących.

16. Rzeczywiste kompromisy stosowania ZKP w monetach prywatności

Zalety

• Maksymalna prywatność z matematycznymi gwarancjami.
• Możliwość jednoczesnego ukrycia nadawcy, odbiorcy i kwoty.
• Dowody mogą weryfikować wszyscy.

Wady

• Wysoki koszt obliczeniowy.
• Ryzyko błędów w obwodach (inflacja).
• Większe transakcje (z wyjątkiem Groth16).
• Trudniejsze do integracji w lekkich portfelach.
• Bardziej skomplikowana kryptografia → mniej ekspertów ją rozumie → wolniejsze audyty.

Rzadko wspominany problem:

Systemy ZK zwiększają wycieki deterministyczne portfeli:
wzorce dowodzenia mogą ujawniać sprzęt portfela, typ CPU/GPU, a nawet system operacyjny, dostarczając metadanych dla agencji nadzoru blockchain.

17. Kierunki rozwoju prywatności ZK w ciągu najbliższych 5 lat

Najbardziej prawdopodobne kierunki:

17.1 Uniwersalne warstwy prywatności

Zamiast budować prywatność bezpośrednio w L1:

• Sieci takie jak Aztec, Penumbra i RAILGUN mają na celu zapewnienie prywatności dla istniejących łańcuchów.
• To unika fragmentacji w altcoinach.

17.2 Koprocesory ZK

Urządzenia pomocnicze obsługujące wszystkie obliczenia SNARK/STARK dla portfeli lub węzłów.

17.3 Prywatność adaptacyjna (wybierana przez użytkownika)

Użytkownicy mogą selektywnie ujawniać:

• Kwoty
• Nadawcę
• Odbiorcę
• Pola memo

Tylko wtedy, gdy jest to wymagane prawnie lub komercyjnie.

17.4 W pełni prywatne ekosystemy smart kontraktów

Aleo, Aztec 3 i Penumbra aktywnie pionierują w tym kierunku.

17.5 Standardy tokenów przyjazne SNARK

Np. ZK-ERC20 z:

• Zaszyfrowanymi saldami
• Dowodami transferu ZK
• Kompatybilnością z narzędziami Ethereum

To prawdopodobnie będzie pierwsze naprawdę masowe zastosowanie ZK.

18. Końcowe refleksje

Dowody zerowej wiedzy fundamentalnie redefiniują pojęcie „prywatności” w ekosystemach blockchain.
Nie są magiczne i niosą ze sobą ryzyka inżynieryjne, złożoność kryptograficzną i operacyjną.
Ale pozwalają osiągnąć coś, czego żaden inny system nie jest w stanie:

matematycznie udowodniona prywatność połączona z matematycznie udowodnioną poprawnością.

Dla altcoinów skoncentrowanych na prywatności ZKP są zarówno ostateczną tarczą, jak i największą odpowiedzialnością w przypadku błędnej implementacji.
Zrozumienie dokładnych mechanizmów kryptograficznych — zobowiązań, obwodów, arytmetyzacji, systemów dowodów — jest kluczowe do oceny monet prywatności poza narracjami marketingowymi.