zk-SNARK (ang. Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) to protokół “dowodzenia z wiedzą zerową” (ang. Zero Knowledge Proof). Kryptowaluta ZCash będzie jednym z pierwszych otwartych projektów kryptowalutowych, który wykorzysta implementację tego fascynującego algorytmu w mechanizmie działania blockchaina. Dowody z wiedzą zerową mają ogromny potencjał i mogą znaleźć zastosowanie, a wręcz zrewolucjonizować wiele procesów wymiany informacji.

W tym artykule wyjaśniam:

• czym jest dowód z wiedzą zerową,
• czym jest i jak działa protokół zk-SNARK i jaką matematyczną machinerię wykorzystuje.

Czym właściwie jest zk-SNARK?

zk-SNARK to protokół, instrukcja realizacji algorytmu rozwiązującego niezwykle ciekawy problem: jak udowodnić, że znamy pewną wartość, bez konieczności dzielenia się tą wartością. Innymi słowy, jak przedstawić dowód na to, że znamy pewną informację bez ujawniania tej informacji. W typowej interakcji występuje 2 uczestników: udowadniający (proover) oraz weryfikujący (verifier). W uproszczeniu: dowodzący ma na celu udowodnić weryfikującemu, że zna pewną wartość x, bez ujawniania tej wartości.

Nazwa algorytmów adresujących ten problem trafnie opisuje je jako dowody z wiedzą zerową – wiedza zerowa oznacza, że udowodniający nie ujawnia weryfikującemu informacji, a jedynie dowód na to, że posiada informację. zk-SNARK jest nieinteraktywny – oznacza, to że dowód jest pojedynczy: dowodzący przedstawia weryfikującemu pojedynczy, krótki dowód (w praktyce kilka wartości) i na tym ich interakcja się kończy. Informacja powinna być wystarczająca do tego, aby weryfikujący mógł określić poprawność dowodu – dowodu na to, że dowodzący jest wiarygodny i posiada informację, dla której dowód posiadania dostarczył.

Matematyczna machineria zk-SNARK

Dowodzenie z wiedzą zerową wymaga szeregu dość złożonych operacji matematycznych (algebraicznych). Stworzenie protokołu, który jest nieinteraktywny, czyli nie wymaga ciągłej komunikacji, konwersacji między dowodzącym a weryfikującym, to wymagający problem.

zk-SNARK jest opisem zbioru pewnych matematycznych przekształceń, które wykonane kolektywnie umożliwiają stworzenie protokołu dowodzenia określonych twierdzeń (z wiedzą zerową). Innymi słowy, jest to instrukcja zaprojektowania, a następnie stworzenia i wykorzystania funkcji umożliwiających: tworzenie dowodu z wiedzą zerową (dla dowodzącego), a następnie jego weryfikację (dla weryfikującego). Oznacza to, że nie istnieje pojedyncza implementacja algorytmu zk-SNARK, która potrafi dowodzić z wiedzą zerową każde twierdzenie. Konkretne twierdzenie do udowodnienia wymaga konkretnej implementacji zgodnej z protokołem zk-SNARK.

Ten artykuł skupia się na wyjaśnieniu mechanizmów matematycznych wykorzystywanych w dowodach zk-SNARK, natomiast nie na samym ich wykorzystaniu. Jest to uproszczona forma opisująca główne koncepcje i elementy układanki tworzącej zk-SNARK. Bardziej zaawansowany opis można znaleźć na blogu ZCash, gdzie opublikowana jest seria artykułów opisujących zk-SNARK, a także na blogu Ethereum. Poniższy opis to szereg skomplikowanych matematycznych przekształceń przedstawiony w stosunkowo prostej i przystępnej formie. Ich znajomość umożliwi zainteresowanym zrozumienie matematycznej “magii” kryjącej się za dowodami z wiedzą zerową.

1. Funkcja homomorficzna (Homomorphic Hiding)

Homomorphic Hiding (HH) to kluczowy element zk-SNARK. Określmy funkcję |E(x)| nieformalnie jako funkcję homomorficzną, która posiada następujące właściwości:

• znając wartość |E(x)|, czyli obliczoną wartość funkcji dla argumentu |x|, bardzo trudno jest określić wartość samego |x|;
• funkcja homomorficzna powinna zwracać różne wartości dla różnych argumentów (inny wynik dla |x = 5|, inny dla |x = 6|, itp.);
• jeśli ktoś zna wartość |E(x)| np. |E(5)|, oraz zna wartość |E(y)| np. |E(8)| – to potrafi obliczyć wartość |E(x+y)|, czyli |E(13)|;

Założmy, że Alicja chce udowodnić Bobowi, że zna liczby |x| i |y|, tak że |x + y = 7|. Alicja nie chce wysłać Bobowi tych liczb, więc jedyne co Bob wie, to że suma tych dwóch liczb ma wynosić |7|. Alicja i Bob określają między soba pewną funkcję HH. Wykorzystując tą funkcję, Alicja może wysłać Bobowi wartość |F(x)| oraz |F(y)|. Mając te dwie wartości, Bob oblicza |F(x +y)|, a także |F(7)|. Ostatecznie Bob wierzy, że Alicja zna poprawne wartości, jeśli wartość |F(x + y)| jest dokładnie równa wartości |F(7)|.

Powyższy mechanizm wykorzystując jedynie matematyczne właściwości funkcji homomorficznej i algebraicznych przekształceń umożliwia przeprowadzić proces dowodzenia, dzięki któremu bez zdradzania wartości weryfikujący jest w stanie sprawdzić, czy dowodzący mówi prawdę. Opisana funkcja homomorficzna to jeszcze nie dowód z wiedzą zerową. Funkcje HH są wykorzystywane w zk-SNARK w szerszym kontekście. Sama mechanika funkcji homomorficznej to jeszcze za mało, aby zaproponować protokół dowodzenia dowolnych (w praktyce bardziej złożonych niż przedstawiony przykład wyżej) twierdzeń. Do tworzenia uniwersalnych dowodów z wykorzystaniem zk-SNARK potrzebny jest bardziej zaawansowany mechanizm.

2. Ślepa ewaluacja (Blind evaluation)

Załóżmy, że Alicja zna pewien wieloman |P| stopnia |d|. Bob chciałby się dowiedzieć, jaka będzie wartość |E(P(s))| – czyli chciałby poznać wartość funkcji homomorficznej, od wartości wielomianu w pewnym punkcie |s|. Jak można to łatwo zrealizować?

1. Alicja wysyła wielomian Bobowi, dzięki czemu jest on w stanie sam to obliczyć.
2. Bob wysyła wartość |s| do Alicji, ona zwraca rezultat, który oczekuje Bob.

Zastanówmy się jednak, czy Bob jest w stanie poznać wartość |E(P(s))|, bez konieczności poznawania wielomianu |P| oraz bez konieczności wysyłania Alicji wartości |s|? Wykorzystując funkcje homomorficzne oraz kombinacje liniowe mające zastosowanie w operacjach na wielomianach (reguły wynikają z algebry liniowej) można przedstawić następujące kroki:

1. Bob wysyła Alicji wartości funkcji homomorficznej |E: E(s^0), E(s^1), …, E(s^d)| (gdzie |d| to wartość stopnia wielomianu |P|)
2. Alicja wykorzystując otrzymane od Boba wartości oblicza |E(P(s))|. Może to zrobić, ponieważ funkcja homomorifczna |E(x)| wspiera kombinacje liniowe, a wartość |P(s)| jest kombinacją liniową wartości |s^0, s, …, s^d|

Algorytm umożliwia poznanie wartości |E(P(s))| przez Boba w poufny sposób – Bob nie zna funkcji |P(s)|, natomiast Alicja dostarczająca wartość |E(P(s))| nie zna wartości |s|. Ten proces określany jest jako ślepa ewaluacja i jest kolejnym istotnym mechanizmem wykorzystywanym w dowodach zk-SNARK.

Pojawia się jednak następujący problem: w jaki sposób Bob może być pewny, że Alicja na pewno wykorzystała właściwy wielomian? Sam fakt, że może to zrobić, nie umożliwia w tym momencie jeszcze Bobowi weryfikacji tego, czy Alicja rzeczywiście to zrobiła. Powyższy proces pozwala Alicji dostarczyć wartość, jaką oczekuje Bob – natomiast nie umożliwia Bobowi weryfikacji, czy aby na pewno Alicja wykorzystała wielomian |P|, którego oczekiwał Bob. Innymi słowy: Alicja może wysłać Bobowi dowolną wartość, a Bob nie będzie w stanie tego zweryfikować.

3. Test KC (Knoweldge of Coefficient Test) i KCA (Knowledge of Coefficient Assumption)

Naszym celem jest teraz zmusić Alicję, aby wykorzystała właściwy wielomian do obliczenia wartości |E(P(s))|? Przedstawmy narzędzie, które używane w zk-SNARK umożliwia ten cel osiągnąć.

Test KC ma następujący przebieg:

1. Bob określa wartość współczynnika |α| oraz wybiera pewną pare liczb (a,b) zwaną |α|-parą, która spełnia podane równanie |b = α⋅a|
2. Bob wysyła Alicji podaną parę mówiąc, że jest to para |α|.
3. Alicja musi zwrócić teraz inną |α|-parę Bobowi – parę |(a’,b’)|
4. Bob akceptuje parę Alicji tylko, jeśli naprawdę jest ona |α|-parą. Może to w prosty sposób sprawdzić, ponieważ para zwrócona przez Alicję powinna spełniać równanie |b’ = α⋅a’|

Alicja może w prosty sposób dostarczyć wartość oczekiwaną przez Boba, jeśli zna wartość |α|. Chodzi jednak o to, że Alicja nie zna wartości |α|. W tym przypadku dostarczenie nowej |α|-pary przez Alicję może polegać na zwróceniu pary |(a’,b’) = (a⋅γ, b⋅γ)|. Nowa para stworzona jest poprzez iloczyn wartości |a| i |b| przez pewną określoną wartość |γ|. Wiedza Alicji dotycząca współczynnika |γ| określana jest jako KCA. Obliczona w ten sposób para zwrócona przez Alicję spełnia równanie Boba.

W scenariuszu rozszerzonego KCA Bob wysyła do Alicji |n| |α|-par, przy czym |α| jest stałe, zmieniają się tylko argumenty |a| i |b|. Dla każdej pary Alicja generuje kolejną |α|-parę |(a’,b’)|. Ponownie dzięki właściwościom algebry liniowej, Alicja jest w stanie zhermetyzować wiele wygenerowanych |α|-par do tylko jednej pary, którą zwróci Bobowi np. jeśli Alicja ma wygenerować 2 |α|-pary dla |(a_1,b_1)| i |(a_2,b_2)|, a wygenerowanie nowej pary obejmuje iloczyn przez odpowiednio |c1| i |c2| wtedy prawdziwe jest równanie: |b’ = c_1\cdot b_1 + c_2 \cdot b_2 = c_1 (\alpha \cdot a_1) + c_2(\alpha\cdot a_2) = \alpha (c_1\cdot a_1 + c_2\cdot a_2) = \alpha\cdot a’.|

4. Protokół weryfikowalnej ślepej ewaluacji (The Verifiable Blind Evaluation Protocol)

Składając wszystkie wyżej opisane komponenty, jesteśmy w stanie uzyskać weryfikowalny protokół ślepej ewaluacji, czyli wymusić na Alicji wygenerowanie “właściwego” wielomianu:

1. Bob posiada funkcję homomorficzną |E(x)=x⋅g|. Wybiera sobie dowolną wartość współczynnika |α|. Wysyła do Alicji wartości funkcji |E(x)| : |E(s^0), E(s^1), …, E(s^d)| (czyli wartości |s^0⋅g, s^1⋅g,…,s^d⋅g|) oraz wartości funkcji |E(x⋅α)| – a więc wartości: |α⋅(s^0⋅g), α⋅(s^1⋅g),…, α⋅(s^d⋅g)|
2. Alicja posiada pewien wielomian |P(x)| stopnia d. Oblicza |a= E(P(s)) = P(s)⋅g| oraz |b=α⋅E(P(s)) = α⋅P(s)⋅g|. Może to zrobić, ponieważ w gruncie obliczone przez Alicję wartości są kombinacjami liniowymi wysłanych przez Boba wartości funkcji homomorficznych (algorytm z punktu drugiego – ślepa ewaluacja).
3. Bob weryfikuje, czy zachodzi równanie |b=α⋅a| i akceptuje wartości Alicji tylko wtedy, gdy się zgadza.

Wykorzystując protokół ślepej ewaluacji i test KCA otrzymaliśmy algorytm umożliwiający weryfikację poprawności wielomianu Alicji. W opisany sposób Alicja jest w stanie w dostarczyć Bobowi oczekiwaną wartość |E(P(s))| nie poznając s, natomiast Bob jest w stanie sprawdzić jego poprawność. Wielomian poprawny w tym momencie oznacza – wielomian odpowiedniego stopnia.

Poznane mechanizmy pozwalają nam już rozpocząć definiowanie działania protokołu zk-SNARK. Protokół ten ma na celu umożliwić udowodnienie pewnego twierdzenia, a następnie jego weryfikację. Twierdzenie w tym rozumieniu to pewna matematyczna formuła. Strona dowodząca przedstawiając dowód, chce udowodnić, że zna rozwiązanie tej formuły, natomiast strona weryfikująca musi potrafić zweryfikować dowód, bez znajomości rozwiązania. Zacznijmy więc od podstawowego problemu zk-SNARK: jak umożliwić zapis twierdzeń do udowodnienia z wiedzą zerową w sposób generyczny, czyli pozwalający zapisywać “dowolne” twierdzenia?

5. Quadratic Arithmetic Program

QAP to ogólna metoda zapisu twierdzenia, które ma zostać udowodnione dowodem z wiedzą zerową. Twierdzenie do udowodnienia zapisane w postaci QAP umożliwia jego dekompozycję do wielomianów, dla których następnie łatwo można określić poprawność rozwiązania. Innymi słowy: mamy możliwość definiowania twierdzeń do udowodnienia w odpowiedniej postaci, dla której możemy sprawdzić poprawność rozwiązania.

Warto zaznaczyć, że twierdzenie do udowodnienia wykorzystując zk-SNARK, już samo w sobie powinno być wielomianem. QAP nie sposobem translacji kodu programu komputerowego definiującego twierdzenie do wielomianu (np. kodu programu definiującego działanie funkcji |C(x,y)|, który udowadnia, że Alicja zna wartość |x|, której hash wynosi |y|, czyli |C(x,y) == true|). QAP służy translacji już zdefiniowanego matematycznie twierdzenia (czyli kodu programu w postaci pewnego wielomianu reprezentującego problem), do postaci QAP (która notabene też składa się z wielomianów). To generyczna metoda – algorytm przekształcania twierdzeń do udowodnienia do odpowiedniej postaci, czyli takiej która następnie przy wykorzystaniu przekształceń algebraicznych i funkcji homomorficznych umożliwi implementację konkretnych funkcji zk-SNARK (funkcji do tworzenia i weryfikacji dowodów).

6. Protokół Pionokia (Pinocchio Protocol)

Wykorzystując QAP oraz zbierając wszystkie opisane wcześniej części w całość, można stworzyć następujący mechanizm: Alicja potrafi udowodnić Bobowi, że zna rozwiązanie |(c1⋅c2)⋅(c1+c3)=7| (przykładowego wielomianu), tj. zna wartości c1, c2 oraz c3 bez konieczności ujawniania tych wartości. Protokół (zwany Protokołem Pinokia) przeprowadzenia takiego dowodu przez Alicję jest następujący:

1. Zapisany w postaci QAP przez Alicję wielomian |(c1⋅c2)⋅(c1+c3)=7| składa się z wielomianów |P, L, R, O|, stworzonych przez Alicję z wartości reprezentujących rozwiązanie twierdzenia do udowodnienia. Jeśli Alicja posiada poprawne rozwiązanie do udowodnienia, czyli zna takie |c1, c2, c3|, dla których |(c1⋅c2)⋅(c1+c3)=7|, to zdefiniowane przez nią wielomiany spełniają równość: |P = L⋅R – O|. Ponadto, jeśli Alicja ma poprawne wartości |c1, c2, c3|, to potrafi zdefiniować także wielomian |H|, taki że |P = H⋅T|.
2. Bob wybiera pewną dowolną wartość |s| i wysyła Alicji wartość |E(T(s))| (czyli wartość funkcji homomorficznej |E| z wartości wielomianu T dla s). Wielomian T jest znany Bobowi, ponieważ także jest wynikiem dekompozycji weryfikowanego wielomianu do postaci QAP.
3. Alicja odsyła Bobowi wartości: |E(L(s)),E(R(s)),E(O(s)),E(H(s))|
4. Bob sprawdza, czy |E(P(s)) = E(T(s)*H(s))|, czyli |E(L(s)⋅R(s)−O(s))=E(T(s)⋅H(s))|.

Protokół pozwala na przedstawienie przez Alicję dowodu na posiadanie rozwiązania dla twierdzenia bez ujawniania tego rozwiązania. Bob jest w stanie zweryfikować poprawność posiadanego przez Alicję rozwiązania, przy założeniu że na pewno zwróciła wartości, które oczekiwał Bob.

Powyższy opis pozwala już zdefiniować ogólny protokół tworzenia łatwych do udowodnienia twierdzeń (przy wykorzystaniu QAP), a następnie weryfikacji posiadania rozwiązania dla tych twierdzeń (weryfikowalna ślepa ewaluacja oraz QAP). Niestety protokół nadal podatny jest na nadużycia: Alicja potrafi przedstawić dowód na rozwiązanie twierdzenia, natomiast nadal nie ma absolutnej pewności, że faktycznie wykorzystała rozwiązanie zwracając Bobowi wartości – teoretycznie może zwrócić wartości, dla których zajdzie oczekiwana przez Boba równość z punktu 4, jednak wartości nie są właściwe dla dowodzonego twierdzenia.

7. zk-RKS, prawie zk-SNARK

Protokół Pionokia jest już gotową bazą do stworzenia kompletnego algorytmu dowodzenia z wiedzą zerową. Aby jednak otrzymać kompletny protokół zk-SNARK, trzeba rozwiązać jeszcze kilka poniższych kwestii.

7.1 Problem: Bob musi znać odpowiednią funkcję homomorficzną E

Odpowiednia oznacza taka, która wspiera iloczyny. Wcześniej nie została przedstawiona, żadna konkretna taka funkcja. Rozwiązaniem tego problemu jest określenie funkcji homomorficznej poprzez wykorzystanie krzywych eliptycznych.

7.2 Problem: Alicja musi wygenerować właściwe wielomiany – odpowiedniego stopnia i wygenerowane z wartości będących rozwiązaniem twierdzenia do udowodnienia

To problem, z którym borykamy się przez właściwie cały artykuł. W Protokole Pinokia Alicja ma za zadanie wygenerować wielomiany |P, L, R, O| przy wykorzystaniu swojego rozwiązania. Protokół Pinokia umożliwia Bobowi sprawdzenie, że Alicja zna rozwiązanie QAP, a więc jest to dowód na jej rozwiązanie twierdzenia do udowodnienia. Jednak Bob musi mieć dodatkowo dowód na to, że Alicja na pewno dostarczyła rozwiązanie QAP, wykorzystując właściwe wartości rozwiązania, które posiada.

Rozwiązanie tego problemu w praktyce możliwe jest poprzez wykorzystanie właściwości zapisu twierdzenia do udowodnienia w postaci QAP. Zapis ten umożliwia weryfikację posiadania rozwiązania twierdzenia – co w dodaktu z ukrywaniem rozwiązania poprzez wykorzystanie funkcji homomorficznych, wykorzystujemy w protokole Pionokia. Połączenie tego zapisu wraz z mechaniką kombinacji liniowych, umożliwia także faktyczną weryfikację wykorzystania przez dowodzącego właściwych rozwiązań, przy dowodzeniu twierdzenia QAP. Określmy pewną grupą wielomianów |Fi|, które powstają poprzez kombinację wielomianów |L, R, O| wraz z rozwiązaniami twierdzenia do udowodnienia. Bob może poprosić Alicję o udowodnienie mu, że potrafi zapisać |F(s)| – wynik przekształcenia łączącego wiele funkcji |Fi|. Ten dowód umożliwi Bobowi weryfikację, że Alicja wykorzystuje właściwe rozwiązanie twierdzenia do udowodnienia, zwracając wartości rozwiązania QAP. Mamy już więc kompletne zero-proof-knowledge.

8. Kompletny zk-SNARK

Protokół Pionokia z uwzględnieniem poprawek z punktu 7 jest póki co zk-RKS (Zero Knowledge Argument Of Knowledge). Oznacza to, ze mamy możliwość dowodzenia twierdzeń z wiedzą zerową – natomiast proces ten nie jest jeszcze szybki i wymaga interakcji między uczestnikami (za długiej interakcji).

Jak uzyskać zk-SNARK (Zero Knowledge Succinct Non Interactive Argument of Knowledge) – jak ograniczyć interakcję między uczestnikami do pojedynczego komunikatu, który dowodzący wysyła weryfikującemu? Rozwiązanie tego ostatecznego problemu polega na wyeliminowaniu konieczności wysyłania przez Boba wartości dla Alicji, które są niezbędne dla niej aby mogła wygenerować dowód.

Stworzenie kompletnego zk-SNARK jest proste: wymagane wartości można przygotować wcześniej i zaszyć w protokole (CRS). Innymi słowy, implementacja protokółu zk-SNARK dla danego twierdzenia do udowodnienia zawiera już wartości potrzebne Alicji, aby mogła dostarczyć kompletny dowód posiadania rozwiązania twierdzenia do udowodnienia. W ten sposób strona weryfikująca nie musi już wysyłać żadnych wartości stronie dowodzącej. Dostarczenie dowodu z wiedzą zerową, może być wykonane tylko i wyłącznie przez Alicję, przez co otrzymujemy ostatecznie kompletny protokół zk-SNARK.

Na pojedynczy dowód w zk-SNARK składa się w praktyce kilka wartości, które przy wykorzystaniu opisanych wcześniej mechanizmów umożliwiają kompletną weryfikację poprawności dowodu i samego rozwiązania dowodzącego (oczywiście bez znajomości tego rozwiązania przez weryfikującego).

9. Słowo o CRS (Common Reference String) i toksycznych odpadach

Opisując kompletny zk-SNARK, przedstawiliśmy istnienie elementu, który zaszyty w protokole jest formą rozwiązania użytego następnie do tworzenia dowodów z wiedzą zerową przez dowodzącego. Dane, które są zaszyfrowane w protokole i które konieczne są do tworzenia dowodów dla danego twierdzenia, określa się jako CRS (Common Reference String).

Wartość CRS to tak naprawdę zabezpieczony kryptograficznie zestaw danych, które zawierają m.in. obliczone wartości funkcji homomorficznej w pewnym losowo wybranym punkcie |s|, których następnie weryfikacja jest kluczowa dla tworzenia dowodów (mowa o |E(s^0), E(s^1), …, E(s^d)|). W artykule tym często przedstawiałem wartości, które miały być losowe. Mechanika funkcji homomorficznych (z uwzględnieniem pewnych przekształceń) uniemożliwia ujawnienie wartości argumentu, dla którego została obliczona wartość takiej funkcji. Opisywany wcześniej parameter |s| jest między innymi taką daną: musi zostać wykorzystany przez weryfikującego do wygenerowania wartości funkcji homomorficznej, które następnie będą wykorzystane przez dowodzącego. Sam jednak parametr |s| absolutnie nie może być znany dowodzącemu. Jest to dana, która musi pozostać nieznana w całym protokole zk-SNARK dla danego twierdzenia – jej losowość i absolutna tajność jest kluczowa dla poprawności działania protokołu.

Jeśli tworzymy protokół, w którym wartości mają być wygenerowane tylko raz – dane, takie jak |s| (oraz jeszcze kilka innych losowych danych, o których już nie będę wspominać), które następnie są wykorzystywane w tworzeniu CRS dla danego protokołu dowodzenia zk-SNARK muszą zostać wygenerowane poufnie, a następnie usunięte. Te dane są określane jako toksyczne odpady (toxic waste). Poznanie ich może prowadzić do możliwości tworzenia fałszywych dowodów. Dlatego też ZCash pisał na swoim blogu o Ceremonii generowania tych parametrów w sposób maksymalnie poufny i bezpieczny.

Podsumowanie

W artykule przedstawiłem proces tworzenia i definiowania protokołu zk-SNARK dla dowodzenia twierdzeń z wiedzą zerową. Wartości reprezentujące CRS oraz same dowody zk-SNARK są w praktyce maksymalnie optymalizowane. Zakres danych obejmuje konieczne minimum zaprezentowane w odpowiedniej postaci, celem jest oczywiście minimalny narzut sieciowego przesyłu danych oraz samego przetwarzania. Sam proces tworzenia dowodów obejmuje jeszcze kilka innych przekształceń uniemożliwiających nadużycie działania protokołu i fałszowania dowodów.

Dowody z wiedzą zerową mogą moim zdaniem realnie zrewolucjonizować przepływ cyfrowej informacji. Ten niezwykle piękny matematyczny mechanizm, to forma świętego graala prywatności i poufności. Protokół zk-SNARK to instrukcja implementacji algorytmu dowodzenia posiadania informacji, bez konieczności ujawniania tej informacji. W świecie blockchaina znalazł już realne zastosowanie w kryptowalucie ZCash, a jego integracją zajmują się inne projekty, jak choćby Ethereum. Mechanizmy dowodzenia z wiedzą zerową, mają potencjał znaleźć wiele realnych zastosowań, dokonując na swój sposób przewrotu w podejściu do traktowania informacji i dowodzenia prawdy. Jednocześnie efekt tej pięknej symbiozy matematyki z technologią daje nam gwarancję poprawności i ostatecznie zaufanie, ponieważ… matematyka się nie myli.