Как доказателствата zk-SNARK-овете подобряват системата за доказателство за резервите на Binance
Основни изводи
През ноември 2022 г. Binance пусна своята система за доказателство за резерви, използваща криптография на дърво на Merkle, за да позволи на потребителите да проверяват своите притежания.
Сега Binance подобри решението си чрез внедряване на zk-SNARK-ове
Потребителите вече могат да проверят дали общият нетен баланс на всеки акаунт е неотрицателен и че всички потребителски активи са част от заявения от Binance общ нетен баланс на потребителските активи – по поверителен и сигурен начин.
Погледнете под капака на новото решение за доказателство за резерви на Binance. Комбинирайки zk-SNARK-овете и информацията за дървото на Merkle, то дава на потребителите нов и подобрен начин за проверка на състоянието на резервите на Binance.
През последните няколко месеца екипът от разработчици на Binance работи усилено по изграждането на усъвършенствани решения за доказване на платежоспособност. Такива инструменти станаха критични за централизираните крипто борси на фона на кризата на доверието, която погълна индустрията след колапса на FTX. Средствата на потребителите, съхранявани в Binance, са обезпечени в съотношение 1:1, плюс резерви, и намирането на начин да се докаже това безпроблемно на обществеността се превърна в основна част от плана на Binance за възстановяване на доверието в индустрията.
През ноември 2022 г. пуснахме нашата система за доказателство за резерви, използваща криптографска техника на дърво на Merkle, за да позволим на потребителите да проверят своите притежания в Binance. Въпреки че е напредък в усилията на Binance за прозрачност на потребителските средства, първоначалният дизайн на това решение имаше два недостатъка:
За да се защити поверителността на потребителите, възлите в доказателството на Merkle представляват хеша на притежанията на потребителите – по този начин коренът на Merkle не може да отразява сумата от информацията за баланса на своите крайни възли.
Субектът, чиито резерви се проверяват, потенциално може да добави отрицателен баланс под фалшив акаунт някъде в дървото, за да направи общите задължителни резерви да изглеждат по-малки. Следващата диаграма от блога на Виталик Бутерин показва пример за такова злонамерено дърво на Merkle (въпреки че в този случай коренът отразява сумата от балансите на всички листови възли, което може да доведе до проблеми с поверителността).
Сега имаме решение, което може да коригира тези недостатъци и по този начин да подсили системата за доказателство за резерви на Binance. Разчитайки на протоколи за доказателство за нулеви знания и zk-SNARK-ове, можем да докажем, че:
Всички листови възли на дървото на Merkle са допринесли за обявения от Binance общ потребителски баланс за всеки актив.
Няма потребител с отрицателен общ нетен баланс (обща стойност в USD на всички активи, които потребителят притежава), включен в дървото на Merkle.
Няколко думи за отрицателните баланси и ефективността
Балансът на конкретен крипто актив на даден потребител може да бъде отрицателен, но общият му нетен баланс за всички крипто активи не трябва да бъде отрицателен (тъй като всички заеми са напълно обезпечени).
В този хипотетичен сценарий да кажем, че Алис е депозирала 10 000 BUSD в Binance, след което е използвала 4 000 BUSD като обезпечение, за да вземе назаем 2 BNB (при курс 1 BNB = 1 000 BUSD, като се приеме, че Binance винаги има свръхобезпечение). Следващата таблица показва баланса на Алис.
Ако Алис след това търгува 1 BNB за 1000 BUSD с Боб (който също е депозирал 10 000 BUSD), техният баланс ще изглежда така, след като сделката бъде съчетана:
В този случай балансът на Алис в BNB ще възлиза на -1, което не е валиден възел в дървото на Merkle и покрива само един актив: BNB. Въпреки това, ако разглеждаме общите нетни баланси, Алис все още е на 10 000 BUSD.
Друго предизвикателство идва от големия мащаб на потребителската база на Binance. Жизнеспособно решение трябва да генерира потребителско доказателство и доказателства zk-SNARK за десетки милиони потребители, някои от които може да притежават повече от 300 крипто актива на нашата платформа.
Като цяло искаме да предоставим доказателство за следните факти в разумен срок:
Активите на всеки потребител на Binance са част от нашия заявен общ потребителски баланс, показан в моментната снимка. Потребителите могат да проверят заявеното от нас общ потребителски баланс спрямо активите, държани на контролирани от Binance адреси, като използват блокчейн търсачка (като Etherscan за портфейли Ethereum или BscScan за портфейли BNB Chain).
Общият нетен баланс на всеки потребител е неотрицателен, което означава, че Binance не е създал фиктивни акаунти с отрицателен баланс, за да намали изкуствено размера на нашите проверими резерви.
Какво представляват zk-SNARK-овете?
Преди да се потопим в детайлите, трябва да направим кратък преглед на механизма за доказателство за нулеви знания. Протоколите за нулеви знания като zk-SNARK позволяват на една страна, доказващият, да демонстрира на друга страна, проверяващият, че доказващият е изпълнил определени изчисления точно с определени входове при определени ограничения, без да разкрива входовете. Изчислението може да отнеме много време, но основният математически механизъм може да помогне на проверяващия да оцени доказателството бързо и сигурно.
Доказващият (Binance) започва с дефиниране на набор от ограничения на изчислението, което иска да докаже. Ограниченията са дефинирани в схеми, които могат да бъдат изразени на език за програмиране от по-високо ниво (в нашия случай, разклонена версия на gnark.)
След това проверяващият изпълнява тежкото изчисление, хешира идентификационните номера и балансите на всички потребители и генерира доказателство, че изчислението отговаря на ограниченията, посочени по-рано. За да направи това, той използва следата на изчислението и публични или частни входове.
Проверяващият (потребителят) получава доказателството и го проверява с публичния вход на веригата, за да се увери, че изчислението е изпълнено точно с всички изпълнени ограничения. Изчислението за проверка отнема изключително кратко време в сравнение с времето за доказване. Ако проверяващият не генерира доказателството на предварително дефинираните вериги, той не може да създаде валидно доказателство за преминаване на проверката.
За да погледнете по-задълбочено под капака на zk-SNARK-овете, можете да се разгледате тази поредица от статии.
Нашето решение
Основният градивен елемент на надграденото решение за доказателство за резерви все още е дърво на Merkle. За горния пример ще изглежда така:
В допълнение към дървото на Merkle, ние поддържаме и глобално състояние, което представлява списък на общите нетни баланси на всеки актив, който всеки клиент на Binance притежава.
За да докажем нашите резерви, ще генерираме zk-SNARK доказателство за изграждането на дървото Merkle. За балансовия набор на всеки потребител – възел на дървото Merkle – нашата верига ще гарантира, че:
Балансът на всеки актив на този потребител е включен в глобалния списък със състояния, споменат по-горе.
Общият нетен баланс на потребителя не е отрицателен.
Промяната на корена на дървото Merkle е валидна след актуализиране на информацията на този потребител към хеша на листовия възел.
Моля, вижте тази техническа спецификация и нашия изходен код за веригата (ограничения) за подробности за изпълнението.
Във всеки случай на доказване на нашите резерви, ние ще публикуваме:
1. Доказателството на Merkle: хешовете за всеки потребител (за Алис, представени със сини възли на горното изображение).
2. zk-SNARK доказателства и публичен вход (хеш на списъка с общите нетни баланси на всеки актив и корена на Merkle) на веригата за всички потребители.
Чрез проверка на доказателството на Merkle потребителите могат да се уверят, че балансът им е включен в корена на дървото Merkle. Чрез проверка на zk-SNARK доказателството, потребителите могат да се уверят, че конструкцията на дървото Merkle отговаря на ограниченията, дефинирани във веригата.
Сигурността на това решение зависи до голяма степен от настройката на ключа за доказване и ключа за потвърждение. Работим върху децентрализирана настройка на ключовете. Що се отнася до съществуващите церемонии за децентрализирана надеждна настройка, церемонията на Ethereum предлага добър пример. Ние сме много близо до наличието на MPC решение, което да направи настройката без доверие.
Представяне
Предвид броя на потребителите на Binance, чиито баланси трябва да бъдат включени, няма начин да получите едно доказателство за конструкцията на дървото на Merkle, което да обхване всички потребители наведнъж. Решение за това е разделянето на потребителите на партиди от по 864, така че да има верига с по-малък мащаб и паралелни процедури за доказване.
За партида, която съдържа 864 потребители, където всеки потребител притежава 350 различни актива, да предположим, че балансът на всеки актив е в диапазона [0, 2^64-1]. С 32-ядрен 128 GB сървър времето за генериране на zk доказателство е около 110 секунди, а времето за проверка на доказателство е по-малко от 1 милисекунда.
Binance ще стартира 1000 проверяващи едновременно, така че да генерира доказателство за всички акаунти за 2 часа. Цената на този сървър за доказване за един час е около 0,56 USD, така че общата цена за генериране на всички zk доказателства, покриващи всички потребители, ще бъде около 1000 USD.
Заключение
Ние ще предоставим първата итерация на доказателство за потребители, генерирани от това ново решение, в последващо съобщение за доказателство за резерви. Освен това сме предоставили отворен достъп до нашия процесор за обработка на потребителски данни, доказателство, верига и верификатор, така че всяка централизирана борса, разчитаща на същия модел като нас, да може лесно да генерира доказателство за своите потребители и активи.
Надяваме се, че това ще помогне за издигането на ново ниво на прозрачността на индустрията на цифровите активи. Ние също така работим върху прилагането на решението, споменато в блога на Виталик, за да постигнем по-добра производителност, което ще ни позволи да предоставяме доказателството по-често на по-ниска цена.
Тъй като това е първата версия на нашия zk-SNARK, очакваме с нетърпение да получим обратна връзка от общността, за да можем да продължим да подобряваме системата.