У чому полягає різниця між Brevis, ораклами та іншими ZK співпроцесорами?

Фундаментальна різниця між оракулами та ZK-копроцесорами, зокрема Brevis, полягає у напрямку руху даних: оракули забезпечують доставку зовнішніх офчейн-даних у блокчейн, а ZK-копроцесори, такі як Brevis, виконують верифіковані обчислення на основі вже наявних ончейн-історичних даних, повертаючи результати, які можна математично перевірити. Як платформа верифікованих обчислень для Web3, Brevis (BREV) відповідає на питання «як обчислювати ончейн-дані та доводити їхню коректність», тоді як оракули вирішують задачу «як доставити офчейн-дані в ончейн».

Смарт-контракти у блокчейнах не мають прямого доступу до зовнішніх даних і не можуть ефективно відтворювати великі обсяги історичних транзакцій ончейн. Ці обмеження стали поштовхом для розвитку оракулів і ZK-копроцесорів: оракули забезпечують надходження зовнішніх даних у блокчейн, а ZK-копроцесори надають можливість довірених обчислень на історичних ончейн-даних. Усвідомлення цієї різниці є ключовим для вибору інфраструктури або комбінування обох підходів для конкретних завдань.

Рис. 1. Порівняння Brevis ZK Coprocessor і оракула за чотирма критеріями: напрям даних, модель довіри, обчислення, верифікація.

Що таке оракул і які проблеми він вирішує?

Оракул — це міст даних між блокчейном і зовнішнім світом, головне завдання якого — безпечно передавати офчейн або зовнішні дані до смарт-контрактів ончейн. Основні сценарії використання: цінові фіди, генерація випадкових чисел, фіксація результатів подій, синхронізація стану між різними системами.

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

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

Що таке ZK-копроцесори на кшталт Brevis?

ZK-копроцесори, такі як Brevis, працюють із історичними та кросчейн-даними, які вже є ончейн, виконують складні обчислення офчейн і повертають як результати, так і zero-knowledge докази. Такі докази дозволяють смарт-контрактам математично перевіряти коректність обчислень ончейн. ZK data coprocessors отримують достовірні дані з архівних вузлів офчейн, виконують обчислення, а потім повертають результати й докази в ончейн, забезпечуючи повний цикл «обчислення офчейн, верифікація ончейн».

Brevis працює на базі ZK data coprocessor і Pico zkVM, підтримуючи дві моделі безпеки: чисто-ZK (чистий zero-knowledge) і coChain (OP), як описано у BREV Token and coChain. Чисто-ZK модель ґрунтується на криптографічних доказах, а coChain модель використовує стейкінг і слешинг на базі Ethereum для додаткової криптоекономічної безпеки.

На відміну від оракулів, ZK-копроцесори не залежать від чесності репортерів даних. Вони дозволяють перевіряти сам процес обчислення: якщо доказ дійсний, контракт підтверджує існування і правильність відповідних ончейн-даних та обчислень, мінімізуючи потребу у довірі.

Як відрізняються джерела даних і моделі довіри?

Оракули отримують зовнішні, офчейн-дані (ціни, події, API), а ZK-копроцесори працюють із вже наявними ончейн-даними (історія транзакцій, баланси, кросчейн-стейти).

За моделлю довіри, оракули покладаються на вузли-репортери або мультипідпис із економічними стимулами — це соціально-економічна модель довіри. ZK-копроцесори базуються на математичній перевірці zero-knowledge proof — криптографічна модель довіри.

Жодна модель не є абсолютною. Зовнішні дані не можна довести лише криптографічно, і відповідність ончейн-цін ринковим цінам у фізичному світі завжди потребує надійного джерела. Однак обчислення на вже наявних ончейн-даних можна прямо перевірити через ZK-докази.

Як відрізняються їхні обчислювальні можливості?

Оракули переважно виконують «транспорт даних»: передають і агрегують зовнішні дані для ончейн-використання без складної аналітики ончейн-даних. ZK-копроцесори можуть виконувати «важкі обчислення» — проводити масштабну статистику, агрегування й навіть інференцію моделей на історичних даних офчейн.

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

Таблиця: ключові відмінності між Brevis, оракулами та іншими ZK-копроцесорами

Нижче наведено порівняння ZK-копроцесорів на кшталт Brevis, інших ZK-копроцесорів і оракулів за чотирма критеріями: напрям даних, модель довіри, обчислювальні можливості, метод верифікації.

Ключові моменти: оракули та ZK-копроцесори знаходяться на протилежних кінцях потоку даних. «Інші ZK-копроцесори» як базова інфраструктура мають індивідуальні компроміси щодо доступу до даних, систем доказів і моделей безпеки. Brevis вирізняється універсальним Pico zkVM і подвійною моделлю чисто-ZK/coChain. Таблиця дає загальний огляд і не містить висновків щодо сторонніх проєктів без підтвердження.

Який тип слід використовувати у різних сценаріях?

Вибір залежить від того, чи потрібні застосунку «зовнішні дані в ончейн» чи «обчислення на історичних ончейн-даних». Оракули використовують для ончейн-цін активів у реальному часі, результатів офчейн-подій або випадкових чисел. ZK-копроцесори краще підходять для стимулювання користувачів на основі довгострокової ончейн-активності, контролю ризиків або кросчейн-агрегації.

Сценарії внесення даних в ончейн зазвичай вирішують оракули: ціни ліквідації у кредитуванні, розрахунки деривативів, тригери страхових подій. Сценарії обчислення історичних даних найкраще вирішують ZK-копроцесори: винагорода за реальний обсяг торгів, розрахунок лояльності за тривалість холду, агрегування активів з різних ланцюгів для контролю ризиків. На практиці обидва підходи часто поєднують: DeFi-застосунок може використовувати оракули для зовнішнього ціноутворення і ZK-копроцесори для оцінки історичного внеску ончейн — ці рішення доповнюють одне одного.

Рис. 2. Вибір сценарію: для зовнішніх даних в ончейн використовуйте оракули, для верифікованих обчислень на історичних ончейн-даних — ZK-копроцесори на кшталт Brevis; обидва підходи можна комбінувати.

Які обмеження та особливості слід враховувати при такому порівнянні?

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

Гібридні рішення стають дедалі поширенішими: інфраструктура може поєднувати зовнішні дані з верифікованими обчисленнями або використовувати zero-knowledge докази для підвищення цілісності даних оракулів. Жорстке розділення між підходами може ігнорувати такі гібридні моделі.

Вартість і затримки теж важливі: генерація ZK-доказів вимагає спеціалізованого обладнання і має вищі накладні витрати для універсальних обчислень порівняно з нативним виконанням. Оракули залежать від частоти оновлення, покриття вузлів і затримки агрегування. Порівнювати слід за конкретними сценаріями, а не за одним показником.

Висновок

Оракули та ZK-копроцесори на кшталт Brevis вирішують різні завдання на протилежних кінцях потоку даних у блокчейні: оракули доставляють зовнішні дані в ончейн, спираючись на довіру та економічні стимули; ZK-копроцесори забезпечують верифіковані обчислення на історичних ончейн-даних, спираючись на математичну цілісність zero-knowledge proof. Кожен підхід має унікальну роль щодо напрямку даних, моделі довіри й обчислювальних можливостей, а межі між ними не є абсолютними. На практиці для максимальної ефективності часто застосовують гібридні підходи.

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

Чи можуть оракули та ZK-копроцесори замінити одне одного?

Ні, вони не можуть напряму замінити одне одного. Оракули відповідають за внесення зовнішніх, офчейн-даних у блокчейн, а ZK-копроцесори виконують верифіковані обчислення на вже наявних ончейн-даних. Вони діють на різних етапах потоку даних і часто використовуються разом або в комбінації в одному застосунку.

У чому полягає ключова відмінність між Brevis та оракулами?

Головна різниця — у напрямку даних і моделі довіри. Оракули доставляють зовнішні дані в ончейн, а довіра ґрунтується на вузлах/мультипідписі й економічних стимулах. Brevis і подібні ZK-копроцесори обробляють історичні ончейн-дані й повертають zero-knowledge докази, що дозволяє математично перевірити результати безпосередньо ончейн.

Чому ZK-копроцесори вважаються мінімально довіреними?

ZK-копроцесори дозволяють перевірити сам процес обчислення: якщо ончейн zero-knowledge proof дійсний, це підтверджує наявність відповідних даних і правильність виконаного обчислення — не потрібно довіряти стороннім учасникам для репортингу чи обчислень. Тому вони вважаються мінімально довіреними.

Чи використовують оракули zero-knowledge докази?

Деякі оракульні рішення використовують zero-knowledge докази для підвищення цілісності або приватності даних, але їхня основна функція — доставляти зовнішні дані в ончейн. У оракулах zero-knowledge докази зазвичай допоміжні, а в ZK-копроцесорах — це основний механізм перевірки коректності обчислень.

Чи може застосунок використовувати і оракули, і ZK-копроцесори?

Так. Наприклад, DeFi-застосунок може використовувати оракули для отримання цін активів у реальному часі, а ZK-копроцесори — для розрахунку стимулів чи контролю ризиків на основі реальної ончейн-історії користувача, вирішуючи водночас завдання «зовнішні дані в ончейн» і «обчислення на історичних ончейн-даних».