Резюме
Доказателството с нулево знание позволява на една страна (верификатор) да определи валидността на твърдение, дадено от друга страна (доказващ) без никакво знание за съдържанието на изявлението. Например, Binance може да иска да докаже, че е подкрепил средствата на своите потребители изцяло в резерви, без да разкрива всички индивидуални потребителски баланси.
„Доказателство за резерви“ може да бъде конструирано с дърво на Merkle, което предпазва от фалшифициране на неговите вътрешни данни, в този случай общите му нетни клиентски баланси, които са задължения на борсата към нейните потребители. После това може да се комбинира с zk-SNARK (протокол за доказателство с нулево знание), който гарантира, че потребителите могат да проверяват своя баланс, който представлява част от общия баланс на нетните потребителски активи, без да знаят индивидуалните баланси.
Въведение
В светлината на събитията на пазара, сигурността на крипто активите под попечителство се превърна в критична тема. Потребителите на блокчейн високо ценят прозрачността и откритостта, но също така поддържат поверителността. Това създава дилема при доказване на резерви на средства, държани от попечители. Често има компромис между прозрачност, доверие и поверителност на данните.
Това обаче не трябва да е така. Чрез комбиниране на протоколи с доказателство с нулево знание като zk-SNARK-овете с дървета на Merkle, можем да намерим ефективно решение за всички страни.
Какво е доказателство с нулево знание?
Доказателството с нулево знание позволява на една страна (верификатор) да определи валидността на твърдение, дадено от друга страна (доказващ) без никакво знание за съдържанието на изявлението. Нека да разгледаме един прост пример.
Имате заключен сейф, чиято комбинация знаете само вие. Да предположим, че сейфът не може да бъде отключен с шперц, отворен насила или по какъвто и да е друг начин, освен чрез познаване на комбинацията. Този факт също е установен, проверен и известен от вашия приятел, участващ в експеримента.
Заявявате на вашия приятел, че знаете комбинацията, но не искате да я дадете или да отворите кутията пред него. В горната част на кутията има дупка, през която вашият приятел може да постави бележка. За да направите това доказателство с нулево знание, вашият приятел не трябва да има никаква допълнителна информация за процеса, освен даденото твърдение.
Можете да докажете на приятеля си, че знаете комбинацията, като отворите кутията, кажете му какво е написано на бележката и я затворите отново. В нито един момент обаче не разкривате комбинацията.
За по-съвършен пример вижте нашата статия Какво е доказателство с нулево знание и как то влияе на блокчейн?
Защо да използваме доказателство с нулево знание?
Доказателствата с нулево знание са подходящи за доказване на нещо, без да се разкрива чувствителна информация или подробности. Това може да се случи, когато не искате да предадете вашата финансова или лична информация, която би могла да бъде използвана неподходящо.
В крипто пространството можете да докажете, че притежавате частен ключ, без да го разкривате или да подписвате цифрово нещо. Борсата за криптовалути може също да иска да докаже състоянието на своите резерви, без да разкрива поверителна информация за своите потребители, включително баланси по техните индивидуални акаунти.
За тези примери (и много други), доказателството с нулево знание би използвало алгоритми, които приемат входни данни и връщат „вярно“ или „грешно“ като изход.
Дефиниране на доказателства с нулево знание в технически термини
Доказателството с нулево знание, от техническа гледна точка, следва специфична структура с определени критерии. Вече разгледахме ролите на доказващия и верификатора, но има и три критерия, които доказателството с нулево знание трябва да покрива:
Пълнота. Ако твърдението е вярно, верификаторът ще бъде убеден от предоставеното доказателство, без да е необходима друга информация или проверка.
Добро състояние. Ако твърдението е невярно, верификаторът няма да бъде убеден в истинността на твърдението чрез предоставеното доказателство.
Нулево знание. Ако твърдението е вярно, верификаторът не научава друга информация, освен че твърдението е вярно.
Какво е zk-SNARK?
zk-SNARK (кратък неинтерактивен аргумент на знанието с нулево знание) е доказателствен протокол, който следва принципите на нулево знание, посочени по-рано. С zk-SNARK можете да докажете, че знаете оригиналната хеширана стойност (обсъдена по-долу), без да разкривате същността. Можете също така да докажете валидността на трансакция, без да разкривате каквато и да е информация за конкретните суми, стойности или адреси.
zk-SNARK се използват често и се обсъждат в света на блокчейна и криптовалутите. Но може да се чудите защо някой би си правил труда да използва zk-SNARK, когато може да използва прост метод на двойка от публичен и частен ключ за защита на информацията. Ние обаче не бихме могли да приложим математическото доказателство, за да гарантираме, че не са включени отрицателни баланси и сумата на дървото на Merkle.
В случай на борсови резерви, ние искаме да докажем обезпечаване 1:1 на балансите на клиентите, без идентификаторите и балансите на всяка сметка да бъдат оповестени публично. Освен това технологията zk-SNARK прави фалшифицирането на данни още по-малко вероятно.
Какво е дърво на Merkle?
Представянето на сумираните средства на акаунтите на потребителите на Binance изисква работа с голям набор от данни. Един от начините да се представи това голямо количество данни криптографски е да се използва дърво на Merkle. Огромно количество информация може да бъде ефективно съхранено в него, а неговият криптографски характер прави целостта му лесно проверима.
Хеш функции
За да кодира накратко вход, дървото на Merkle зависи от използването на хеш функции. Накратко, хеширането е процес на генериране на изход с фиксиран размер от вход с променлив размер. С други думи, когато вход с произволна дължина се хешира чрез алгоритъм, той ще произведе криптиран изход с фиксирана дължина.
Докато входът остава същият, изходът също ще бъде същият. Това означава, че можем да вземем огромни количества трансакционни данни и да ги хешираме в управляем изход. Изходът ще бъде коренно различен, ако във входа се промени някаква информация.
Например, можем да вземем съдържанието на 100 книги и да ги въведем в хеш функцията SHA-256. След това ще предостави нещо подобно като изход:
801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea
Ако след това променим един знак на входа (тези 100 книги), хешът ще бъде напълно различен, ето така:
abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410
Това е важно свойство на хеш функциите, защото позволява лесна проверка на точността на данните. Ако някой повтори процеса на хеширане на същите тези 100 книги с помощта на алгоритъма SHA-256, той ще получи точно същия хеш като изхода. Ако изходът е различен, можем да потвърдим със сигурност, че входът е променен. Това означава, че няма нужда от индивидуална или ръчна проверка за разлики между входовете, което може да бъде трудоемко.
Дървета на Merkle в света на криптовалутите
Когато се съхраняват данни за трансакции в блокчейн, всяка нова трансакция се изпраща чрез хеш функция, която генерира уникални хеш стойности. Представете си, че имаме осем трансакции (A до H), които индивидуално хешираме, за да получим техните хеширани резултати. Това е, което наричаме възли от лист на Merkle. На изображението по-долу можете да видите уникалната хеш стойност на всяка буква: hA за A, hB за B, hC за C и т.н.
След това можем да вземем двойки хеширани изходи, да ги комбинираме и да получим нов хеширан изход. Хешовете на hA и hB, хеширани заедно, например, ще ни дадат нов хеширан изход на hAB, известен като клон на Merkle. Имайте предвид, че всеки път, когато се генерира нов изход, той идва с фиксирана дължина и размер, според използваната хеш функция.
Сега имаме данните от две трансакции (напр. A и B), комбинирани в един хеш (hAB). Имайте предвид, че ако променим информация от A или B и повторим процеса, нашият хеширан изход hAB ще бъде напълно различен.
Процесът продължава, докато комбинираме нови двойки хешове, за да ги хешираме отново (вижте изображението по-долу). Ние хешираме hAB с hCD, за да получим уникален хеш hABCD и правим същото с hEF и hGH, за да получим hEFGH. В крайна сметка получаваме единичен хеш, представляващ хешираните резултати от хешовете на всички предишни трансакции. С други думи, хешираният изход hABCDEFGH представлява цялата информация, която е била преди него.
Графиката, показана по-горе, се нарича дърво на Merkle, а хешираният изход hABCDEFGH е коренът на Merkle. Използваме корени на Merkle в заглавки на блокове, тъй като те криптографски обобщават всички данни за трансакциите в блок по кратък начин. Можем също така бързо да проверим дали някакви данни са били подправени или променени в блока.
Ограниченията на дърветата на Merkle
Нека се върнем към нашия пример за резервите на CEX. CEX иска да докаже, че активите на всички негови клиенти са обезпечени в съотношение 1:1 и изгражда дърво на Merkle, което хешира UID на своите клиенти с техните нетни активи (нетиране на активите и пасивите) на ниво токени. Веднъж пуснат (и подписан, за да докаже собствеността върху предоставения корен на Merkle), отделен потребител няма да има начин да провери дали дървото на Merkle е валидно, без да получи достъп до всичките му входове.
Възможно е борсата да е пропуснала да включи някои входни данни. Може също да създаде фалшиви акаунти с отрицателни баланси, за да промени общото задължение. Например, въпреки че активите на клиентите може да възлизат на 1 000 000 $, може да се добави фалшив акаунт с баланс от -500 000 $. Това би създало цел за резерви от само $500 000.
Случаят за доказателство за резерви е различен от корена на Merkle на даден блок, тъй като потребителите могат да видят всички трансакции, които блокът съдържа в блокчейн изследовател. CEX обаче няма да иска да разкрива всеки баланс по акаунт от съображения за сигурност и поверителност на данните. Клиентите също не биха били доволни от оповестяването на балансите по сметките им. В този случай CEX не може да докаже, че потребителските баланси се равняват на правилната сума, без да прави видими други потребителски баланси.
Едно решение, което борсите може да обмислят да използват, е използването на доверен одитор от трета страна. Одиторът може да провери индивидуалните сметки и резерви, преди окончателно да удостовери валидността на предоставения корен на Merkle. За потребителите обаче този метод изисква доверие в одитора и данните, използвани за одита. Не е нужно да разчитате на трета страна, когато можете да се доверите на данните.
Комбиниране на zk-SNARK с дървета Merkle
Горният проблем е идеален случай за използване на zk-SNARK-овете. Искаме да докажем, че резервите покриват изцяло задълженията на потребителите и не са фалшифицирани. От съображения за поверителност и сигурност обаче не искаме да показваме на верификатора точния състав на потребителските баланси и резерви.
Чрез използване на zk-SNARK, крипто борсата може да докаже, че всички набори от баланси на листовите възли на дървото на Merkle (т.е. баланси на потребителски акаунти) допринасят за заявения общ баланс на активите на борсата. Всеки потребител може лесно да получи достъп до своя листов възел, тъй като е бил включен в процеса. Zk-SNARK също така гарантира, че генерираното дърво на Merkle не съдържа потребители с отрицателен общ баланс на нетните активи (което би означавало фалшифициране на данни, тъй като всички заеми са свръхобезпечени). Също така се използва изчисление на глобалното състояние на Binance, т.е. списък на общия нетен баланс на всеки актив, който притежава всеки клиент на Binance.
Нека да разгледаме как Binance подхожда към ситуацията. Като начало Binance определя ограниченията на изчислението, което иска да докаже, и ги определя като програмируема схема. По-долу е наборът от три ограничения, които Binance използва в своя модел.
За набор от баланси на всеки потребител (листов възел на Merkle), нашата схема гарантира, че:
Балансите на активите на даден потребител са включени в изчисляването на сумата от общите нетни баланси на потребителите с Binance.
Общият нетен баланс на потребителя е по-голям или равен на нула.
Промяната на корена на дървото на Merkle е валидна (т.е. без използване на фалшифицирана информация) след актуализиране на информацията на потребителя към хеша на листовия възел.
След това Binance може да генерира zk-SNARK доказателство за конструкцията на дървото на Merkle според веригата. Това налага борсата да извърши тежкото изчисление на хеширане на идентификатори и баланси на потребители, като същевременно гарантира, че доказателството преминава ограниченията.
Верификаторът ще проучи доказателството (и неговия публично публикуван отворен код), за да се убеди, че изчислението се изпълнява при спазване на всички ограничения. Изчислението за проверка отнема изключително кратко време в сравнение с времето за доказване.
При всяко пускане на доказателство за резерви борсата ще публикува:
1. Доказателството на Merkle за всеки потребител.
2. Zk-SNARK доказателство и публичен вход (хеш на списъка на общия нетен баланс на всеки актив и корен на Merkle) на веригата за всички потребители.
Заинтересованите страни могат да проверят доказателството на Merkle, като гарантират, че техните индивидуални баланси са допринесли за корена на дървото на Merkle. Те могат също да проверят доказателството zk-SNARK, за да гарантират, че конструкцията на дървото на Merkle отговаря на ограниченията, дефинирани във веригата. За по-подробно обяснение на решението zk-SNARK и неговата производителност вижте нашия блог Как zk-SNARK-овете подобряват системата за доказателство за резерви на Binance.
Заключителни мисли
zk-SNARK-овете предоставят технологията, необходима за осигуряване едновременно на целостта и поверителността на данните. Неговото приложение за доказване на резерви и увеличаване на прозрачността на CEX трябва да помогне за изграждането на доверие в блокчейн индустрията. За мнозина развитие като това е дългоочаквано и идва в ключов момент за CEX.
Това е първата версия на нашия zk-SNARK и очакваме с нетърпение да получим обратна връзка от общността, за да можем да продължим да подобряваме системата.