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