Wprowadzenie do zk-SNARKs

blog 1AktualnościDevelopersEnterpriseBlockchain ExplainedWydarzenia i konferencjePrasaBiuletyny

Zapisz się do naszego newslettera.

Adres e-mail

Szanujemy twoją prywatność

HomeBlogBlockchain Development

Wprowadzenie do zk-SNARKs

Przegląd dowodów o zerowej wiedzy i jak zintegrować zk-SNARKs z Ethereum. przez ConsenSysMarca 27, 2017 Opublikowany w marcu 27, 2017

bohater domowy

W tym poście staramy się przedstawić przegląd zk-SNARKs z praktycznego punktu widzenia. Potraktujemy rzeczywistą matematykę jako czarną skrzynkę i spróbujemy rozwinąć intuicję dotyczącą tego, jak możemy z nich korzystać. Podamy również proste zastosowanie ostatnich prac nad integracja zk-SNARKs w Ethereum.

Dowody braku wiedzy

Celem dowodów o wiedzy zerowej jest przekonanie weryfikatora, że ​​dowódca posiada wiedzę o tajnym parametrze, zwanym świadkiem, spełniając jakąś relację, bez ujawniania świadka weryfikatorowi ani nikomu innemu.

Możemy myśleć o tym bardziej konkretnie jako o programie, oznaczonym C, pobierającym dwa dane wejściowe: C (x, w). Wejście x to wejście publiczne, aw to wejście tajnego świadka. Dane wyjściowe programu są logiczne, tj. Prawda lub fałsz. Następnie cel otrzymuje określone wejście publiczne x, udowodnić, że osoba dowodząca zna tajne dane wejściowe w takie, że C (x, w) == true.

W szczególności omówimy nieinteraktywne dowody wiedzy zerowej. Oznacza to, że sam dowód jest zbiorem danych, które można zweryfikować bez żadnej interakcji ze strony weryfikatora.

Przykładowy program

Załóżmy, że Bob otrzymuje hash H o jakiejś wartości i chce mieć dowód na to, że Alicja zna wartość s, która jest hashowana do H. Zwykle Alice udowadnia to, podając s Bobowi, po czym Bob obliczy hash i sprawdzi, czy równa się H..

Załóżmy jednak, że Alicja nie chce ujawnić Bobowi wartości s, ale zamiast tego chce tylko udowodnić, że zna tę wartość. Może do tego użyć zk-SNARK.

Możemy opisać scenariusz Alicji za pomocą następującego programu, tutaj zapisanego jako funkcja JavaScript:


function C (x, w) {return (sha256 (w) == x);} Język kodu: JavaScript (javascript)

Innymi słowy: program pobiera publiczny skrót x i tajną wartość wi zwraca prawdę, jeśli wartość skrótu SHA – 256 w równa się x.

Tłumacząc problem Alicji za pomocą funkcji C (x, w), widzimy, że Alicja musi stworzyć dowód, że posiada takie wartości, że C (H, s) == prawda, bez konieczności ujawniania s. To jest ogólny problem, który rozwiązują zk-SNARKs.

Definicja zk-SNARK

Zk-SNARK składa się z trzech algorytmów G, P, V zdefiniowanych w następujący sposób:

Generator kluczy G pobiera tajną parametryczną lambdę i program C oraz generuje dwa publicznie dostępne klucze, klucz potwierdzający pk i klucz weryfikacyjny vk. Te klucze są parametrami publicznymi, które muszą zostać wygenerowane tylko raz dla danego programu C.

Przysłowie P przyjmuje jako dane wejściowe klucz dowodowy pk, wejście publiczne x i świadka prywatnego w. Algorytm generuje dowód prf = P (pk, x, w), że dowodzący zna świadka wi, że świadek spełnia program.

Weryfikator V oblicza V (vk, x, prf), które zwraca prawdę, jeśli dowód jest poprawny, a fałsz w przeciwnym razie. Zatem ta funkcja zwraca prawdę, jeśli osoba potwierdzająca wie, że świadek spełnia C (x, w) == prawda.

Zwróć uwagę na tajny parametr lambda używany w generatorze. Ten parametr czasami utrudnia użycie zk-SNARK w rzeczywistych aplikacjach. Powodem tego jest to, że każdy, kto zna ten parametr, może generować fałszywe dowody. W szczególności, biorąc pod uwagę dowolny program C i publiczne dane wejściowe x, osoba znająca lambdę może wygenerować dowód fake_prf taki, że V (vk, x, fake_prf) przyjmuje wartość true bez znajomości sekretu w.

W związku z tym faktyczne uruchomienie generatora wymaga bardzo bezpiecznego procesu, aby mieć pewność, że nikt nigdzie nie dowie się o parametrze i nie zapisze go. To był powód niezwykle wyszukana ceremonia zespół Zcash prowadził w celu wygenerowania klucza dowodowego i klucza weryfikacyjnego, upewniając się, że parametr „toksyczne odpady” lambda został zniszczony w procesie.

A zk-SNARK dla naszego przykładowego programu

W jaki sposób Alicja i Bob użyliby zk-SNARK w praktyce, aby Alice mogła udowodnić, że zna tajną wartość z powyższego przykładu?

Przede wszystkim, jak omówiono powyżej, użyjemy programu zdefiniowanego następującą funkcją:

funkcja C (x, w) {return (sha256 (w) == x); } Język kodu: JavaScript (javascript)

Pierwszym krokiem Boba jest uruchomienie generatora G w celu utworzenia klucza sprawdzającego pk i klucza weryfikacyjnego vk. Najpierw losowo wygeneruj lambdę i użyj jej jako danych wejściowych:

(pk, vk) = G (C, lambda)

Z parametrem lambda obchodź się ostrożnie, ponieważ jeśli Alicja pozna wartość lambda, będzie mogła tworzyć fałszywe dowody. Bob podzieli się pk i vk z Alice.

Alicja wcieli się teraz w rolę przysłowiowej osoby. Musi udowodnić, że zna wartość s, która łączy się ze znanym hashem H. Uruchamia algorytm dowodzenia P, używając danych wejściowych pk, H i s, aby wygenerować dowód prf:

prf = P (pk, H, s)

Następnie Alicja przedstawia dowód prf Bobowi, który uruchamia funkcję weryfikacji V (vk, H, prf), która w tym przypadku zwróci wartość true, ponieważ Alicja dobrze zna sekret s. Bob może być pewien, że Alicja znała sekret, ale Alice nie musiała ujawniać sekretu Bobowi.

Klucze potwierdzające i weryfikacyjne wielokrotnego użytku

W powyższym przykładzie zk-SNARK nie można użyć, jeśli Bob chce udowodnić Alicji, że zna sekret, ponieważ Alicja nie może wiedzieć, że Bob nie zapisał parametru lambda. Bob mógłby być w stanie sfałszować dowody.

Jeśli program jest przydatny dla wielu osób (jak przykład Zcash), zaufana niezależna grupa niezależna od Alice i Boba mogłaby uruchomić generator i utworzyć klucz dowodzący pk i klucz weryfikacyjny vk w taki sposób, że nikt nie dowie się o lambdzie.

Każdy, kto wierzy, że grupa nie oszukiwała, może użyć tych kluczy do przyszłych interakcji.

zk-SNARKs w Ethereum

Programiści już zaczęli integrować zk-SNARKs z Ethereum. Jak to wygląda? Konkretnie, możesz dodać elementy składowe algorytmu weryfikacji do Ethereum w postaci wstępnie skompilowanych kontraktów. Oto jak: uruchomić generator poza łańcuchem, aby wygenerować klucz potwierdzający i klucz weryfikacyjny. Każdy dowódca może następnie użyć klucza dowodowego, aby stworzyć dowód, również poza łańcuchem. Następnie można uruchomić ogólny algorytm weryfikacji w inteligentnej umowie, używając dowodu, klucza weryfikacyjnego i publicznych danych wejściowych jako parametrów wejściowych. Następnie możesz użyć wyniku algorytmu weryfikacji, aby wywołać inną aktywność w łańcuchu.

Przykład: transakcje poufne

Oto prosty przykład tego, jak zk-SNARKs może pomóc w ochronie prywatności w Ethereum. Załóżmy, że mamy prostą umowę na token. Zwykle kontrakt na token miałby w swej istocie odwzorowanie adresów na salda:

mapowanie (adres => uint256) salda; Język kodu: JavaScript (javascript)

Zachowamy ten sam podstawowy rdzeń, z wyjątkiem zastąpienia salda hashem salda:

mapowanie (adres => bytes32) balanceHashes; Język kodu: JavaScript (javascript)

Nie będziemy ukrywać nadawcy ani odbiorcy transakcji. Ale ukryjemy salda i wysłane kwoty. Ta właściwość jest czasami nazywana poufne transakcje.

Użyjemy dwóch zk-SNARK do wysyłania tokenów z jednego konta na drugie. Jeden dowód jest tworzony przez nadawcę, a drugi przez odbiorcę.

Zwykle w umowie tokenowej, aby transakcja o wartości rozmiaru była ważna, musimy zweryfikować następujące kwestie:

salda [fromAddress] >= wartość

Nasze zk-SNARKs muszą udowodnić, że to obowiązuje, a także, że zaktualizowane skróty odpowiadają zaktualizowanym saldom.

Główną ideą jest to, że nadawca użyje swojego salda początkowego i wartości transakcji jako prywatnych danych wejściowych. Jako publiczne dane wejściowe używają skrótów salda początkowego, salda końcowego i wartości. Podobnie odbiornik użyje bilansu początkowego i wartości jako tajnych danych wejściowych. Jako publiczne dane wejściowe używają skrótów salda początkowego, salda końcowego i wartości.

Poniżej znajduje się program, którego użyjemy dla nadawcy zk-SNARK, gdzie jak poprzednio x reprezentuje wejście publiczne, aw reprezentuje wejście prywatne.

function senderFunction (x, w) {return (w.senderBalanceBefore > w.value && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Język kodu: JavaScript (javascript)

Program używany przez odbiornik znajduje się poniżej:

function receiverFunction (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} Język kodu: JavaScript (javascript)

Programy sprawdzają, czy saldo wysyłania jest większe niż wysyłana wartość, a także sprawdza, czy wszystkie skróty są zgodne. Zaufany zbiór osób wygenerowałby klucze potwierdzające i weryfikacyjne dla naszych zk-SNARKs. Nazwijmy je confTxSenderPk, confTxSenderVk, confTxReceiverPk i confTxReceiverVk.

Używanie zk-SNARKs w umowie tokenowej wyglądałoby mniej więcej tak:

transfer funkcji (address _to, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, bajty zkProofSender, bajty zkProofReceiver) {bytes32 hashSenderBalanceBefore = balanceHashes [msg.sender]; bytes32 hashReceiverBalanceBefore = balanceHashes [_to]; bool senderProofIsCorrect = zksnarkverify (confTxSenderVk, [hashSenderBalanceBefore, hashSenderBalanceAfter, hashValue], zkProofSender); bool receiverProofIsCorrect = zksnarkverify (confTxReceiverVk, [hashReceiverBalanceBefore, hashReceiverBalanceAfter, hashValue], zkProofReceiver); if (senderProofIsCorrect && receiverProofIsCorrect) {balanceHashes [msg.sender] = hashSenderBalanceAfter; balanceHashes [_to] = hashReceiverBalanceAfter; }} Język kodu: JavaScript (javascript)

Dlatego jedynymi aktualizacjami w łańcuchu bloków są skróty sald, a nie same salda. Możemy jednak wiedzieć, że wszystkie salda są poprawnie zaktualizowane, ponieważ możemy sami sprawdzić, czy dowód został zweryfikowany.

Detale

Powyższy schemat transakcji poufnych ma głównie na celu podanie praktycznego przykładu wykorzystania zk-SNARKs na Ethereum. Aby stworzyć solidny schemat transakcji poufnych, musielibyśmy rozwiązać szereg problemów:

  • Użytkownicy musieliby śledzić swoje salda po stronie klienta, a jeśli stracisz saldo, te tokeny będą nieodwracalne. Salda mogłyby być przechowywane w postaci zaszyfrowanej w łańcuchu za pomocą klucza pochodzącego z klucza podpisującego.
  • Wagi muszą wykorzystywać 32 bajty danych i kodować entropię, aby uniemożliwić odwrócenie skrótów w celu obliczenia sald.
  • Musisz poradzić sobie z skrajnym przypadkiem wysyłania na nieużywany adres.
  • W celu wysłania nadawca musi współpracować z odbiorcą. Potencjalnie mógłby istnieć system, w którym nadawca wykorzystuje swój dowód do zainicjowania transakcji. Odbiorca może wtedy zobaczyć w łańcuchu bloków, że ma „oczekującą transakcję przychodzącą” i może ją sfinalizować.

Biuletyn Zapisz się do naszego newslettera, aby otrzymywać najnowsze wiadomości dotyczące Ethereum, rozwiązania dla przedsiębiorstw, zasoby dla programistów i nie tylko.Jak zbudować udany produkt BlockchainWebinar

Jak zbudować udany produkt Blockchain

Jak skonfigurować i uruchomić węzeł EthereumWebinar

Jak skonfigurować i uruchomić węzeł Ethereum

Jak zbudować własny interfejs API EthereumWebinar

Jak zbudować własny interfejs API Ethereum

Jak stworzyć token społecznościowyWebinar

Jak stworzyć token społecznościowy

Korzystanie z narzędzi bezpieczeństwa w tworzeniu inteligentnych kontraktówWebinar

Korzystanie z narzędzi bezpieczeństwa w tworzeniu inteligentnych kontraktów

Przyszłość finansów, aktywów cyfrowych i DeFiWebinar

Przyszłość finansów: aktywa cyfrowe i DeFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
Adblock
detector
map