Что такое zkTLS: объяснение для начинающих

zkTLS предназначен для тех, кому нужно передать в смарт-контракт или контрагенту значения с веб-страницы или аутентифицированного API, а не для создания нового транспорта взамен HTTPS. По сравнению со скриншотами или самостоятельными заявлениями он превращает утверждения «сеанс подключился к целевому сайту» и «поле соответствует условию» в проверяемые доказательства. Для непрерывных публичных рыночных потоков данных чаще используют блокчейн-оракулы; сравнение с потоками данных приведено ниже.

В разделах ниже рассматриваются определение, этапы от сеанса до доказательства, различия между MPC, прокси и TEE, сценарии использования, отличие от оракулов и риски, а также описания публичных механизмов, например объяснение zkTLS от Oasis и страница EthSystems о паттерне zk-TLS.

Ключевые выводы

• zkTLS превращает HTTPS-сеанс в проверяемое утверждение: связывает домен и сертификат и при необходимости раскрывает только результат проверки условия.
• Название часто вводит в заблуждение: не во всех архитектурах доказательства с нулевым разглашением используются на этапе рукопожатия; наиболее распространены три подхода: MPC, прокси и TEE.
• Поскольку TLS завершается созданием общего симметричного ключа сеанса, клиент в одиночку может подделать демонстрируемую расшифровку транскрипта. Поэтому нужны нотариусы, прокси или TEE.
• Происхождение данных не гарантирует их достоверность: если источник возвращает неверное поле, доказательство всё равно может быть формально действительным.
• Проверяющая сторона должна проверить привязку к домену и сертификату, условие, а также подпись аттестации или корень доверия в пути доказательства.

Что такое zkTLS и какую проблему он решает?

zkTLS устраняет пробел в обычном TLS. Transport Layer Security лежит в основе HTTPS-подключений браузеров, шифруя и аутентифицируя канал между клиентом и сервером. Однако после завершения сеанса трудно убедить третью сторону, что сервер действительно вернул этот контент, не передавая материалы расшифровки, которыми можно злоупотребить, и не полагаясь на скриншоты. Поэтому смарт-контрактам сложно использовать поля, доступные после входа в аккаунт.

Стандартное TLS-рукопожатие создаёт симметричный ключ сеанса: и браузер, и сервер могут шифровать и расшифровывать данные. Если пользователь самостоятельно показывает шифротекст вместе с этим ключом, другие стороны не могут исключить, что пользователь зашифровал поддельный открытый текст, а затем расшифровал его по запросу. Поэтому клиент в одиночку не может быть надёжным свидетелем. Это ограничение обосновывает использование нотариусов, прокси или TEE.

zkTLS предоставляет доказательства происхождения и целостности данных, а не окончательное решение об их фактической достоверности. Доказательство того, что поле баланса получено из TLS-сеанса сайта, не опровергает ошибочный ввод данных или подменённую страницу. Это смежная тема с нарративами о каналах данных с нулевым разглашением в zkOracle и zkCoprocessor, но относится к другой предметной области.

Как работает zkTLS? От HTTPS-сеанса к проверяемому утверждению

На высоком уровне zkTLS преобразует обычный HTTPS-сеанс в проверяемое доказательство: пользователь открывает сеанс с источником; путь через MPC-нотариуса, прокси или TEE оставляет проверяемые свидетельства; затем создаётся и проверяется доказательство выборочного раскрытия.

1. Откройте сеанс — установите TLS-соединение с целевым доменом. Сертификат и привязка к домену становятся частью последующего утверждения.
2. Совместное свидетельствование или делегирование — нотариус участвует в рукопожатии или расшифровке данных через MPC, прокси подтверждает направление шифротекста, либо TEE выполняет запрос. Это не позволяет клиенту в одиночку легко подделать шифротекст, якобы отправленный сервером. В некоторых архитектурах этот этап рассматривается как многосторонний протокол, а не как процесс с единственным клиентом.
3. Получите целевое поле — в рамках сеанса запросите страницу аккаунта или API и получите зашифрованный ответ.
4. Создайте утверждение — сформируйте доказательство или подписи пути на основе обязательств транскрипта, идентичности сервера и условия, например balance > threshold. В схемах на основе схем ограничений транскрипта преобразуются в результаты доказательства.
5. Отправьте на проверку — смарт-контракт или контрагент проверяет доказательство и корни доверия, затем принимает или отклоняет его.

Выборочное раскрытие является распространённым вторым уровнем: можно доказать, что баланс превышает порог, не раскрывая точную сумму, или извлечь одно поле, скрыв остальные. Согласно материалу Reclaim о «zk» в zkTLS, ZK для конфиденциальности часто служит дополнительным улучшением. Более базовое требование заключается в том, чтобы убедить третью сторону, что ответ действительно поступил от источника.

Рисунок 1. zkTLS проходит путь от HTTPS-сеанса клиента через путь аттестации MPC, прокси или TEE к доказательству выборочного раскрытия, которое проверяет верификатор или смарт-контракт.

Контрольный список для верификатора должен включать как минимум четыре пункта: привязку домена и сертификата к заявленному источнику; условие, соответствующее бизнес-правилам; подпись пути доказательства или корень доверия из списка разрешённых; а также проверку того, не нарушат ли изменения структуры источника работу парсера. Пропуск любого из этих пунктов превращает «проверяемое» в «похожее на доказательство», хотя цель состоит в предоставлении проверяемых данных смарт-контрактам или контрагентам.

Почему это называется zkTLS? Чем отличаются MPC, прокси и TEE?

«zkTLS» — распространённый общий термин, создающий впечатление, что доказательства с нулевым разглашением обязательно выполняются во время рукопожатия. Однако это не всегда так. Это обозначение часто широко используется для гибридного протокола, хотя не каждая реализация действительно соответствует такому описанию. Многие архитектуры ближе к Web Proofs или TLS-аттестациям: главное в них проверяемость, а не обязательное применение ZK внутри рукопожатия.

Все три подхода отвечают на один вопрос: как убедить третью сторону, что шифротекст поступил от сервера, не передавая симметричный ключ, которым можно злоупотребить. Прокси могут наблюдать направление передачи данных, не видя открытый текст. Архитектуры MPC/2PC в стиле TLSNotary используют совместные ключи, чтобы исключить одностороннюю подделку. Подходы с прокси сочетают аттестации направления с доказательством расшифровки на стороне пользователя. В TEE сеанс размещается в аппаратно изолированной среде. ZK для конфиденциальности может использоваться поверх этих механизмов для скрытия полей, но TEE и большинство MPC-рукопожатий не используют ZK на уровне рукопожатия.

Выбор подхода зависит от модели угроз и затрат: приемлемы ли единичный нотариус, прокси или TEE; должны ли сеансы сохранять низкую задержку; поддерживает ли источник только определённые версии TLS. Подходы MPC также обеспечивают, что ни один узел никогда не получает полный ключ. Воспринимайте «zk» как обозначение проверяемых веб-данных, а не как строгую криптографическую классификацию.

Для чего можно использовать zkTLS?

Классический сценарий использования — доказать, что офчейн-аккаунт соответствует порогу, не публикуя полную выписку: пороги баланса для определения кредитоспособности, проверки банковского баланса в финансовых процессах без раскрытия точной суммы, поля о занятости или репутации с портала после входа в аккаунт, а также подтверждение офчейн-активности для правил заданий. Общий признак таких сценариев заключается в том, что данные находятся за HTTPS и для них нет готового подписанного публичного API.

Сценарии идентификации и атрибутов включают проверку личности и верифицированные учётные данные, а также возрастные категории, уровни членства или сводные рейтинги. Верификатор видит результат условия, а не полную страницу с частными данными. Протокольные продукты, такие как оракул zkTLS от zkPass, представляют частные данные, которые можно проверить ончейн. Следует различать то, как протокол упаковывает доказательства, и то, что гарантирует сам паттерн zkTLS.

Другой класс — потоки данных с сохранением конфиденциальности: приложениям нужны поля с веб-сайтов в ончейн-приложениях без раскрытия полного открытого текста скрейпинга каждому наблюдателю. В этом случае zkTLS предоставляет доказательство поля с подтверждённым происхождением. Его всё равно следует отличать от непрерывных ценовых потоков и агрегации из нескольких источников, используемых в децентрализованных финансах и более широких процессах передачи данных из веба в блокчейн.

Чем zkTLS отличается от традиционных оракулов?

Традиционные оракулы ориентированы на запись офчейн-фактов, таких как цены и результаты событий, в блокчейн, часто через наборы узлов или потоки данных из нескольких источников. Это часть проблемы оракулов: как передавать надёжные офчейн- или веб-данные в смарт-контракты. zkTLS ориентирован на доказательство того, что поля HTTPS-сеанса получены от конкретного источника, при необходимости с выборочным раскрытием. Потоки данных оптимизированы для доступности и устойчивости к манипуляциям, а zkTLS — для преобразования веб-сеанса в проверяемое утверждение.

Для сравнения архитектуры потоков данных, допущений доверия и режимов отказа используйте zkTLS и традиционные оракулы. Краткое правило: для непрерывных публичных рыночных потоков по-прежнему лучше подходят зрелые сети оракулов; для частных полей со страниц после входа в аккаунт, требующих минимального раскрытия, лучше подходит zkTLS. Некоторые системы также рассматривают переносимость данных как отдельную цель проектирования. Эти подходы можно комбинировать, но ни один не заменяет другой.

Каковы преимущества и риски использования или применения zkTLS для конфиденциальных данных?

К преимуществам относится экспорт проверяемых полей везде, где пользователь всё ещё может выполнить HTTPS-подключение к источнику, без ожидания специального API для потока данных. Выборочное раскрытие позволяет смарт-контрактам проверять факт без раскрытия полной частной записи. Утверждения также могут программно проверяться смарт-контрактами.

Риски столь же конкретны. Честность и доступность нотариусов, прокси или TEE формируют корни доверия: сговор, отказ в обслуживании или простой могут привести к ложному принятию или сбоям. Архитектуры на основе TEE также несут риски безопасности, связанные с производителем оборудования или корнем аттестации. Честность источника находится вне области действия протокола: неверные страницы всё равно могут создавать формально действительные доказательства. Изменения пути к полю нарушают условия, а некоторые стеки нотариусов поддерживают лишь отдельные версии TLS.

Участникам, зависящим от системы, также следует учитывать стоимость создания доказательств, задержку сеанса и риск хранения транскриптов сеансов. zkTLS улучшает проверяемость происхождения данных, но не превращает произвольные веб-страницы в непроверенные источники истины.

Итоги

zkTLS превращает повседневные HTTPS-сеансы в проверяемые утверждения с минимальным раскрытием, чтобы смарт-контракты могли удостовериться, с какого сервера, привязанного к домену, получено поле, вместо доверия к скриншотам. «zk» не гарантирует использование нулевого разглашения во время рукопожатия. MPC, прокси и TEE обеспечивают целостность при разных допущениях доверия.

Перед запуском следует учитывать, что клиент с симметричным ключом в одиночку может инсценировать поддельный сеанс; контрольные списки верификатора должны охватывать домен и сертификат, условие и корни доверия; происхождение не означает достоверность содержимого; а традиционные оракулы и zkTLS разделяют задачи непрерывных потоков данных и доказательств полей с частных страниц. Выбирайте подход с учётом модели угроз и включайте риски, связанные с источником и аттестацией, в эту модель.

Часто задаваемые вопросы

Что такое zkTLS?

zkTLS — это семейство архитектур на основе стандартных TLS/HTTPS, создающих утверждения, которые может проверить третья сторона: что конкретные данные поступили с сервера, привязанного к домену и сертификату, с возможностью раскрыть только результат условия. Он связывает частные поля Web2 с проверкой смарт-контрактами, не заменяя HTTPS.

Как zkTLS преобразует HTTPS-сеанс в проверяемое утверждение?

Клиент и источник открывают сеанс. MPC-нотариус, прокси или TEE совместно свидетельствует о сеансе либо принимает на себя его выполнение, чтобы клиент в одиночку не мог подделать серверный шифротекст. Затем создаётся доказательство выборочного раскрытия. Перед принятием или отклонением верификатор проверяет привязку к домену, условие и корни доверия.

Должен ли zkTLS использовать доказательства с нулевым разглашением при TLS-рукопожатии?

Нет. Во многих системах, обозначаемых как zkTLS, для обеспечения целостности используются MPC, прокси или TEE. Доказательства с нулевым разглашением часто применяются позднее для выборочного раскрытия или доказательств расшифровки в схемах с прокси. Само рукопожатие может вообще не использовать ZK-схему. «zk» является распространённым обозначением.

Чем zkTLS отличается от традиционных оракулов?

Традиционные оракулы непрерывно передают офчейн-факты в смарт-контракты, стремясь использовать несколько источников и обеспечивать доступность. zkTLS доказывает происхождение и, при необходимости, выполнение условий для полей HTTPS-сеанса. Публичные потоки данных и поля с частных страниц после входа в аккаунт решают разные задачи. См. тему сравнения: эти подходы можно объединять.

Каковы основные риски при использовании zkTLS?

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