Що таке zkTLS: пояснення для початківців

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

Нижче розглянуто визначення, етапи від сеансу до доказу, відмінності між MPC/Proxy/TEE, варіанти використання, зіставлення з оракулами та ризики, а також публічні описи механізмів, зокрема пояснення zkTLS від Oasis і сторінку патерна zk-TLS від EthSystems.

Основні висновки

• zkTLS перетворює сеанс HTTPS на перевірюване твердження: прив’язує домен і сертифікат та за потреби розкриває лише результат предиката.
• Назва часто вводить в оману: не кожна конструкція використовує докази з нульовим розголошенням під час рукостискання; найпоширенішими є три підходи — MPC, Proxy і TEE.
• Оскільки TLS завершується спільним симетричним ключем сеансу, клієнт самостійно може підробити транскрипт для демонстрації — тому використовують нотаріусів, проксі або TEE.
• Походження даних не означає їх правдивості: якщо джерело повертає некоректне поле, доказ усе одно може бути формально дійсним.
• Верифікатори мають перевіряти прив’язку до домену/сертифіката, предикат і підпис атестації або корінь довіри в ланцюжку доказу.

Що таке zkTLS і яку проблему він розв’язує?

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

Стандартне TLS-рукостискання виводить симетричний ключ сеансу: і браузер, і сервер можуть шифрувати та розшифровувати дані. Якщо користувач самостійно показує шифротекст разом із цим ключем, інші сторони не можуть виключити, що користувач зашифрував підроблений відкритий текст, а потім розшифрував його на вимогу. Отже, клієнт без інших учасників не може бути надійним свідком. Саме це обмеження зумовлює потребу в нотаріусах, проксі або TEE.

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

Як працює zkTLS? Від сеансу HTTPS до верифікованого твердження

На високому рівні zkTLS перетворює звичайний HTTPS-сеанс на перевірюваний доказ: користувач відкриває сеанс із джерелом; шлях через MPC-нотаріуса, Proxy або TEE залишає перевірювані докази; потім створюється та перевіряється доказ вибіркового розкриття.

1. Відкрийте сеанс — Запустіть TLS для цільового домену; прив’язка сертифіката й домену стане частиною подальшого твердження.
2. Спільно засвідчіть або делегуйте — Нотаріус бере участь у рукостисканні/розшифруванні (MPC), проксі засвідчує напрямок шифротексту (Proxy) або TEE виконує запит, тому клієнт самостійно не може легко підробити шифротекст, надісланий сервером; деякі конструкції розглядають це як багатосторонній протокол, а не потік за участю лише клієнта.
3. Отримайте цільове поле — У межах сеансу запитайте сторінку акаунта або API та отримайте зашифровану відповідь.
4. Створіть твердження — Сформуйте доказ (або підписи ланцюжка) щодо зобов’язань транскрипту, ідентичності сервера та предиката, наприклад balance > threshold; підходи на основі схем перетворюють обмеження транскрипту на результати доказу.
5. Надішліть на перевірку — Контракт або контрагент перевіряє доказ і корені довіри, після чого приймає або відхиляє його.

Вибіркове розкриття є поширеним другим рівнем: можна довести, що баланс перевищує поріг, не розкриваючи точну суму, або виділити одне поле, приховавши решту. Згідно з приміткою Reclaim про «zk» у zkTLS, приватність на основі ZK часто є доповненням; базова вимога полягає в тому, щоб переконати третю сторону, що відповідь справді надійшла від джерела.

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

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

Чому це називається zkTLS? Чим відрізняються MPC, Proxy і TEE?

«zkTLS» — поширений узагальнювальний термін, який натякає, що докази з нульовим розголошенням мають виконуватися під час TLS-рукостискання, але це не завжди так. Цей ярлик часто широко застосовують до гібридного протоколу, хоча не кожна реалізація справді відповідає такому опису. Багато конструкцій ближчі до Web Proofs або TLS-атестацій: їхній фокус — верифікованість, а не обов’язкове ZK усередині рукостискання.

Усі три підходи відповідають на те саме питання: як переконати третю сторону, що шифротекст надійшов від сервера, не передаючи симетричний ключ для можливих зловживань. Проксі можуть спостерігати напрямок передавання даних, не бачачи відкритого тексту. Конструкції MPC/2PC у стилі TLSNotary використовують спільні ключі, щоб блокувати односторонню підробку; конструкції Proxy поєднують атестації напрямку з доказом розшифрування на стороні користувача; конструкції 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, Proxy і TEE забезпечують цілісність за різних припущень щодо довіри.

Перед запуском врахуйте, що клієнт із симетричним ключем може інсценувати підроблений сеанс; контрольні списки верифікатора мають охоплювати домен/сертифікат, предикат і корені довіри; походження не означає правдивість вмісту; а традиційні оракули та zkTLS розподіляють завдання між безперервними потоками даних і доказами полів із приватних сторінок. Обирайте підхід відповідно до моделі загроз і включайте ризики джерела та атестації до цієї моделі.

Поширені запитання

Що таке zkTLS?

zkTLS — це сімейство конструкцій, побудованих на стандартному TLS/HTTPS, які створюють твердження, доступні для перевірки третьою стороною: що конкретні дані надійшли від сервера, прив’язаного до домену та сертифіката, з можливістю розкрити лише результат предиката. Він поєднує приватні поля Web2 із перевіркою контрактами, не замінюючи HTTPS.

Як zkTLS перетворює HTTPS-сеанс на верифіковане твердження?

Клієнт і джерело відкривають сеанс; MPC-нотаріус, Proxy або TEE спільно засвідчує чи делегує виконання, щоб клієнт самостійно не міг підробити серверний шифротекст; створюється доказ вибіркового розкриття; верифікатор перевіряє прив’язку до домену, предикат і корені довіри, перш ніж прийняти або відхилити твердження.

Чи повинен zkTLS використовувати докази з нульовим розголошенням під час TLS-рукостискання?

Ні. Багато систем, позначених як zkTLS, використовують MPC, Proxy або TEE для забезпечення цілісності; докази з нульовим розголошенням часто з’являються пізніше для вибіркового розкриття або доказів розшифрування у стилі Proxy. Саме рукостискання може взагалі не виконувати ZK-схему — «zk» є поширеним ярликом.

Чим zkTLS відрізняється від традиційних оракулів?

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

Які основні ризики під час покладання на zkTLS?

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