zkTLS і традиційні оракули: які вебдані краще підходять для ончейну?

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

Далі наведено параметри та контрольний список «Обирайте, якщо», зокрема пояснення, де закінчуються скриншоти або PDF і починається криптографічне походження даних. Протокольні обгортки містять оракул zkPass zkTLS; наративи про фіди з нульовим розголошенням наведено поруч із zkOracle і zkCoprocessor.

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

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

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

Рисунок 1. Порівняння zkTLS і традиційних оракулів за доступом до джерела, конфіденційністю, припущеннями щодо довіри та затримкою.

Що таке zkTLS?

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

zkTLS не замінює HTTPS і не визначає автоматично, чи правильні бізнес-факти в джерелі; він надає докази походження та цілісності. Transport Layer Security — це протокол 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-сеансі надійшли від сервера, прив’язаного до домену та сертифіката. Деякі конструкції використовують MPC — безпечні багатосторонні обчислення — під час TLS-рукостискання між клієнтом і сторонами-нотаріусами, тоді як інші покладаються на свідків на основі 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 або спеціалізовані партнерства з даними підходять краще, ніж стандартне завдання фіду.