Strona Główna
Artykuły
Poprawa Transparentności Krypto Dzięki Zero-Knowledge Proof

Poprawa Transparentności Krypto Dzięki Zero-Knowledge Proof

Średnio zaawansowany
Opublikowane Feb 10, 2023Zaktualizowane Jan 5, 2024
10m

TL;DR

Dowód zerowej wiedzy pozwala jednej stronie (weryfikatorowi) określić ważność stwierdzenia, podanego przez inną stronę (dowodzącego), bez znajomości treści stwierdzenia. Na przykład, Binance może chcieć udowodnić, iż w pełni zabezpieczyło środki swoich użytkowników w rezerwach, bez ujawniania wszystkich sald poszczególnych użytkowników.

"Dowód rezerw" można skonstruować za pomocą drzewa Merkle'a, które chroni przed fałszowaniem wewnętrznych danych, w tym przypadku całkowitych sald klientów netto, będących zobowiązaniami giełdy wobec użytkowników. Można to następnie połączyć z zk-SNARK (protokołem dowodu zerowej wiedzy), który zapewnia użytkownikom możliwość sprawdzenia, czy ich saldo stanowi część całkowitego salda aktywów netto użytkownika, bez znajomości indywidualnych sald.

Wprowadzenie

W świetle wydarzeń rynkowych, bezpieczeństwo aktywów krypto w depozycie stało się krytycznym tematem. Użytkownicy blockchainu wysoko cenią sobie przejrzystość i otwartość, ale także oczekują prywatności i poufności. Stwarza to dylemat przy udowadnianiu rezerw funduszy, przechowywanych przez powierników. Często istnieje kompromis między przejrzystością, zaufaniem i poufnością danych.

Jednak, nie musi zawsze tak być. Łącząc protokoły dowodu zerowej wiedzy, takie jak zk-SNARK z drzewami Merkle'a, możemy znaleźć skuteczne rozwiązanie dla wszystkich stron.

Czym jest dowód zerowej wiedzy?

Dowód zerowej wiedzy pozwala jednej stronie (weryfikatorowi), określić ważność stwierdzenia podanego przez inną stronę (udowadniającego), bez znajomości treści stwierdzenia. Spójrzmy na prosty przykład.

Masz zamknięty sejf, do którego tylko ty znasz szyfr. Sejf, na potrzeby przykładu, nie może zostać podniesiony, otwarty siłą ani w żaden inny sposób, niż poprzez znajomość kombinacji. Fakt ten jest również ustalony, zweryfikowany i znany przez Twojego przyjaciela, biorącego udział w eksperymencie.

Mówisz przyjacielowi, że znasz kombinację, ale nie chcesz jej zdradzać ani otwierać sejfu przed nim. Na górze sejfu znajduje się otwór, przez który Twój przyjaciel może wrzucić do środka notkę. Aby był to dowód zerowej wiedzy, Twój przyjaciel nie powinien mieć żadnych dodatkowych informacji o procesie, poza podanym stwierdzeniem.

Możesz udowodnić swojemu przyjacielowi, że znasz szyfr, otwierając sejf, oraz mówiąc mu, co było napisane w notce i zamykając ponownie sejf. W całym tym procesie nigdy nie musiałeś(-aś) ujawniać kombinacji.

Bardziej zaawansowany przykład można znaleźć w naszym artykule Czym jest dowód zerowej wiedzy i jaki ma to wpływ na blockchain? .

Dlaczego używamy dowodów zerowej wiedzy?

Dowody zerowej wiedzy są odpowiednie do udowodnienia czegoś, bez konieczności ujawniania poufnych informacji lub szczegółów. Może tak być w przypadku, gdy nie chcesz przekazywać swoich danych finansowych lub osobowych, które mogłyby zostać niewłaściwie wykorzystane.

W krypto możesz udowodnić, że posiadasz klucz prywatny bez ujawniania go, lub cyfrowego podpisywania czegokolwiek. Giełda krypto może również chcieć udowodnić stan swoich rezerw, bez ujawniania poufnych informacji o swoich użytkownikach, w tym ich indywidualnych sald kont. 

Dla tych przykładów (i wielu innych) dowód zerowej wiedzy wykorzystywałby algorytmy, które pobierają dane wejściowe i zwracają "prawdę" lub "fałsz" jako wynik. 

Definiowanie dowodów zerowej wiedzy w kategoriach technicznych

Dowód zerowej wiedzy, w kategoriach technicznych, ma określoną strukturę z pewnymi kryteriami. Omówiliśmy już role udowadniającego i weryfikatora, ale istnieją również trzy kryteria, które powinien spełniać dowód zerowej wiedzy:

  1. Kompletność. Jeśli oświadczenie jest prawdziwe, weryfikator zostanie przekonany przez dostarczony dowód, bez potrzeby jakichkolwiek innych informacji lub weryfikacji.

  2. Solidność. Jeśli stwierdzenie jest fałszywe, weryfikator nie zostanie przekonany o prawdziwości stwierdzenia przez dostarczony dowód.

  3. Zerowa wiedza. Jeśli stwierdzenie jest prawdziwe, weryfikator nie dowiaduje się żadnych informacji poza tym, że stwierdzenie jest prawdziwe.

Czym jest zk-SNARK?

zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) to protokół dowodowy, który jest zgodny z zasadami wiedzy zerowej opisanymi wcześniej. Za pomocą zk-SNARK można udowodnić, że zna się oryginalną haszowaną wartość (omówioną poniżej) bez ujawniania, jaka ona jest. Można również udowodnić ważność transakcji, bez ujawniania jakichkolwiek informacji o konkretnych kwotach, wartościach lub zaangażowanych adresach.

zk-SNARK są powszechnie używane i omawiane w świecie blockchaina i kryptowalut. Można się jednak zastanawiać, dlaczego ktoś miałby zawracać sobie głowę używaniem zk-SNARK, skoro mógłby użyć prostej metody pary klucza publicznego i prywatnego do zabezpieczenia informacji. Nie bylibyśmy jednak w stanie zaimplementować dowodu matematycznego, aby upewnić się, że żadne ujemne salda nie są uwzględniane i suma drzewa Merkle. 

W przypadku rezerw giełdy, chcemy udowodnić zabezpieczenie sald klientów w stosunku 1:1, bez upubliczniania identyfikatorów i sald każdego konta. Ponadto, technologia zk-SNARK sprawia, że fałszowanie danych jest jeszcze mniej prawdopodobne.

Czym jest drzewo Merkle?

Przedstawienie zsumowanych środków na kontach użytkowników Binance, wymaga pracy z dużym zbiorem danych. Jednym ze sposobów kryptograficznej prezentacji tak dużej ilości danych, jest użycie drzewa Merkle. Można w nim efektywnie przechowywać ogromne ilości informacji, a jego kryptograficzna natura sprawia, iż jego integralność jest łatwo weryfikowalna.

Funkcje haszujące

Aby zwięźle zakodować dane wejściowe, drzewo Merkle'a zależy od użycia funkcji haszowania. W skrócie, haszowanie to proces generowania danych wyjściowych o stałym rozmiarze, z danych wejściowych o zmiennym rozmiarze. Innymi słowy, gdy dane wejściowe o dowolnej długości zostaną zahaszowane za pomocą algorytmu, otrzymamy zaszyfrowane dane wyjściowe o stałej długości.

Tak długo, jak dane wejściowe pozostają takie same, tak samo będzie z danymi wyjściowymi. Oznacza to, że możemy pobrać ogromne ilości danych transakcyjnych i zahaszować je, do postaci możliwych do zarządzania danych wyjściowych. Dane wyjściowe będą radykalnie inne, jeśli jakiekolwiek informacje zostaną zmienione na wejściu.

Na przykład, możemy wziąć zawartość stu książek i wprowadzić je do funkcji haszowania SHA-256. Na wyjściu otrzymamy coś takiego:

801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea

Jeśli następnie zmienilibyśmy pojedynczy znak w danych wejściowych (w tych stu książkach), hash byłby zupełnie inny, na przykład:

abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410

Jest to ważna właściwość funkcji haszowania, ponieważ pozwala na łatwą weryfikację dokładności danych. Jeśli ktokolwiek powieli proces haszowania tych samych 100 książek, przy użyciu algorytmu SHA-256, otrzyma dokładnie taki sam hash jak dane wyjściowe. Jeśli dane wyjściowe są inne, możemy z całą pewnością stwierdzić, że dane wejściowe zostały zmienione. Oznacza to, że nie ma potrzeby indywidualnego lub ręcznego sprawdzania różnic między danymi wejściowymi, co może być pracochłonne.

Drzewa Merkle w świecie kryptowalut

Podczas przechowywania danych transakcji na blockchainie, każda nowa transakcja jest przesyłana za pomocą funkcji haszowania, która generuje unikalne wartości hash. Wyobraźmy sobie, że mamy osiem transakcji (od A do H), które indywidualnie haszujemy, aby uzyskać ich zahaszowane dane wyjściowe. To jest to, co nazywamy węzłami liścia Merkle. Na poniższym obrazku, można zobaczyć unikalną wartość hash dla każdej litery: hA dla A, hB dla B, hC dla C itd.

Następnie możemy pobrać pary zahaszowanych danych wyjściowych, połączyć je i otrzymać nowe zahaszowane dane wyjściowe. Na przykład, haszowane hA i hB połączone razem, dałyby nam nowe zahaszowane dane wyjściowe hAB, znane jako gałąź Merkle. Należy pamiętać, że za każdym razem, gdy generowane są nowe dane wyjściowe, mają one stałą długość i rozmiar, zgodnie z zastosowaną funkcją haszowania.

Teraz mamy dane dwóch transakcji (np. A i B), połączone w jeden hash (hAB). Zauważ, że jeśli zmienimy jakąkolwiek informację z A lub B i powtórzymy proces, nasze zahaszowane dane wyjściowe hAB będą zupełnie inne.

Proces ten jest kontynuowany, gdy łączymy nowe pary hashy, aby ponownie je haszować (patrz obrazek poniżej). Haszujemy hAB z hCD, aby uzyskać unikalny hash hABCD i robimy to samo z hEF i hGH, aby uzyskać hEFGH. Na końcu otrzymujemy pojedynczy hash, reprezentujący zahaszowane dane wyjściowe, wszystkich poprzednich haszowanych transakcji. Innymi słowy, zahaszowany wynik hABCDEFGH reprezentuje wszystkie informacje, które pojawiły się wcześniej.

Wyświetlony powyżej graf nazywany jest drzewem Merkle, a zahaszowany wynik hABCDEFGH jest korzeniem Merkle. Używamy korzeni Merkle w nagłówkach bloków, ponieważ kryptograficznie podsumowują wszystkie dane transakcji w bloku, w zwięzły sposób. Możemy również szybko zweryfikować, czy jakiekolwiek dane zostały naruszone lub zmienione w bloku.

Ograniczenia drzewa Merkle

Wróćmy do naszego przykładu rezerw CEX. CEX chce udowodnić zabezpieczenie w stosunku 1:1 wszystkich aktywów swoich klientów i buduje drzewo Merkle, które łączy identyfikatory UID klientów z ich aktywami netto (kompensując aktywa i pasywa) na poziomie tokena. Po udostępnieniu (i podpisaniu, w celu udowodnienia własności dostarczonego korzenia Merkle), indywidualny użytkownik nie miałby żadnej możliwości sprawdzenia, czy drzewo Merkle jest prawidłowe, bez dostępu do wszystkich jego danych wejściowych.

Giełda nie wykorzystuje niektórych danych wejściowych. Mogłoby to również tworzyć fałszywe konta z ujemnymi saldami, aby zmienić całkowite zobowiązania. Na przykład, chociaż aktywa klientów mogą wynosić 1 000 000 $, mogłoby zostać dodane fałszywe konto z saldem -500 000 $. Pozwoliłoby to na utworzenie rezerw w wysokości zaledwie 500 000 $.

Przypadek dla dowodu rezerw różni się od korzenia Merkle bloku, ponieważ użytkownicy mogą zobaczyć wszystkie transakcje, zawarte w bloku w eksploratorze blockchain. CEX nie będzie jednak chciał ujawniać salda każdego konta, ze względów bezpieczeństwa i ochrony prywatności danych. Również klienci nie byliby zadowoleni z upublicznienia sald ich kont. W takim przypadku CEX nie może udowodnić, że salda użytkowników sumują się do prawidłowej sumy, bez uwidocznienia sald innych użytkowników.

Jednym z rozwiązań, które giełdy mogą rozważyć, jest skorzystanie z usług zaufanego audytora zewnętrznego. Audytor może sprawdzić poszczególne konta i rezerwy, przed ostatecznym potwierdzeniem ważności dostarczonego korzenia Merkle. Jednak dla użytkowników, metoda ta wymaga zaufania do audytora i danych wykorzystanych do audytu. Nie musisz polegać na stronie zewnętrznej, gdy możesz zaufać danym.

Łączenie zk-SNARK z drzewami Merkle

Powyższe zagadnienie jest doskonałym przykładem zastosowania zk-SNARK. Chcemy udowodnić, że rezerwy w pełni pokrywają zobowiązania użytkownika i nie są sfałszowane. Jednak ze względów bezpieczeństwa i ochrony prywatności, nie chcemy pokazywać weryfikatorowi dokładnego składu sald i rezerw użytkowników. 

Korzystając z zk-SNARK, giełda krypto może udowodnić, że wszystkie zestawy sald węzłów liścia drzewa Merkle (tj. salda kont użytkowników) przyczyniają się do deklarowanego całkowitego salda aktywów użytkownika giełdy. Każdy użytkownik może łatwo uzyskać dostęp do swojego węzła liścia, który został uwzględniony w procesie. Zk-SNARK zapewnia również, że żadne wygenerowane drzewo Merkle nie zawiera użytkowników z ujemnym całkowitym saldem aktywów netto (co oznaczałoby fałszowanie danych, ponieważ wszystkie pożyczki są ponad miarę zabezpieczone). Wykorzystywane są również obliczenia globalnego stanu Binance, tj. lista całkowitego salda netto każdego aktywa, posiadanego przez każdego klienta Binance.

Przyjrzyjmy się, jak Binance podchodzi do tej sytuacji. Na początek Binance definiuje ograniczenia obliczeń, które chce udowodnić i definiuje je jako programowalny obwód. Poniżej znajduje się zestaw trzech ograniczeń, które Binance wykorzystuje w swoim modelu. 

Dla każdego zestawu sald użytkownika, (węzła liścia drzewa Merkle) nasz obwód zapewnia, że:

  1. Salda aktywów użytkownika, są uwzględniane w obliczeniach sumy całkowitych sald netto użytkownika na Binance.

  2. Całkowite saldo netto użytkownika jest większe lub równe zero.

  3. Zmiana korzenia drzewa Merkle jest prawidłowa (tj. nie używa sfałszowanych informacji) po zaktualizowaniu informacji użytkownika do hasha węzła liścia.

Binance może następnie wygenerować dowód zk-SNARK dla konstrukcji drzewa Merkle, zgodnie z obwodem. Wiąże się to z wykonywaniem przez giełdę ciężkich obliczeń polegających na haszowaniu identyfikatorów użytkowników i sald, przy jednoczesnym zapewnieniu, że dowód spełnia ograniczenia.

Weryfikator sprawdzi dowód (i jego publicznie udostępniony kod źródłowy), aby przekonać się, że obliczenia zostały wykonane z zachowaniem wszystkich ograniczeń. Obliczenia weryfikacyjne trwają niezwykle krótko, w porównaniu z czasem weryfikacji.

Przy każdej publikacji Dowodu Rezerw, giełda będzie publikować:

1. Dowód Merkle dla każdego użytkownika.

2. Dowód zk-SNARK i publiczne dane wejściowe (hash listy całkowitego salda netto każdego zasobu i korzenia Merkle) obwodu dla wszystkich użytkowników.

Zainteresowane strony mogą zweryfikować dowód Merkle, upewniając się, że ich indywidualne salda przyczyniły się do powstania korzenia drzewa Merkle. Mogą również zweryfikować dowód zk-SNARK, aby upewnić się, że konstrukcja drzewa Merkle'a spełnia ograniczenia zdefiniowane w obwodzie. Bardziej szczegółowe wyjaśnienie rozwiązania zk-SNARK i jego wydajności, można znaleźć na naszym blogu Jak zk-SNARK poprawia system Dowodu Rezerw na Binance.

Wnioski Końcowe

zk-SNARK zapewniają technologię potrzebną do zapewnienia zarówno integralności danych, jak i prywatności w tym samym czasie. Jego zastosowanie do udowadniania rezerw i zwiększania przejrzystości CEX, powinno pomóc w budowaniu zaufania w branży blockchain. Dla wielu, taki rozwój wydarzeń był długo oczekiwany i pojawia się w kluczowym momencie dla CEX-ów.

Jest to pierwsza wersja naszego zk-SNARK i z niecierpliwością czekamy na otrzymywanie informacji zwrotnej od społeczności, abyśmy mogli nadal ulepszać system.

Dalsza Lektura