Как работает zkPass? 3P-TLS + смешанная ZK для создания нулевых знаний Машина Oracle

! [как работает 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 вычислений для шифрования ключа (enc_key) и ключа проверки сообщения (mac_key) между P и V. Ключевое проектирование заключается в том, что 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 использует основанный на VOLE интерактивный ZK протокол для аутентификации, гарантируя, что данные поступают из точного источника и защищены от модификации клиентом. Протокол VOLE-ZK 23 представляет собой рамочную структуру «отправка и доказательство», где доказатель (P) и проверяющий (V) совместно генерируют множество экземпляров VOLE, каждый из которых удовлетворяет линейной формуле «m = k + w * delta». P использует некоторые компоненты этой формулы в качестве обязательств, V содержит остальные компоненты.

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

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

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

zkSBT: Система комбинируемых токенов привязки души

! архитектура zkSBT zkPass

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

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

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