Як працює zkPass? 3P-TLS + змішане ZK створює нульові знання Оракул-машину

! [як працює zkPass](https://img-cdn.gateio.im/webp-social/moments-87a9b3933a-bedc28aa99-153d09-69ad2a.webp019283746574839201

zkPass є протоколом оракула, що дозволяє перевіряти приватні дані інтернету на блокчейні. zkPass побудовано на базі zkTLS, що складається з 3P-TLS та змішаної ZK технології, і надає інструменти та додатки для безпечного, перевірного обміну даними, гарантуючи конфіденційність та цілісність даних з будь-якого HTTPS сайту без необхідності використання OAuth API.

) як працює zkPass? Загальна структура та основні концепції

! [загальна структура zkPass]###https://img-cdn.gateio.im/webp-social/moments-87a9b3933a-ca83c82af4-153d09-69ad2a.webp019283746574839201

Як працює zkPass? Щоб зрозуміти його структуру, потрібно спочатку ознайомитися з трьома основними ролями: P (доказувач/особа), V (перевіряючий/бізнес/вузол zkPass), S (TLS-сервер/джерело даних). У традиційному процесі перевірки даних доказувач подає інформацію перевіряючому, який витягує ці дані і співпрацює з DataSource для виконання перевірки. У цій моделі існує три основні проблеми: доказувач стикається з ризиком розкриття занадто великої кількості особистої інформації; хоча джерело даних є надійним, воно не може надати персоналізовану перевірку; перевіряючий володіє всіма приватними даними клієнтів, що створює величезний потенційний ризик витоку даних.

zkPass запропонував революційне рішення, яке розташовує доказувача між валідатором та джерелом даних. На відміну від традиційних методів, доказувачі використовують свої токени доступу для прямого локалізації та отримання даних із джерела даних, після чого генерують нульові докази знань (ZKP) для перевірки валідатором. Цей процес забезпечує те, що валідатор все ще не знає особисту інформацію доказувача. Ця архітектура інтегрує 3P-TLS, MPC (багатосторонні обчислення) та змішану ZK (нульове знання) технології.

Ключові технологічні компоненти：

3P-TLS: тривимірна безпека передачі, основана на еліптичній кривій DH-протоколі, комбінуючи MPC та Oblivious Transfer (OT) для запобігання шахрайству

Змішаний ZK: поєднання інтерактивного ZK (VOLE-ZK 23) та неінтерактивного ZK (SNARK/Circom) з двошаровою системою доказів

zkSBT: токени, пов'язані з душею, на основі стандарту комбінованих NFT ERC998, що зберігають основні декларації та декларації запиту.

( 3P-TLS та MPC: технічний прорив трьохстороннього рукостискання

! [zkPass 3P-TLS та MPC])https://img-cdn.gateio.im/webp-social/moments-87a9b3933a-ebb0a53efc-153d09-69ad2a.webp###

Перший ключ до роботи zkPass полягає в протоколі 3P-TLS. Протокол безпеки передачі (TLS) є безпечним комунікаційним протоколом HTTPS, який підтримується майже всіма джерелами даних. zkPass побудував протокол 3P-TLS на основі протоколу DH з еліптичними кривими та об'єднав його з MPC та Oblivious Transfer для реалізації безпечного тристороннього зв'язку.

Перший етап: трьохстороннє рукостискання P, V та S спільно генерують сеансовий ключ, P та V отримують частини цих ключів. Це реалізується за допомогою алгоритму шифрування Paillier, який забезпечує адитивну гомоморфність. Передній ключ ділиться на дві частини, P та V отримують по половині, а S зберігає повний передній ключ. Щоб запобігти підробці клієнтом фальшивих веб-сайтів, клієнт вимагатиме від сервера повернення сертифікату, щоб забезпечити довіру до джерела даних.

Другий етап: обмін ключами та проведення обчислень MPC між P і V для шифрування ключа (enc_key) та ключа для перевірки повідомлень (mac_key). Ключовий дизайн полягає в тому, що V має лише частину mac_key і не має enc_key, що гарантує, що V не може отримати доступ до приватної інформації користувача. Натомість P має частину mac_key, може отримати доступ до певної ідентифікаційної інформації, але не може її змінювати; будь-які зміни можуть бути виявлені за допомогою mac_key для перевірки справжності повідомлення.

Третя стадія: Підготовка стандартного TLS та ZKP Застосункові дані дотримуються стандартних процедур зв'язку TLS, P та V обмінюються ключами, готуючись до наступної стадії, що включає нульові знання. Алгоритм MPC zkPass зазнав значної оптимізації щодо часу зв'язку, хеш-функцій та операцій пам'яті, ефективність зросла більше ніж у три рази. Використання нового методу доказу AES128 зменшило кількість блоків у 300 разів, час виконання Garbler/Evaluator зріс у десять разів. Конкретно, zkPass використовує Silent OT для виконання OT операцій, використовуючи стековий GC для зменшення розміру заплутаного кола, що значно скорочує час виконання всього процесу MPC.

( Змішане ZK: ідеальне поєднання інтерактивного та неінтерактивного

! [zkPass mixed ZK])https://img-cdn.gateio.im/webp-social/moments-87a9b3933a-7fbe46bdb9-153d09-69ad2a.webp019283746574839201

Другим ключовим моментом у роботі zkPass є змішаний метод нульових знань. Останній етап протоколу zkPass передбачає генерацію клієнтом нульового доказу, який перевіряється смарт-контрактом на блокчейні. Цей змішаний підхід об'єднує переваги інтерактивних та неінтерактивних ZK протоколів.

Інтерактивний нульовий доказ (IZK): VOLE-ZK 23 zkPass використовує інтерактивний ZK протокол на основі VOLE для аутентифікації, забезпечуючи, що дані походять з точного джерела та захищають їх від змін з боку клієнта. Протокол VOLE-ZK 23 є рамкою «подання та доведення», де доводчик (P) та перевіряючий (V) спільно генерують велику кількість VOLE екземплярів, кожен з яких задовольняє лінійній формулі «m = k + w * delta». P подає деякі елементи цієї формули як зобов'язання, а V містить решту компонентів.

Ця лінійність є ключовою причиною, чому рішення є економічно вигідним, на відміну від інших високих поліноміальних рішень, таких як SNARK. P потрібно лише передати два елементи стовпців перевіряльнику, а потім V використовує свої параметри VOLE для перевірки дійсності. На цьому етапі є п'ять основних обмежень, що гарантують, що запит використовує зашифровані ключі, запит повинен бути згенерований за допомогою токена доступу користувача, користувач повинен мати зашифрований ключ для розшифрування відповіді, користувач не може змінити відповідь, а дані відповіді повинні відповідати конкретним умовам, викладеним у шаблоні.

Технологія оптимізації zkPass пройшла кілька вдосконалень для підвищення практичності протоколу. Введення SoftSpoken знижує приблизно на 50% мережеві витрати та прискорює генерацію VOLE. Використовуючи гомоморфні властивості додавання VOLE, зобов'язання для воріт XOR та INV зменшуються до нуля. Для конкретних випадків використання, що передбачають однакові операції, параметри VOLE можуть бути повторно використані, перетворюючи множення на додавання, що називається «вхід сигналу з більшості даних», подібно до архітектури CPU SIMD.

Неінтерактивні нульові знання (NIZK) переходять від IZK доказів до NIZK доказів з метою приховати фактичний шаблон, дозволяючи користувачам вибірково розкривати докази для відкритої перевірки будь-якою стороною. Використовується рамка SNARK, зокрема Circom. Коли клієнт успішно проходить перевірку IZK, вузол надає підпис для результату, клієнт вставляє результат та його відповідний підпис у дерево Меркла та оновлює корінь у контракті SBT. Коли клієнт потребує доведення результату, він просто надає нульове знання доказ, що доводить, що результат є листком у дереві Меркла та вже підписаний вузлом.

zkSBT: комбінована система зв'язаних душевних токенів

! Архітектура zkSBT від zkPass

Третій ключовий аспект роботи zkPass полягає в архітектурі zkSBT. zkPass дотримується стандарту ERC998, комбінованого стандарту NFT. tSBT представляє категорії правового статусу, соціальних мереж і фінансової інформації, а dSBT містить фактичні свідоцтва, заявлені користувачем. Ці декларації мають два типи: основні декларації та запитувані декларації.

Основні вимоги стосуються отримання користувачем його приватних даних з джерела даних після виконання MPC, таких як країна/регіон, вік, стать та інша інформація з урядових веб-сайтів. На основі цих даних будується дерево вимог, де кожен вузол представляє хеш-значення своїх дочірніх вузлів. Використовуючи підпис babyjub, додаються випадкові числа для запобігання детальним атакам, кореневий хеш основного дерева вимог зберігається в dSBT, а нульове знання, яке підтверджує правильність дерева, має бути згенеровано та підтверджено смарт-контрактом.

Запит на оголошення, наприклад, для визначення, чи вік користувача перевищує 18 років, користувачеві потрібно лише надати підтвердження, яке представляє вік, що міститься в деревоподібній структурі, і значення цього листа перевищує 18. Користувач може безпосередньо передати це підтвердження перевіряючому, який може виконати функцію в ланцюзі для перевірки підтвердження. Це гарантує, що фактичні приватні дані користувача залишаються прихованими для всіх зацікавлених сторін, і лише формулювання запиту даних вибірково розкривається певному перевіряючому.