zkTLS и традиционные оракулы: какие веб-данные лучше подходят для ончейна?

Это сравнение предназначено для специалистов по продуктам и рискам, выбирающих между полями на закрытых страницах и публичными фидами. Сам механизм разобран в zkTLS; общее понятие для мостов передачи офчейн-данных относится к блокчейн-оракулам. В разделах ниже сопоставляются источник, конфиденциальность, доверие и задержка, а также рассматривается граница между скриншотами/PDF-файлами и криптографическим подтверждением происхождения данных.

Далее приведены параметры сравнения и список «Выберите, если», включая объяснение того, где заканчиваются скриншоты или PDF-файлы и начинается криптографическое подтверждение происхождения. Среди протокольных решений есть оракул zkPass zkTLS; описания фидов с доказательствами с нулевым разглашением представлены рядом с zkOracle и zkCoprocessor.

Основные выводы

• zkTLS оптимизирован для подтверждения того, с какого сервера, привязанного к домену, получено поле в HTTPS-сессии. Традиционные оракулы оптимизированы для непрерывной записи публичных фактов в блокчейн с защитой от манипуляций.
• Закрытые страницы после входа без подписанных публичных API подходят для zkTLS. Непрерывные рыночные цены и агрегация из нескольких источников подходят для зрелых сетей оракулов.
• Выборочное раскрытие данных является распространенным преимуществом zkTLS. Традиционные фиды обычно публикуют агрегированные значения для всех наблюдателей в блокчейне.
• Скриншоты и загруженные PDF-файлы могут поддерживать операционные процессы, но не обеспечивают проверяемого происхождения сессии. Криптографические утверждения подтверждают происхождение и целостность, но не достоверность исходных данных.
• Выбирайте с помощью списка «Выберите, если» и включайте риски нотариуса/набора нод, а также ошибки источника в модель угроз.

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

Рисунок 1. Сопоставление zkTLS и традиционных оракулов по доступу к источнику, конфиденциальности, допущениям доверия и задержке.

Что такое zkTLS?

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

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

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

Что такое традиционный оракул?

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

Контракты считывают обновления фида, а не транскрипты браузера. Непрерывные данные публичного рынка естественно подходят для этого пути. Закрытые поля на страницах после входа часто не имеют подписанного публичного API, а сети фидов по умолчанию не воспроизводят HTTPS-сессию каждого пользователя. Поэтому децентрализованные приложения часто используют оракулы для общих внешних данных, а не для подтверждения персональных данных сессии. Стороны оракула обычно управляют серверами, которые получают данные через публичные конечные точки. Они не находятся внутри клиентского TLS-канала пользователя и поэтому не могут напрямую использовать закрытую банковскую страницу так, как это может сделать протокол zkTLS с клиентом и свидетелем.

Чем отличаются источники данных и пути доступа?

Основное различие заключается в следующем: zkTLS следует за сессиями, которые пользователь уже может открыть с источником, а традиционные оракулы следуют за публичными источниками, которые могут получить ноды операторов.

В пути zkTLS клиент завершает HTTPS-сессию с сервером целевого домена, а доказательство может быть создано на основе любого HTTPS-сайта без предварительного доступа к API. В некоторых архитектурах используется модель Proxy, в которой посредник свидетельствует или перенаправляет обмен между клиентом и сервером вместо обработки сессии в стиле MPC. В других подходах на базе MPC совместно выполняется TLS-рукопожатие, то есть этап протокола, устанавливающий защищенный ключ сессии, поэтому ни одна сторона по отдельности не может подделать серверный шифротекст. Нотариус, Proxy или TEE оставляет проверяемые свидетельства, после чего создается доказательство утверждения. В пути традиционного оракула ноды получают данные торговых площадок, индексов или публичных API, агрегируют их в фид, а контракты считывают этот фид. Это делает zkTLS полезным для проверки данных Web2 из существующих систем при отсутствии доступного публичного фида. В противном случае традиционная проверка данных или иной процесс подтверждения потребовал бы от отдельной стороны напрямую получить те же данные из источника. Без пользовательской сессии zkTLS не может заменить публичный фид. Без доступных для получения публичных источников ноды не могут безопасно использовать закрытые поля после входа. Подходы с поддержкой сервера также зависят от разрешения серверов источника на экспорт данных, поэтому операторы могут ограничивать передаваемые данные. Продукты, использующие Web Proofs, рассматривают клиента, сервер и стороны-свидетели как единый путь протокола. Публичные описания механизмов, такие как объяснение Oasis zkTLS и страница паттерна EthSystems zk-TLS, описывают тот же путь от сессии к доказательству.

Чем отличаются конфиденциальность, частные данные и выборочное раскрытие?

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

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

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

Чем отличаются допущения доверия, целостность данных и режимы отказа?

Доверие в zkTLS основано на привязке к домену/сертификату и на том, честен и доступен ли путь через нотариуса, Proxy или TEE. Если сервер источника возвращает неверное поле, формально действительное доказательство все равно может быть принято. Происхождение не означает достоверность содержимого. Если раскрытие с нулевым разглашением реализовано корректно, проверяющий не получает информацию о персональных данных доказывающей стороны. Тем не менее проверяющим следует выяснить, какие стороны владеют ключевым материалом, какие стороны выполняют протокол MPC или Proxy и какой сертификат сервера закрепляет TLS-конечную точку.

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

Как соотносить задержку, стоимость и типы данных?

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

zkTLS требует затрат на каждую сессию и генерацию доказательства, обычно обеспечивает более высокую задержку, чем путь с активным фидом, и подходит для пороговых значений баланса, уровней участия, полей о трудоустройстве или репутации. Сюда относится подтверждение того, что банковский счет или баланс банковского счета превышает требуемый порог, без раскрытия исходных учетных данных или полной выписки. Путь MPC TLS может требовать значительного обмена данными. Путь Proxy может использовать менее интерактивные вычисления, но все равно требует активного сервера-свидетеля. Пути TEE переносят обработку ключей в защищенное аппаратное обеспечение. Традиционные оракулы поддерживают непрерывные обновления и подходят для цен, ставок и публичных событий. Они предназначены для рыночных данных с низкой задержкой, которые многие клиентские приложения используют в каждом блоке.

Скриншоты, PDF-файлы или ручные загрузки могут показывать «нечто, похожее на страницу», но третья сторона не может криптографически проверить, что TLS-сессия была установлена с сервером целевого домена или что поля не были изменены клиентом. Утверждения в стиле zkTLS могут обеспечивать подлинность данных и сохранять происхождение данных для такого типа закрытых входных данных, но они по-прежнему не доказывают достоверность бизнес-фактов источника. Даже в этом случае неверные страницы источника, сбои DOM и недоступность нотариуса могут нарушать корректность или доступность. Использование скриншотов как единственного условия означает доверие к загрузившему их пользователю и проверяющему. Рассмотрение доказательств как «истины» игнорирует тот факт, что ошибки источника могут оставаться формально действительными. Команды, использующие и скриншоты, и криптографические доказательства, должны обозначать, какой класс свидетельств принимает каждое условие.

Следует ли выбрать zkTLS или традиционный оракул?

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

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

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

Итог

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

Кратко: используйте традиционный оракул, когда многим контрактам нужен один и тот же публичный фид; используйте zkTLS, когда клиент должен подтвердить закрытый TLS-ответ от сервера источника с помощью доказательства выборочного раскрытия. MPC, Proxy и TEE остаются основными стилями свидетелей для этого пути протокола, и каждый из них меняет состав сторон, владеющих ключевым материалом, а также объем интерактивных вычислений, которые должен выполнить клиент. Скриншоты и PDF-файлы не могут устранить разрыв в криптографическом подтверждении происхождения. TLS-доказательство не может автоматически гарантировать корректность содержимого источника. Выбор с помощью списка «Выберите, если» и включение режимов отказа нотариуса/нод и источника в модель угроз эффективнее, чем обсуждение названий.

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

В чем разница между zkTLS и традиционными оракулами?

Традиционные оракулы главным образом передают публичные данные в смарт-контракт, тогда как продукты используют zkTLS, когда необходимо подтвердить подлинность данных из HTTPS-сессии, которой владеет пользователь. Это также влияет на то, видит ли проверяющий исходную запись или только доказательство утверждения о ней. zkTLS доказывает, что поля в TLS-сессии получены с сервера, привязанного к домену и сертификату. В некоторых архитектурах во время TLS-рукопожатия между клиентом и сторонами нотариуса используется MPC, то есть безопасные многосторонние вычисления, а другие полагаются на свидетелей на основе Proxy или TEE. Традиционные оракулы непрерывно записывают публичные офчейн-факты, например цены, в контракты через наборы нод и агрегацию из нескольких источников. Один подход оптимизирован для происхождения сессии, другой — для доступности фида и устойчивости к манипуляциям. В архитектурах на основе Proxy или свидетеля самому серверу источника обычно не требуется изменяться, а клиент по-прежнему хранит или разделяет ключ сессии согласно правилам протокола.

Когда следует использовать zkTLS, а когда традиционный оракул?

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

Могут ли скриншоты или загруженные PDF-файлы заменить доказательство zkTLS?

Не всегда надежно. Скриншоты и PDF-файлы с веб-страницы могут выглядеть убедительно в операционном процессе, но они не содержат проверяемого происхождения TLS-сессии и криптографического доказательства происхождения или целостности сессии. Поэтому третья сторона не может легко исключить изменение изображений или использование неверных страниц. Напротив, свидетель HTTP Proxy может наблюдать за обменом или маршрутизировать его, сохраняя проверяемое происхождение способом, недоступным для скриншота или PDF-файла. Утверждения в стиле zkTLS обеспечивают привязку к домену и пути проверки целостности. Однако если источник возвращает неверные данные, доказательство все равно может быть формально действительным.

Означает ли успешная проверка zkTLS, что данные источника верны?

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

Могут ли традиционные оракулы напрямую использовать поля веб-страницы пользователя после входа?

Обычно нет, если речь идет о персональной HTTPS-сессии. Традиционные ноды обычно получают публичные источники через API или другие публичные конечные точки, а не транскрипт закрытой сессии пользователя после входа или Web Proofs. Некоторые новые архитектуры оракулов «от частного к частному» вместо этого передают аутентифицированные TLS-данные в серверы закрытых вычислений, а не публикуют их как стандартный фид. Эта модель ориентирована на обеспечение происхождения данных для закрытых входных данных, может сохранять зашифрованные данные конфиденциальными для соблюдения нормативных требований и объединять данные нескольких клиентов для совместных вычислений. Такие платформы, как Private-to-Private Oracles от Nillion, используют закрытые вычисления для конфиденциальности, тогда как Reclaim Protocol является примером подхода в стиле Proxy, отличающегося от него. Такой подход также может повышать безопасность, перенося конфиденциальные данные сессии в закрытые вычисления вместо раскрытия исходного содержимого страницы. Когда закрытые страницы после входа не имеют подписанного открытого API, Web Proofs в стиле zkTLS или специализированные партнерства по данным подходят лучше, чем стандартная задача фида.