Czym są zk-SNARK-i i jak umożliwiają prywatność w blockchainach?

Czym są zk-SNARK-i?

zk-SNARK-i to kryptograficzne dowody, dzięki którym można wykazać, że określone informacje lub obliczenie są poprawne, bez ujawniania informacji wrażliwych. Dzięki temu blockchain może na przykład sprawdzić, czy płatność jest ważna, podczas gdy dane takie jak kwota lub odbiorca pozostają ukryte. Jednym z najbardziej znanych blockchainów wykorzystujących tę technologię jest Zcash. Wykorzystuje on zk-SNARK-i do weryfikacji transakcji, przy jednoczesnym ukrywaniu danych takich jak kwota lub odbiorca.

Nazwa zk-SNARK to skrót od zero-knowledge succinct non-interactive argument of knowledge. Brzmi to skomplikowanie, ale poszczególne elementy można prosto rozłożyć na części:

• Zero-knowledge: dowód pokazuje, że twierdzenie jest prawdziwe, na przykład że transakcja jest ważna, bez ujawniania informacji wrażliwych, takich jak adres nadawcy, adres odbiorcy czy kwota transakcji.
• Succinct: dowód jest krótki. Węzeł lub smart contract może więc sprawdzić go stosunkowo efektywnie.
• Non-interactive: po utworzeniu dowodu jego twórca nie musi już prowadzić dalszej komunikacji z osobą, która go weryfikuje. Dowód można utworzyć raz, a następnie sprawdzić.
• Argument of knowledge: twórca pokazuje, że dysponuje informacjami potrzebnymi do spełnienia określonych reguł, na przykład danymi, dzięki którym można utworzyć ważną transakcję. Bezpieczeństwo opiera się przy tym na założeniach kryptograficznych: atakujący o ograniczonej mocy obliczeniowej nie jest w praktyce w stanie stworzyć fałszywego dowodu, który zostałby zaakceptowany jako ważny. Informacje używane do utworzenia dowodu są często nazywane witness. Załóżmy, że chcesz udowodnić, że masz wystarczające saldo na płatność. Witness zawiera wtedy na przykład dane, dzięki którym można wykazać, że dysponujesz odpowiednią ilością środków i możesz je wydać. Blockchain nie musi widzieć tych danych, ale może sprawdzić, czy powiązany dowód jest ważny.

Oprócz prywatnego witness zk-SNARK może też zawierać dane publiczne. Są to informacje, które mogą być widoczne i które weryfikator wykorzystuje razem z dowodem, aby sprawdzić, czy twierdzenie jest prawdziwe.

Warto wiedzieć: zk-SNARK nie jest jednym stałym protokołem, lecz nazwą zbiorczą dla różnych systemów dowodowych o tych właściwościach. Dokładne działanie może się różnić w zależności od systemu. Niektóre systemy wymagają na przykład trusted setup, podczas gdy inne mogą działać bez takiego przygotowania.

Najważniejsze informacje

• zk-SNARK-i dowodzą, że coś jest prawdziwe, bez ujawniania informacji wrażliwych.
• Prywatne dane stojące za dowodem są często nazywane witness.
• Dowody są krótkie i można je stosunkowo efektywnie weryfikować.
• Opublikowany dowód można zweryfikować bez dodatkowego kontaktu z jego twórcą.
• zk-SNARK-i to kategoria systemów dowodowych, a nie jeden stały protokół.

Jak działają zk-SNARK-i?

W przypadku zk-SNARK-a reguły, które musi spełniać transakcja lub obliczenie, są najpierw zamieniane na kontrole, które może wykonać komputer. Taki zestaw kontroli nazywa się obwodem lub systemem ograniczeń. Określa on dokładnie, jakie warunki muszą zostać spełnione, zanim coś zostanie uznane za ważne.

Weźmy jako przykład prywatną płatność. Obwód może na przykład sprawdzać, czy ktoś ma wystarczające saldo, czy nie wydał go wcześniej i czy ma prawo z niego korzystać. Informacje wrażliwe potrzebne do tych kontroli, takie jak saldo lub dane, dzięki którym można je wydać, pozostają ukryte przed osobą weryfikującą dowód.

W dużym uproszczeniu są trzy kroki:

1. Setup W wielu klasycznych zk-SNARK-ach najpierw tworzy się publiczne parametry. Są one potrzebne do tworzenia i weryfikacji dowodów.

2. Proof generation Prover, czyli strona, która chce coś udowodnić, używa witness i reguł obwodu do utworzenia dowodu kryptograficznego.

3. Weryfikacja Verifier, na przykład węzeł lub smart contract, sprawdza dowód razem z danymi publicznymi. Verifier nie widzi prywatnego witness i nie musi samodzielnie wykonywać całego obliczenia od początku.

Dobry system zk-SNARK ma gwarantować trzy ważne właściwości. Po pierwsze zupełność: jeśli twierdzenie jest prawdziwe, a dowód został poprawnie utworzony, dowód zostanie zaakceptowany. Po drugie soundness: atakujący nie jest w praktyce w stanie stworzyć ważnego dowodu dla twierdzenia, które nie jest prawdziwe. I po trzecie zero-knowledge: dowód nie ujawnia informacji wrażliwych, poza samym faktem, że udowodnione twierdzenie jest prawdziwe.

Przykład: Załóżmy, że musisz udowodnić, że masz więcej niż 18 lat, bez podawania daty urodzenia. W teorii zk-SNARK może wykazać, że spełniasz ten warunek, bez ujawniania daty urodzenia ani dokładnego wieku osobie sprawdzającej.

Istnieje jednak ważne ograniczenie. zk-SNARK sprawdza tylko reguły zapisane w obwodzie. Jeśli w tych regułach jest błąd, dowód może być technicznie ważny, mimo że system pozwala na coś, czego w rzeczywistości nie powinien. Kryptografia nie naprawi więc automatycznie źle zaprojektowanego obwodu.

Do czego używa się zk-SNARK-ów?

zk-SNARK-i stosuje się wtedy, gdy ktoś chce wykazać, że obliczenie zostało wykonane poprawnie, bez ujawniania wszystkich danych wejściowych ani kroków pośrednich. To sprawia, że technologia jest interesująca dla prywatności, ale także dla zastosowań, w których osoba weryfikująca dowód nie musi ponownie wykonywać całego obliczenia.

Kilka znanych zastosowań to:

• prywatne płatności;
• aplikacje, w których dane wejściowe lub części obliczenia pozostają prywatne;
• dowody tożsamości i credentiali, w których można wykazać cechę bez udostępniania wszystkich danych osobowych;
• proof-of-reserves, w którym podmiot może wykazać, że posiada określone rezerwy, bez ujawniania wszystkich danych źródłowych;
• validity rollups, które przetwarzają wiele transakcji poza Ethereum, a następnie umieszczają na Ethereum dowód poprawnego przetworzenia.

Aleo wykorzystuje na przykład model, w którym program jest uruchamiany lokalnie. Następnie tworzy się dowód zero-knowledge, który pozwala wykazać, że wykonanie było poprawne. Walidatorzy nie muszą wtedy otrzymywać wszystkich prywatnych danych wejściowych i kroków pośrednich, lecz mogą sprawdzić dowód.

Prywatność nie pojawia się automatycznie tylko dlatego, że gdzieś użyto oznaczenia „ZK”. To, jakie dane pozostają prywatne, zależy od protokołu i od tego, co w obwodzie zostało określone jako prywatne lub publiczne. Jeśli pewne dane transakcji są celowo ujawniane publicznie, zk-SNARK nie ukryje ich później.

Jak zk-SNARK-i wspierają prywatność?

zk-SNARK-i wspierają prywatność, ponieważ pozwalają udowodnić, że transakcja jest ważna, bez ujawniania jej wrażliwych szczegółów. W przypadku prywatnej płatności ktoś może na przykład wykazać, że dysponuje ważnymi środkami, ma prawo je wydać i nie wydaje pieniędzy podwójnie. Nadawca, odbiorca i kwota nie muszą być przy tym publiczne.

Zcash dobrze pokazuje, jak działa taki model. Wykorzystuje on note do prywatnego zapisania określonej ilości ZEC. Na blockchainie nie znajduje się pełna treść tej note, lecz commitment: kryptograficzne zobowiązanie do niej. Można to porównać do zamkniętej, zapieczętowanej koperty. Każdy może zobaczyć, że koperta istnieje, ale nie może sprawdzić, co jest w środku.

Informacje o note są szyfrowane dla odbiorcy. Gdy note zostaje wydana, na blockchainie pojawia się unikalny nullifier. Nullifier nie pokazuje bezpośrednio, która note została wydana, ale węzły mogą sprawdzić, czy ten sam nullifier był już wcześniej użyty. Dzięki temu sieć może zapobiegać double spending bez ujawniania podstawowych danych prywatnych.

Prywatność nie oznacza więc, że na blockchainie nie pozostaje żaden ślad. Commitments i nullifiers nadal są widoczne. Również dane takie jak adresy IP, czas transakcji, metadane sieciowe i informacje ujawnione przez samego użytkownika nie są automatycznie ukrywane przez zk-SNARK.

Jak zk-SNARK-i są używane do skalowania?

Do skalowania zk-SNARK-i można wykorzystać do podsumowania dużej ilości obliczeń w jednym zwartym dowodzie. Widać to na przykład w validity rollups: transakcje są przetwarzane poza Ethereum, grupowane w batchach, a następnie tworzony jest dowód, że przetwarzanie przebiegło poprawnie.

Operator takiego rollupu przetwarza transakcje i tworzy validity proof, który pokazuje, że nowy stan został obliczony zgodnie z zasadami rollupu. Kontrakt weryfikujący na Ethereum akceptuje ten nowy stan tylko wtedy, gdy dowód jest ważny. Dzięki temu Ethereum nie musi ponownie wykonywać wszystkich obliczeń dla każdej pojedynczej transakcji.

Dzięki rekurencji można to jeszcze bardziej uprościć. W takim przypadku nowy dowód może wykazać, że wiele wcześniejszych dowodów jest ważnych. Ostatecznie wiele oddzielnych obliczeń lub dowodów można więc przedstawić jednym zwartym dowodem.

Scroll wykorzystuje dowody ZK do wykazania poprawnego wykonania batchy transakcji, po czym dowód może zostać zweryfikowany na Ethereum.

Mina wykorzystuje rekurencyjne zk-SNARK-i w inny sposób. Zamiast wymagać od uczestnika sprawdzenia całej historii blockchaina od początku, można wykazać poprawność bieżącego stanu blockchaina za pomocą zwartego dowodu kryptograficznego.

Szybka weryfikacja nie oznacza, że cały proces jest tani. Samo tworzenie dowodu może wymagać dużej mocy obliczeniowej i pamięci. Ponadto validity proof nie rozwiązuje automatycznie innych problemów, takich jak dostępność danych, cenzura ze strony operatora czy ryzyka związane z mostami między blockchainami.

Które blockchainy i kryptowaluty korzystają z zk-SNARK-ów?

Różne projekty crypto wykorzystują zk-SNARK-i, ale często do różnych celów. Technologia ta nie służy więc wyłącznie do prywatnych transakcji.

• Zcash używa zk-SNARK-ów do shielded transactions. W ramach protokołu Orchard używany jest Halo 2 do kryptograficznego dowodzenia takich transakcji.
• Aleo używa zk-SNARK-ów do prywatnych i programowalnych aplikacji. Programy mogą być uruchamiane lokalnie, a następnie walidatorzy sprawdzają dowód poprawnego wykonania bez konieczności widzenia prywatnych danych wejściowych ani kroków pośrednich.
• Mina używa rekurencyjnych zk-SNARK-ów do zwartego dowodzenia poprawności stanu blockchaina. Głównym celem jest tu kompaktowa weryfikacja, a nie automatyczna prywatność transakcji.
• Scroll używa zk-SNARK-ów w swoim zkEVM do dowodzenia poprawnego przetwarzania batchy transakcji. Dowody te mogą być następnie weryfikowane na Ethereum.
• Ethereum wspiera weryfikację niektórych zk-SNARK-ów opartych na pairingach za pomocą precompiles. Dzięki temu smart contracty mogą sprawdzać dowody zk-SNARK. Ethereum nie używa jednak zk-SNARK-ów jako ogólnego mechanizmu konsensusu.

Warto odróżnić zk-SNARK od zk-STARK. Oba są systemami dowodów kryptograficznych, które mogą wspierać zero-knowledge, ale technicznie działają inaczej. zk-STARK-i zwykle nie wymagają trusted setup, ale często generują większe dowody niż zk-SNARK-i. ZK-rollup nie musi więc koniecznie korzystać z zk-SNARK-a.

Czym jest trusted setup w zk-SNARK-ach?

Trusted setup to jednorazowy proces, w którym dla niektórych zk-SNARK-ów tworzy się publiczne parametry potrzebne do generowania i weryfikacji dowodów. Parametry te są często nazywane structured reference string (SRS) lub common reference string (CRS).

Wrażliwym elementem są tajne losowe informacje używane podczas takiego setupu. Nazywa się je też toxic waste. Jeśli ktoś zachowa te informacje lub będzie w stanie je później odtworzyć, może to w niektórych systemach, takich jak Groth16, zostać w teorii wykorzystane do tworzenia fałszywych dowodów, które mimo to zostaną zaakceptowane jako ważne.

Dlatego projekty czasem korzystają z ceremonii multi-party computation. Wielu uczestników dodaje wtedy własną tajną losowość. Dopóki przynajmniej jeden uczestnik działa uczciwie i rzeczywiście zniszczy swoją tajną część, nie da się odtworzyć całej tajnej informacji setupu.

Zmniejsza to ryzyko w znacznym stopniu, ale nadal oznacza, że trzeba ufać, iż przynajmniej jeden uczestnik nie został skompromitowany i naprawdę usunął swój tajny wkład.

Nie każdy zk-SNARK wymaga trusted setup. Zcash w starszych obwodach Sprout i Sapling używał Groth16, który wymagał takiego trusted setup. Późniejszy protokół Orchard używa Halo 2 i nie wymaga trusted setup z toxic waste.

Jakie są zalety zk-SNARK-ów?

Największą zaletą zk-SNARK-ów jest to, że prywatność i możliwość weryfikacji mogą iść ze sobą w parze. Można wykazać, że spełnia się określone reguły, bez ujawniania wrażliwych danych stojących za dowodem.

Najważniejsze zalety w skrócie:

• Prywatność z kontrolą: wrażliwe dane mogą pozostać ukryte, a węzły nadal mogą sprawdzić, czy transakcja lub obliczenie są ważne.
• Krótkie dowody: dowody są zwarte w porównaniu z obliczeniem, które reprezentują.
• Szybka weryfikacja: węzeł lub smart contract nie musi ponownie wykonywać całego obliczenia.
• Publiczna kontrola: dowód można opublikować, a następnie niezależnie zweryfikować.
• Podsumowanie wielu obliczeń: dzięki dowodom rekurencyjnym wiele transakcji, batchy lub wcześniejszych dowodów można ostatecznie ująć w jednym zwartym nowym dowodzie.

Na Ethereum niektóre zk-SNARK-i oparte na pairingach mogą być też sprawdzane w smart contractach. Dzięki temu aplikacje mogą na przykład zlecać weryfikację dowodów obliczeń offchain lub kontroli nastawionych na prywatność na Ethereum.

Warto jednak pamiętać, że „krótki” i „efektywny” odnoszą się przede wszystkim do rozmiaru dowodu i jego weryfikacji. Dla provera utworzenie takiego dowodu może wymagać dużej mocy obliczeniowej i pamięci.

Jakie są ograniczenia i ryzyka zk-SNARK-ów?

zk-SNARK-i są potężne, ale nie rozwiązują każdego problemu z prywatnością ani skalowalnością. Bezpieczeństwo zależy od użytej kryptografii, obwodu i sposobu, w jaki system został wbudowany w blockchain lub aplikację.

Jednym z ważnych ryzyk w systemach zależnych od trusted setup jest tajna informacja setupu. Jeśli toxic waste z na przykład setupu Groth16 trafi w niepowołane ręce, atakujący mogą potencjalnie tworzyć fałszywe dowody, które mimo to zostaną zaakceptowane jako ważne. W przypadku prywatnego systemu płatności może to w najgorszym razie doprowadzić do powstania salda, które zgodnie ze zwykłymi zasadami nie powinno istnieć.

Ponadto zk-SNARK dowodzi jedynie, że spełniono reguły obwodu. Błędy w obwodzie, kodzie provera, kodzie verifera, użytych parametrach lub integracji z blockchainem mogą więc mieć poważne skutki. Kryptograficznie poprawny dowód nie pomoże, jeśli same reguły zostały źle zaprojektowane.

Prywatność również ma swoje granice. W shielded transakcjach Zcash na blockchainie nadal widoczne są na przykład commitments i nullifiers, podczas gdy informacje o notes pozostają zaszyfrowane. Dodatkowo dane publiczne, czas transakcji, adresy IP i inne metadane sieciowe mogą czasem mimo wszystko ujawniać informacje lub pokazywać powiązania.

W przypadku zk-rollups pojawia się inny problem. Validity proof może wykazać, że batch został przetworzony poprawnie, ale nie zapobiega automatycznie temu, by operator opóźniał transakcje lub cenzurował użytkowników. Ryzyka związane z bridge'ami i dostępnością danych również pozostają.

Na koniec warto pamiętać, że zero-knowledge nie oznacza automatycznie odporności systemu na przyszłe ataki kwantowe. Zależy to od konkretnej konstrukcji kryptograficznej. Klasyczne zk-SNARK-i oparte na pairingach korzystają z innych założeń kryptograficznych niż na przykład transparentne systemy STARK.

Podsumowanie

zk-SNARK-i umożliwiają udowodnienie, że transakcja lub obliczenie są poprawne, bez ujawniania wrażliwych danych stojących za nimi. Dzięki temu są interesujące dla prywatnych płatności, aplikacji nastawionych na prywatność oraz skalowania poprzez validity rollups. Zcash jest jednym z najbardziej znanych przykładów blockchaina, który wykorzystuje zk-SNARK-i do umożliwienia shielded transactions.

Sedno jest stosunkowo proste: blockchain lub inny verifier nie musi widzieć wszystkich danych źródłowych ani ponownie wykonywać całego obliczenia, o ile może sprawdzić ważny dowód kryptograficzny. To, ile prywatności i bezpieczeństwa ostatecznie zapewnia takie rozwiązanie, zależy jednak od projektu systemu. Ostatecznie zk-SNARK jest tak wiarygodny, jak obwód, użyta kryptografia i cała integracja wokół niego.