Въведение в zk-SNARKs

блог 1NewsDevelopersEnterpriseBlockchain ExplainedEvent and ConferencesPressБюлетини

Абонирайте се за нашия бюлетин.

Имейл адрес

Ние уважаваме вашата поверителност

Развитие на HomeBlogBlockchain

Въведение в zk-SNARKs

Преглед на доказателствата за нулево знание и как да интегрирате zk-SNARKs в Ethereum. от ConsenSys 27 март 2017 г. Публикувано на 27 март 2017 г.

домашен герой

В тази публикация се стремим да дадем преглед на zk-SNARKs от практическа гледна точка. Ще се отнасяме към действителната математика като към черна кутия и ще се опитаме да развием някои интуиции около това как можем да ги използваме. Ще дадем и просто приложение на скорошната работа по интегриране на zk-SNARKs в Ethereum.

Доказателства с нулево знание

Целта на доказателствата с нулево знание е проверяващият да може да се убеди, че проверяващият притежава знания за таен параметър, наречен свидетел, удовлетворяващ някаква връзка, без да разкрива свидетеля на проверяващия или някой друг.

Можем да мислим за това по-конкретно като за програма, обозначена с C, която приема два входа: C (x, w). Входът x е публичният вход, а w е входът на тайния свидетел. Резултатът от програмата е булев, т.е. или true, или false. След това на целта се дава конкретен публичен вход x, докажете, че проверяващият знае таен вход w такъв, че C (x, w) == true.

Специално ще обсъдим неинтерактивни доказателства за нулеви знания. Това означава, че самото доказателство е блок от данни, който може да бъде проверен без каквото и да е взаимодействие от проверяващия.

Примерна програма

Да предположим, че на Боб му е даден хеш H с някаква стойност и той иска да има доказателство, че Алис знае стойността s, която хешира към H. Обикновено Алис би доказала това, като даде s на Боб, след което Боб ще изчисли хеша и ще провери дали то е равно на H.

Да предположим обаче, че Алис не иска да разкрие стойността на Боб, а вместо това просто иска да докаже, че знае стойността. Тя може да използва zk-SNARK за това.

Можем да опишем сценария на Алис, като използваме следната програма, написана тук като функция на Javascript:


функция C (x, w) {return (sha256 (w) == x);} Език на кода: JavaScript (javascript)

С други думи: програмата приема публичен хеш x и секретна стойност w и връща true, ако хеш SHA-256 от w е равен на x.

Превеждайки проблема на Алиса с помощта на функцията C (x, w), виждаме, че Алиса трябва да създаде доказателство, че притежава s такова, че C (H, s) == true, без да се налага да разкрива s. Това е основният проблем, който zk-SNARKs решават.

Определение на zk-SNARK

Zk-SNARK се състои от три алгоритма G, P, V, дефинирани както следва:

Генераторът на ключове G взема таен параметър ламбда и програма C и генерира два публично достъпни ключа, доказателствен ключ pk и ключ за проверка vk. Тези ключове са публични параметри, които трябва да бъдат генерирани само веднъж за дадена програма C.

Проверяващият P приема като вход доказателствения ключ pk, публичен вход x и частен свидетел w. Алгоритъмът генерира доказателство prf = P (pk, x, w), че проверяващият познава свидетел w и че свидетелят удовлетворява програмата.

Проверяващият V изчислява V (vk, x, prf), който връща true, ако доказателството е вярно, и false в противен случай. По този начин тази функция връща true, ако доказващият познава свидетел w, удовлетворяващ C (x, w) == true.

Забележете тук тайния параметър ламбда, използван в генератора. Този параметър понякога прави трудно използването на zk-SNARKs в реални приложения. Причината за това е, че всеки, който познава този параметър, може да генерира фалшиви доказателства. По-конкретно, като се има предвид всяка програма C и публично въвеждане x, човек, който знае ламбда, може да генерира доказателство fake_prf, така че V (vk, x, fake_prf) да оцени като true, без да знае тайната w.

По този начин действителното стартиране на генератора изисква много сигурен процес, за да е сигурно, че никой не научава и запазва параметъра навсякъде. Това беше причината за изключително сложна церемония екипът на Zcash проведе, за да генерира доказателствен ключ и ключ за проверка, като същевременно се увери, че параметърът „токсични отпадъци“ ламбда е бил унищожен в процеса.

Zk-SNARK за примерната ни програма

Как биха използвали Алис и Боб на практика zk-SNARK, за да може Алис да докаже, че знае тайната стойност в примера по-горе?

На първо място, както беше обсъдено по-горе, ще използваме програма, дефинирана от следната функция:

функция C (x, w) {return (sha256 (w) == x); } Език на кода: JavaScript (javascript)

Първата стъпка е Боб да пусне генератора G, за да създаде доказателствен ключ pk и ключ за проверка vk. Първо, произволно генерирайте ламбда и използвайте това като вход:

(pk, vk) = G (C, ламбда)

Работете внимателно с параметъра ламбда, защото ако Алис научи стойността на ламбда, тя ще може да създава фалшиви доказателства. Боб ще сподели pk и vk с Алис.

Сега Алис ще играе ролята на доказател. Тя трябва да докаже, че знае стойността s, която хешира до известния хеш H. Тя изпълнява алгоритъма за доказване P, използвайки входовете pk, H и s, за да генерира доказателството prf:

prf = P (pk, H, s)

След това Алис представя доказателствения prf на Боб, който изпълнява функцията за проверка V (vk, H, prf), която в този случай ще се върне вярно, тъй като Алис правилно знае тайната s. Боб може да бъде уверен, че Алис е знаела тайната, но Алис не е трябвало да разкрива тайната на Боб.

Ключове за многократна проверка и проверка

В нашия пример по-горе, zk-SNARK не може да се използва, ако Боб иска да докаже на Алис, че знае тайна, тъй като Алис не може да знае, че Боб не е запазил ламбда параметъра. Вероятно Боб би могъл да фалшифицира доказателства.

Ако една програма е полезна за много хора (като примера на Zcash), доверена независима група, отделна от Алис и Боб, може да стартира генератора и да създаде доказателствен ключ pk и ключ за проверка vk по такъв начин, че никой да не научи за ламбда.

Всеки, който вярва, че групата не е изневерила, може да използва тези ключове за бъдещи взаимодействия.

zk-SNARKs в Ethereum

Разработчиците вече са започнали да интегрират zk-SNARKs в Ethereum. Как изглежда това? По-конкретно, можете да добавите градивните елементи на алгоритъма за проверка към Ethereum под формата на предварително съставени договори. Ето как: стартирайте генератора извън веригата, за да създадете доказателствен ключ и ключ за проверка. След това всеки проверяващ може да използва доказателствения ключ, за да създаде доказателство, също извън веригата. След това можете да стартирате общия алгоритъм за проверка в интелигентен договор, като използвате доказателството, ключа за проверка и публичния вход като входни параметри. След това можете да използвате резултата от алгоритъма за проверка, за да задействате други дейности по веригата.

Пример: Поверителни транзакции

Ето един прост пример за това как zk-SNARKs могат да помогнат за поверителността на Ethereum. Да предположим, че имаме прост символен договор. Обикновено символичният договор би имал в основата си картографиране от адреси към баланси:

картографиране (адрес => uint256) баланси; Език на кода: JavaScript (javascript)

Ще запазим същото основно ядро, с изключение на заместването на баланс с хеш на баланс:

картографиране (адрес => bytes32) balanceHashes; Език на кода: JavaScript (javascript)

Ние няма да скрием подателя или получателя на транзакциите. Но ние ще скрием салдата и изпратените суми. Това свойство понякога се нарича „ поверителни сделки.

Ще използваме два zk-SNARK, за да изпращаме токени от един акаунт в друг. Едно доказателство се създава от подателя и едно от получателя.

Обикновено в символен договор за транзакция със стойност на размера, за да бъде валидна, трябва да проверим следното:

салда [отАдрес] >= стойност

Нашите zk-SNARKs трябва да докажат, че това важи, както и че актуализираните хешове съответстват на актуализираните баланси.

Основната идея е, че подателят ще използва началното си салдо и стойността на транзакцията като частни входове. Като публични данни те използват хешове на начален баланс, краен баланс и стойност. По същия начин приемникът ще използва начален баланс и стойност като секретни входове. Като публични данни те използват хешове на начален баланс, краен баланс и стойност.

По-долу е програмата, която ще използваме за подателя zk-SNARK, където както преди x представлява публичния вход, а w представлява частния вход.

функция senderFunction (x, w) {return (w.senderBalanceBefore > w.стойност && sha256 (w.value) == x.hashValue && sha256 (w.senderBalanceBefore) == x.hashSenderBalanceBefore && sha256 (w.senderBalanceBefore – w.value) == x.hashSenderBalanceAfter)} Език на кода: JavaScript (javascript)

Програмата, използвана от приемника, е по-долу:

функция receiverFunction (x, w) {return (sha256 (w.value) == x.hashValue && sha256 (w.receiverBalanceBefore) == x.hashReceiverBalanceBefore && sha256 (w.receiverBalanceBefore + w.value) == x.hashReceiverBalanceAfter)} Език на кода: JavaScript (javascript)

Програмите проверяват дали изпращащото салдо е по-голямо от изпращаната стойност, както и дали всички хешове съвпадат. Доверен набор от хора ще генерира ключове за проверка и проверка за нашите zk-SNARKs. Нека ги наречем confTxSenderPk, confTxSenderVk, confTxReceiverPk и confTxReceiverVk.

Използването на zk-SNARKs в символен договор ще изглежда по следния начин:

прехвърляне на функция (адрес _to, bytes32 hashValue, bytes32 hashSenderBalanceAfter, bytes32 hashReceiverBalanceAfter, байтове zkProofSender, байтове 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; }} Език на кода: JavaScript (javascript)

По този начин единствените актуализации на блокчейна са хешовете на салдата, а не самите салда. Можем обаче да знаем, че всички баланси са правилно актуализирани, защото можем да се проверим дали доказателството е проверено.

Подробности

Горната схема за поверителни транзакции е главно да даде практически пример за това как човек може да използва zk-SNARKs на Ethereum. За да създадем стабилна схема за поверителни транзакции, ще трябва да разгледаме редица проблеми:

  • Потребителите ще трябва да следят баланса си от страна на клиента и ако загубите баланса, тези жетони са невъзстановими. Салдата може би биха могли да се съхраняват криптирани по веригата с ключ, получен от ключа за подписване.
  • Балансите трябва да използват 32 байта данни и да кодират ентропия, за да се предотврати възможността за обръщане на хешове, за да се разберат балансите.
  • Трябва да се справите с крайния случай на изпращане на неизползван адрес.
  • Подателят трябва да взаимодейства с получателя, за да изпрати. Потенциално може да има система, при която изпращачът използва доказателството си, за да инициира транзакцията. След това получателят може да види на блокчейна, че има „чакаща входяща транзакция“ и може да я финализира.

Абонирайте се за нашия бюлетин за най-новите новини за Ethereum, корпоративни решения, ресурси за разработчици и др. Имейл адрес Изключително съдържаниеКак да изградим успешен блокчейн продуктУебинар

Как да изградим успешен блокчейн продукт

Как да настроите и стартирате Ethereum NodeУебинар

Как да настроите и стартирате Ethereum Node

Как да създадете свой собствен API за EthereumУебинар

Как да създадете свой собствен API за Ethereum

Как да създадете социален токенУебинар

Как да създадете социален токен

Използване на инструменти за сигурност при разработването на интелигентен договорУебинар

Използване на инструменти за сигурност при разработването на интелигентен договор

Бъдещето на финансите Digital Assets и DeFiУебинар

Бъдещето на финансите: цифрови активи и 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