TL; DR
Доказ із нульовим знанням дозволяє одній стороні (верифікатору) визначити дійсність твердження, наданого іншою стороною (доказником), не знаючи змісту твердження. Наприклад, Binance може захотіти довести, що вона повністю забезпечила кошти своїх користувачів у резервах, не розкриваючи баланси всіх окремих користувачів.
«Доказ резервів» можна створити за допомогою дерева Merkle, яке захищає від фальсифікації внутрішніх даних, у даному випадку, загальних чистих балансів клієнтів, які є зобов’язаннями біржі перед її користувачами. Потім це можна поєднати з zk-SNARK (протокол з нульовим знанням), який гарантує, що користувачі можуть перевірити, чи їхній баланс є частиною загального балансу чистих активів користувача, не знаючи індивідуальних балансів.
вступ
У світлі ринкових подій безпека криптоактивів на зберіганні стала критичною темою. Користувачі блокчейну високо цінують прозорість і відкритість, але також підтримують приватність і конфіденційність. Це створює дилему під час підтвердження запасів коштів, які зберігаються зберігачами. Часто існує компроміс між прозорістю, довірою та конфіденційністю даних.
Однак це не обов’язково має бути так. Поєднуючи протоколи з нульовим розпізнаванням, як-от zk-SNARK, із деревами Merkle, ми можемо знайти ефективне рішення для всіх сторін.
Що таке доказ нульового знання?
Доказ із нульовим знанням дозволяє одній стороні (верифікатору) визначити дійсність твердження, наданого іншою стороною (доказником), не знаючи змісту твердження. Давайте розглянемо простий приклад.
У вас є замкнений сейф, розгадку якого знаєте лише ви. Сейф, для прикладу, не можна підняти, змусити або відкрити будь-яким іншим способом, окрім знання комбінації. Цей факт також встановлений, перевірений і відомий вашому другу, який бере участь в експерименті.
Ви заявляєте, що знаєте комбінацію своєму другові, але не хочете віддавати її чи відкривати коробку перед ними. У верхній частині коробки є отвір, куди ваш друг може покласти записку. Щоб зробити це доказом нульового знання, ваш друг не повинен мати жодної додаткової інформації про процес, крім наданого твердження.
Ви можете довести своєму другові, що знаєте комбінацію, відкривши коробку, сказавши їм, що написано на записці, і знову закрийте її. Однак ви жодного разу не розкрили цю комбінацію.
Щоб отримати докладніший приклад, перегляньте наш розділ «Що таке підтвердження нульового знання та як воно впливає на блокчейн?» стаття.
Чому ми використовуємо підтвердження нульового знання?
Докази з нульовим знанням підходять для доведення чогось без розкриття конфіденційної інформації чи деталей. Це може статися, якщо ви не хочете передавати свою фінансову чи особисту інформацію, яка може бути використана неналежним чином.
У крипто ви можете довести, що володієте закритим ключем, не розкриваючи його та не підписуючи щось цифровим. Криптовалютна біржа також може захотіти підтвердити статус своїх резервів, не розкриваючи конфіденційну інформацію про своїх користувачів, у тому числі баланси їхніх індивідуальних рахунків.
Для цих прикладів (та багатьох інших) підтвердження з нульовим знанням використовуватиме алгоритми, які приймають вхідні дані та повертають «true» або «false» як вихід.
Визначення доказів із нульовим знанням у технічній термінології
Підтвердження з нульовим знанням, з технічної точки зору, має певну структуру з певними критеріями. Ми вже розглянули ролі перевірника та верифікатора, але є також три критерії, які має відповідати доказ нульового знання:
Повнота. Якщо твердження правдиве, верифікатор буде переконаний наданим доказом, без потреби в будь-якій іншій інформації чи перевірці.
Обґрунтованість. Якщо твердження є хибним, верифікатор не переконається в істинності твердження наданим доказом.
Нульові знання. Якщо твердження правдиве, верифікатор не дізнається жодної іншої інформації, крім того, що твердження є істинним.
Що таке zk-SNARK?
Zk-SNARK (Короткий неінтерактивний аргумент знань із нульовим знанням) — це протокол підтвердження, який дотримується принципів нульового знання, викладених раніше. За допомогою zk-SNARK ви можете довести, що знаєте оригінальне хешоване значення (обговорюється далі нижче), не розкриваючи, що це таке. Ви також можете підтвердити дійсність транзакції, не розкриваючи жодної інформації про конкретні суми, вартості чи адреси.
zk-SNARK зазвичай використовуються та обговорюються в світі блокчейнів і криптовалют. Але ви можете задатися питанням, навіщо комусь використовувати zk-SNARK, коли вони можуть використовувати простий метод пари відкритих і закритих ключів для захисту інформації. Однак ми не зможемо застосувати математичне підтвердження, щоб гарантувати відсутність від’ємних сальдо та суми дерева Меркла.
У випадку резервів біржі ми хочемо довести 1:1 забезпечення балансів клієнтів без оприлюднення ідентифікаторів і балансів кожного рахунку. Крім того, технологія zk-SNARK робить фальсифікацію даних ще менш ймовірною.
Що таке дерево Меркле?
Відображення сумарних коштів облікових записів користувачів Binance вимагає роботи з великим набором даних. Одним із способів представити цей великий обсяг даних криптографічно є використання дерева Меркла. У ньому можна ефективно зберігати величезну кількість інформації, а його криптографічний характер дозволяє легко перевірити його цілісність.
Хеш-функції
Для стислого кодування вхідних даних дерево Merkle залежить від використання хеш-функцій. Коротше кажучи, хешування - це процес генерації вихідних даних фіксованого розміру з вхідних даних змінного розміру. Іншими словами, коли вхідні дані будь-якої довжини хешуються за допомогою алгоритму, він створить зашифрований вихід фіксованої довжини.
Поки вхід залишається незмінним, вихід також буде. Це означає, що ми можемо взяти величезні обсяги транзакційних даних і хешувати їх у керований вихід. Вихід буде кардинально іншим, якщо будь-яка інформація буде змінена на вході.
Наприклад, ми можемо взяти вміст 100 книг і ввести його в хеш-функцію SHA-256. Тоді це забезпечить щось на зразок цього як результат:
801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea
Якщо ми потім змінимо один символ вхідних даних (ці 100 книг), хеш буде зовсім іншим, ось так:
abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410
Це важлива властивість хеш-функцій, оскільки вона дозволяє легко перевіряти точність даних. Якщо хтось повторить процес хешування тих самих 100 книг за допомогою алгоритму SHA-256, він отримає той самий хеш, що й вихід. Якщо вихідні дані відрізняються, ми можемо з упевненістю стверджувати, що вхідні дані були змінені. Це означає, що немає необхідності окремо або вручну перевіряти відмінності між вхідними даними, що може бути трудомістким.
Дерева Merkle у світі криптовалют
Під час зберігання даних транзакцій у блокчейні кожна нова транзакція надсилається через хеш-функцію, яка генерує унікальні хеш-значення. Уявіть, що у нас є вісім транзакцій (від A до H), які ми окремо хешуємо, щоб отримати їхні хешовані результати. Це те, що ми називаємо листовими вузлами Меркла. На зображенні нижче ви можете побачити унікальне хеш-значення кожної літери: hA для A, hB для B, hC для C тощо.
Потім ми можемо взяти пари хешованих виходів, об’єднати їх і отримати новий хешований вихід. Хеші hA і hB, хешовані разом, наприклад, дадуть нам новий хешований вихід hAB, відомий як гілка Меркла. Зауважте, що кожного разу, коли створюється новий вихід, він має фіксовану довжину та розмір відповідно до використовуваної хеш-функції.
Тепер у нас є дані двох транзакцій (наприклад, A і B), об’єднані в один хеш (hAB). Зауважте, що якщо ми змінимо будь-яку інформацію з A або B і повторимо процес, наш хешований вихід hAB буде зовсім іншим.
Процес продовжується, коли ми об’єднуємо нові пари хешів, щоб знову їх хешувати (див. зображення нижче). Ми хешуємо hAB з hCD, щоб отримати унікальний хеш hABCD, і робимо те саме з hEF і hGH, щоб отримати hEFGH. Зрештою, ми отримуємо єдиний хеш, що представляє хешовані результати всіх хешів попередніх транзакцій. Іншими словами, хешований вихід hABCDEFGH представляє всю інформацію, яка надходила до нього.
Графік, показаний вище, називається деревом Меркла, а хешований результат hABCDEFGH є коренем Меркла. Ми використовуємо корені Merkle у заголовках блоків, оскільки вони криптографічно підсумовують усі дані транзакцій у блоці в стислій формі. Ми також можемо швидко перевірити, чи були будь-які дані підроблені або змінені в блоці.
Обмеження дерев Меркле
Повернемося до нашого прикладу резервів CEX. CEX хоче довести підтримку 1:1 для всіх активів своїх клієнтів і будує дерево Merkle, яке хешує UID своїх клієнтів з їхніми чистими активами (залік активів і зобов’язань) на рівні символів. Після випуску (і підписання, щоб підтвердити право власності на наданий кореневий каталог Merkle), окремий користувач не матиме можливості перевірити, чи дійсне дерево Merkle, не отримавши доступу до всіх його вхідних даних.
Можливо, пропущений обмін, включаючи деякі вхідні дані. Це також може створювати підроблені облікові записи з негативним балансом, щоб змінити загальну відповідальність. Наприклад, хоча активи клієнтів можуть становити 1 000 000 доларів США, фальшивий рахунок може бути доданий із балансом у -500 000 доларів США. Це створило б цільові резерви лише в 500 000 доларів США.
Випадок для підтвердження резервів відрізняється від кореня Merkle блоку, оскільки користувачі можуть бачити всі транзакції, які містить блок, у провіднику блокчейнів. Однак CEX не захоче розкривати баланс кожного рахунку з міркувань безпеки та конфіденційності даних. Клієнти також не будуть задоволені, якщо їхні баланси на рахунках будуть оприлюднені. У цьому випадку CEX не може довести, що баланси користувачів дорівнюють правильній сумі, не показуючи баланси інших користувачів.
Одним із рішень, яке біржі можуть розглянути, є використання довіреного стороннього аудитора. Аудитор може перевірити індивідуальні рахунки та резерви, перш ніж остаточно засвідчити дійсність наданого кореня Меркла. Однак для користувачів цей метод вимагає довіри до аудитора та даних, які використовуються для аудиту. Вам не потрібно покладатися на третю сторону, якщо ви можете довіряти даним.
Поєднання zk-SNARK з деревами Меркла
Наведена вище проблема є ідеальним випадком для використання zk-SNARK. Ми хочемо довести, що резерви повністю покривають зобов’язання користувачів і не є фальсифікованими. Проте з міркувань конфіденційності та безпеки ми не хочемо показувати верифікатору точний склад балансів і резервів користувачів.
Використовуючи zk-SNARK, криптобіржа може довести, що всі набори балансів листових вузлів дерева Merkle (тобто баланси облікових записів користувачів) роблять внесок у заявлений біржею загальний баланс активів користувачів. Кожен користувач може легко отримати доступ до свого кінцевого вузла, оскільки він був включений у процес. Zk-SNARK також гарантує, що будь-яке згенероване дерево Merkle не містить користувачів із від’ємним загальним балансом чистих активів (що означатиме фальсифікацію даних, оскільки всі кредити забезпечені надмірною заставою). Також використовується розрахунок глобального стану Binance, тобто список загального чистого балансу кожного активу, яким володіє кожен клієнт Binance.
Давайте подивимося, як Binance підходить до ситуації. Для початку Binance визначає обмеження обчислень, які він хоче підтвердити, і визначає їх як програмовану схему. Нижче наведено набір із трьох обмежень, які Binance використовує у своїй моделі.
Для кожного набору балансу користувача (вузол дерева Меркла) наша схема гарантує, що:
Баланс активів користувача включається в розрахунок суми загальних чистих балансів користувачів у Binance.
Загальний чистий баланс користувача більше або дорівнює нулю.
Зміна кореня дерева Merkle є дійсною (тобто не використовує фальсифіковану інформацію) після оновлення інформації про користувача в хеші листового вузла.
Потім Binance може створити доказ zk-SNARK для конструкції дерева Меркла відповідно до схеми. Це означає, що біржа виконує важкі обчислення хешування ідентифікаторів і балансів користувачів, одночасно гарантуючи, що доказ дотримується обмежень.
Верифікатор перевірить підтвердження (і його відкрито оприлюднений код), щоб переконатися, що обчислення виконано з дотриманням усіх обмежень. Обчислення верифікації займає надзвичайно короткий час порівняно з часом перевірки.
Під час кожного випуску доказів запасів біржа публікуватиме:
1. Доказ Merkle для кожного користувача.
2. Доказ zk-SNARK і публічний вхід (хеш списку загального чистого балансу кожного активу та кореня Merkle) схеми для всіх користувачів.
Зацікавлені сторони можуть перевірити доказ Merkle, переконавшись, що їхні індивідуальні баланси внесені до кореня дерева Merkle. Вони також можуть перевірити доказ zk-SNARK, щоб переконатися, що конструкція дерева Меркла відповідає обмеженням, визначеним у схемі. Для більш детального пояснення рішення zk-SNARK і його продуктивності зверніться до нашого блогу «Як zk-SNARKs покращують систему підтвердження резервів Binance».
Заключні думки
zk-SNARK забезпечують технологію, необхідну для забезпечення як цілісності даних, так і конфіденційності одночасно. Його застосування для підтвердження запасів і підвищення прозорості CEX повинно допомогти зміцнити довіру в індустрії блокчейнів. Для багатьох такий розвиток подій був довгоочікуваним і стався у вирішальний час для CEX.
Це перша версія нашого zk-SNARK, і ми з нетерпінням чекаємо на відгуки спільноти, щоб ми могли продовжувати вдосконалювати систему.
Подальше читання
(Блог) Як zk-SNARK покращують систему підтвердження резервів Binance
(Академія) Підтвердження резервів (PoR)
(Академія) Що таке підтвердження резервів і як воно працює на Binance
(Оголошення)Binance випускає систему підтвердження резервів
