1. Вступ до концепції

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

Ключовим моментом є передача конкретних завдань конкретним співпроцесорам. Так само, як і на фабриці, начальник знає кроки кожної ланки і може зробити це сам або навчити співробітників всьому виробничому процесу, але це дуже неефективно і тільки він може виробляти одну деталь за раз, і тільки після того, як одна буде закінчена, він може виготовити наступну, тому він найняв багато конкретних співробітників. Кожен з них виконує свої обов'язки і виконує роботу, яку добре справляється у виробничому ланцюжку, у власних майстернях. Ланки ланцюжка можуть взаємодіяти один з одним. Спілкуйтеся і координуйте, але не заважайте один одному працювати. Вони роблять тільки те, що вміють найкраще. Ті, у кого швидкі руки і сильна фізична сила, можуть забивати шурупи. Керувати машинами можуть ті, хто вміє керувати машинами. Ті, хто знається на бухгалтерському обліку, можуть розрахувати обсяг виробництва і витрати. Асинхронна спільна робота для максимальної ефективності роботи.

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

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

2. Чому нам потрібен ZK копроцесор?

Один з найбільших тупиків, з якими стикаються розробники смарт-контрактів, залишаються високі витрати, пов'язані з обчисленням on-chain. Оскільки для кожної операції потрібно вимірювати газ, вартість складної логіки додатків швидко стане занадто високою для виконання, оскільки, хоча архівні вузли в DA-шарі блокчейну дійсно можуть зберігати історичні дані, саме тому речі, наприклад застосунки для аналізу поза ланцюжком, такі як Analytics, Nansen, 0xscope, та Etherscan можуть мати настільки багато даних з блокчейну та можуть йти у далеке минуле, але для смарт-контрактів це не є простою справою доступу до всіх цих даних. Вони можуть легко отримати доступ тільки до даних, збережених в стані віртуальної машини, останніх даних блоку та інших публічних даних смарт-контрактів. Для отримання більшої кількості даних смарт-контракти можуть витратити багато зусиль на доступ:

Розумні контракти в віртуальній машині Ethereum (EVM) мають доступ до хешів заголовків блоків останніх 256 блоків. Ці заголовки блоків містять всю інформацію про діяльність в блокчейні до поточного блоку та стисаються в 32-байтове хеш-значення за допомогою дерева Меркла та алгоритму хешування Keccak.

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

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

ZK rollups насправді є першими копроцесорами ZK, що підтримують той самий тип обчислень, які використовуються на рівні L1 на більшій масштабі та кількості. Цей процесор знаходиться на рівні протоколу, а ZK копроцесор, про який ми зараз говоримо, знаходиться на рівні додатків. ZK копроцесор підвищує масштабованість розумних контрактів, дозволяючи їм легко делегувати доступ до історичних даних on-chain та обчислення за допомогою ZK-доказів. Замість виконання всіх операцій в EVM, розробники можуть вивантажувати дорогі операції на ZK копроцесор і просто використовувати результати on-chain. Це надає новий спосіб масштабування розумних контрактів шляхом відокремлення доступу до даних та обчислень від консенсусу блокчейну.

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

3. Технічна реалізація

Ця частина буде використовувати архітектуру Axiom для пояснення того, як zk копроцесор технічно вирішує проблему. Насправді, існує два ядра: захоплення даних та обчислення. У цих двох процесах ZK забезпечує ефективність та приватність одночасно.

3.1 Захоплення даних

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

ZK копроцесор вирішує цю проблему трьома різними способами, збалансовуючи витрати, безпеку та легкість розробки:

1. Зберігайте додаткові дані в стані блокчейну та використовуйте EVM для зберігання усіх даних, використовуваних on-chain від верифікації читання співпроцесора. Цей підхід є досить дорогим та недосяжним вартісно для великих обсягів даних.
2. Довіряйте Оракулу або мережі підписантів для перевірки вхідних даних до співпроцесора. Це вимагає від користувачів співпроцесора довіри до Оракула або постачальника багатоособового підпису, що зменшує безпеку.
3. Використовуйте ZK-докази, щоб перевірити, чи будь-які дані on-chain, використані в ко-процесорі, були зафіксовані в історії блокчейну. Будь-який блок у блокчейні фіксує всі попередні блоки, тому будь-які історичні дані, надаючи криптографічні гарантії валідності даних і не вимагаючи додаткових припущень про довіру від користувача.

3.2 Розрахунок

Виконання обчислень поза ланцюжком у копроцесорі ZK вимагає перетворення традиційних комп'ютерних програм в ZK схеми. Наразі всі методи досягнення цього мають великий вплив на продуктивність, з доказами ZK від 10 000 до 1 000 000 в накладних в порівнянні з виконанням вихідної програми. З іншого боку, обчислювальна модель ZK схем відрізняється від стандартних комп'ютерних архітектур (наприклад, наразі всі змінні мають бути закодовані за модулем великого криптографічного простого числа, а реалізація може бути недетермінованою), що означає, що розробникам складно напряму їх писати.

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

1. Користувацькі схеми: Розробники пишуть власні схеми для кожного застосування. Цей підхід має найбільший потенціал продуктивності, але потребує значних зусиль розробника.
2. eDSL/DSL для схем: Розробники пишуть схеми для кожної програми, але абстрагуються від специфічних для ZK проблем в упередженій структурі (аналогічно використанню PyTorch для нейронних мереж). Проте продуктивність трохи нижча.
3. Розробники zkVM пишуть схеми в існуючих віртуальних машинах та перевіряють їх виконання в ZK. Це забезпечує найпростіший досвід для розробників при використанні існуючих віртуальних машин, але призводить до меншої продуктивності та гнучкості через різні моделі обчислень між віртуальними машинами та ZK.

4. Застосування

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

4.1 Defi

4.1.1 DEX

Візьмемо гачок в Uniswap V4 як приклад:

Hook дозволяє розробникам виконувати вказані операції в будь-якій ключовій точці в усьому життєвому циклі пула ліквідності - наприклад, перед або після торгівлі токенами, або перед або після змін позицій LP, спеціальні пули ліквідності, обміни, комісії. Як взаємодіяти з позиціями LP, наприклад:

• Часовий зважений середній ринковий мейкер (TWAMM);
• динамічні комісії на основі волатильності або інших вхідних даних;
• Ланцюжкове обмеження ціни замовлення;
• Депонуйте ліквідність, що виходить за межі обсягу, в протоколи кредитування;
• Спеціалізовані онлайн-оракули, такі як геометричні оракули;
• Автоматично складайте комісію по LP на позиціях LP;
• Прибуток від MEV Uniswap розподіляється серед LP;
• Програма знижок на вірність для LPs або трейдерів;

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

У довгостроковій перспективі співпроцесор ZK прискорить інтеграцію DEX і CEX. З 2022 року ми побачили, що DEX та CEX стали функціонально узгодженими. Усі основні CEX приймають цю реальність і впроваджують гаманці Web3, створюють EVM L2 і впроваджують існуючу інфраструктуру, як-от Lightning Network або відкритий вихідний код, щоб отримати частку ліквідності в мережі. Це явище невіддільне від бусту співпроцесора ZK. Усі функції, яких може досягти CEX, будь то grid-торгівля, подальші дії, швидке кредитування чи використання даних користувачів, DEX також можуть бути реалізовані через співпроцесор ZK. , а компонування та свобода DeFi, а також транзакції з дрібними валютами в ланцюжку важко досягти за допомогою традиційних CEX. У той же час технологія ZK також може захищати конфіденційність користувачів під час виконання.

4.1.2 Роздача токенів

Якщо деякі проекти хочуть проводити роздачі токенів, їм потрібен розумний контракт для запиту історичних дій за адресою, але не хочуть розкривати інформацію про адресу користувача та виконувати його без введення додаткового доказу довіри. Наприклад, проект, що робить Дефі-кредитування, хоче за допомогою взаємодії між адресою та серією протоколів кредитування, таких як Aave, Compound, Fraxlend та Spark як стандарту для роздач токенів, історичний захват даних та конфіденційні функції ZK-копроцесора можуть легко вирішити цю потребу.

4.2 ZKML

Ще однією захоплюючою рисою ZK копроцесора є область машинного навчання. Оскільки розумним контрактам можуть бути надані можливості обчислень поза ланцюжком, на ланцюжку стане можливим високоефективне машинне навчання. Фактично, ZK копроцесор також є невід'ємною частиною для введення та обчислення даних ZKML. Він може видобувати введення, необхідне для машинного навчання, з історичних даних на ланцюжку/поза ланцюжком, і потім записувати обчислення в ZK схему і відправляти її на ланцюжок.

4.3 KYC

KYC — це великий бізнес, і зараз світ web3 поступово переходить на комплаєнс. За допомогою співпроцесора ZK можна зробити перевірений доказ смарт-контракту, захопивши будь-які офчейн-дані, надані користувачем, без необхідності розкриття будь-якої непотрібної інформації користувачів, насправді деякі проекти реалізуються, наприклад, хук KYC від Uniswap, який використовує співпроцесор ZK Pado для збору даних поза мережею без довіри. Підтвердження активів, підтвердження академічної кваліфікації, підтвердження подорожі, підтвердження водіння, підтвердження правоохоронних органів, підтвердження гравців, підтвердження транзакцій... Будь-яка історична поведінка в ланцюжку та поза ним може бути навіть упакована в повну ідентичність і може бути написана з великою довірою. ZK доводить, що він знаходиться в ланцюжку, захищаючи конфіденційність користувачів.

4.4 Соціальний

Спекулятивний атрибут Friend.tech насправді сильніший за соціальний. Суть полягає в кривій зв'язку. Чи можна додати гачок до кривої зв'язування friend.tech, щоб користувачі могли налаштувати напрямок кривої зв'язування, наприклад, реалізувати Після того, як повальне захоплення торговими ключами закінчиться і спекулянти підуть, крива зв'язування буде згладжена, вхідний бар'єр для справжніх фанатів буде знижений, а реальний трафік приватних доменів зросте. Або дозвольте смарт-контракту отримати ончейн/офчейн соціальний граф користувача та мати можливість стежити за своїми друзями в різних соціальних децентралізаціях одним клацанням миші. Або ви можете створити приватний клуб у мережі, наприклад, Degen club, і входити можуть лише адреси, які відповідають історичним умовам споживання газу тощо.

4.5 Ігри

У традиційних іграх Web2 дані користувачів є дуже важливим параметром. Поведінка покупок, стиль гри та внесок можуть зробити гру краще управляється та забезпечити кращий досвід користувача, як, наприклад, механізм співставлення ELO в іграх MOBA. Частота покупок скинів і т. д., але ці дані складно захопити за допомогою смарт-контрактів на блокчейні, тому їх можна замінити лише централізованими рішеннями або просто покинути. Однак поява ZK копроцесора робить можливими децентралізовані рішення.

5. Проектна Вечірка

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

5.1 Аксіома

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

Для виконання цих запитів, Axiom виконує наступні три кроки:

1. Axiom використовує ZK-докази для довіри до читання даних з блок-заголовків, статусу, транзакцій та квитанцій історичних блоків Ethereum. Оскільки всі дані Ethereum on-chain закодовані у цих форматах, Axiom може отримати доступ до всього, до чого мають доступ архівні вузли. Axiom перевіряє всі вхідні дані до ZK-копроцесора за допомогою ZK-доказів потрійних Merkle-Patricia та хеш-ланцюжків блок-заголовків. Хоча цей підхід є складнішим для розробки, він надає найкращу безпеку та вартість для кінцевих користувачів, оскільки забезпечує, що всі результати, повернені Axiom, криптографічно еквівалентні обчисленням on-chain, виконаним у EVM.
2. розрахунок: Після впровадження даних Axiom застосовує перевірені обчислення. Розробники можуть вказати свою логіку обчислень у JavaScript-інтерфейсі, а валідність кожного обчислення перевіряється у ZK-доведенні. Розробники можуть відвідати AxiomREPL або переглянути документацію, щоб дізнатися про доступні обчислювальні примітиви. Axiom дозволяє користувачам отримувати доступ до даних on-chain та вказувати свої власні розрахунки через eDSL. Також вона дозволяє користувачам писати свої власні схеми, використовуючи бібліотеку ZK схем.
3. перевірити: Axiom забезпечує докази правомірності ZK для кожного результату запиту. Ці докази забезпечують, що (1) вхідні дані були правильно витягнуті з ланцюжка та (2) обчислення були правильно застосовані. Ці ZK-докази перевіряються на ланцюжку в смарт-контрактах Axiom, що забезпечує надійне використання кінцевих результатів у смарт-контрактах користувачів.

Оскільки результати перевіряються за допомогою доказів ZK, результати Axiom криптографічно так само безпечні, як і результати Ethereum. Цей підхід не робить жодних припущень щодо криптоекономіки, стимулів або теорії ігор. Axiom вважає, що цей підхід надасть найвищий рівень запевнення для додатків з розумними контрактами. Команда Axiom тісно співпрацювала з Фондом Uniswap та отримала Гранти Uniswap, і побудує довірчий оракул на Uniswap.

5.2 Нульовий ризик

Bonsai: У 2023 році RISC Zero випустила Bonsai, сервіс доказів, який дозволяє on-chain та off-chain додаткам запитувати та отримувати докази zkVM. Bonsai є універсальним сервісом доказів нульового знання, що дозволяє будь-якому ланцюжку, будь-якому протоколу та будь-якому додатку використовувати ZK-докази. Він є високопаралельним, програмованим та високопродуктивним.

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

zkVM є основою Bonsai та підтримує широку сумісність мов, підтримуючи доведені коди Rust та, можливо, доведені коди з нульовим знанням будь-якою мовою, скомпільовані до RISC-V (наприклад, C++, Rust, Go тощо). Через рекурсивні доведення, компілятори спеціальних схем, продовження стану та постійні покращення алгоритмів доведення, Bonsai дозволяє будь-кому генерувати високопродуктивні ZK-докази для різних застосувань.

RISC Zero zkVM: RISC Zero zkVM, вперше випущений у квітні 2022 року, може довести правильність виконання довільного коду, дозволяючи розробникам створювати програми ZK на зрілих мовах, таких як Rust і C++. Цей реліз є серйозним проривом у розробці програмного забезпечення ZK: zkVM дає можливість створювати ZK-додатки без побудови схем і використання користувальницьких мов.

Дозволяючи розробникам використовувати Rust і використовувати зрілість екосистеми Rust, zkVM дозволяє розробникам швидко створювати значущі програми ZK, не вимагаючи досвіду в поглибленій математиці чи криптографії.

Ці програми включають:

• JSON: Перевірте вміст запису в файлі JSON, зберігаючи інші дані приватними.
• Де Волдо: Доведіть, що Волдо присутній в файлі JPG, зберігаючи інші частини зображення в таємниці.
• ZK Checkmate: Доведіть, що ви бачили хід до мату, не розкриваючи виграшний хід.
• ZK Proof of Exploit: Доказ те, що ви можете використовувати обліковий запис Ethereum, не розголошуючи вразливість.
• Перевірка підпису ECDSA: Довести правильність підпису ECDSA.

Ці приклади реалізовані за допомогою зрілого програмного екосистему: більшість наборів інструментів Rust доступні з коробки в Risc Zero zkVM. Можливість суміщення з Rust - це нова якість для світу програмного забезпечення ZK: проекти, які можуть зайняти місяці або роки для розробки на інших платформах, можуть бути легко вирішені на платформі RISC Zero.

Крім того, RISC Zero також володіє відмінною продуктивністю. zkVM має прискорення GPU за допомогою CUDA та Metal, і реалізує паралельне доведення великих програм за допомогою продовження.

Раніше Risc Zero отримав $40 млн у раунді фінансування серії A від Galaxy Digital, IOSG, RockawayX, Maven 11, Fenbushi Capital, Delphi Digital, Algaé Ventures, IOBC та інших установ.

5.3 Brevis

Brevis, дочірня компанія Celer Network, спрямовується на захоплення багатоланцюжкових історичних даних. Вона надає смарт-контрактам можливість читати свої повні історичні дані з будь-якого ланцюжка та виконувати комплексні безперечні налаштовані обчислення. На даний момент вона в основному підтримує Ethereum POS. Comos Tendermint та BSC.

Інтерфейс програми: Поточна система Brevis підтримує ефективні та лаконічні ZK-докази, надаючи наступну інформацію з ланцюжка джерел, доведену за допомогою ZK, для децентралізованих додатків (dApp), що підключені до блокчейну:

1. Хеш-блок та пов'язаний статус, транзакція та корінь квитанції будь-якого блоку на джереловій ланці.
2. Значення слота та пов'язані метадані для будь-якого конкретного блоку, контракту, слоту на джереловому ланцюжку.
3. Квитанції про транзакції та пов'язані метадані для будь-якої транзакції у вихідному ланцюжку.
4. Входи транзакції та пов'язані метадані для будь-якої транзакції на джереловому ланцюжку.
5. Будь-яке повідомлення, відправлене будь-якою сутністю на джерелному ланцюжку будь-якій сутності на цільовому ланцюжку.

Огляд архітектури: архітектура Brevis складається з трьох основних частин:

1. мережа ретрансляторів: Вона синхронізує заголовки блоків та інформацію з ланцюжка з різних блокчейнів та пересилає їх у мережу валідаторів для генерації доказів достовірності. Потім вона надсилає перевірену інформацію та пов'язані з нею докази на підключений блокчейн.
2. мережа Prover: Реалізувати схеми для протоколу легкого клієнта кожного блокчейну, оновлення блоків та генерування доказів запитаних значень слотів, транзакцій, квитанцій та інтегрованої логіки застосування. Для мінімізації часу, витрат та вартості верифікації на ланцюжку, мережа доказувачів може агрегувати розподілені докази, згенеровані одночасно. Крім того, вона може використовувати прискорювачі, такі як GPU, FPGA та ASIC, для покращення ефективності.
3. Підключення контрактів валідаторів на блокчейні: Отримання перевірених zk-даних та відповідних доказів, що генеруються мережею валідаторів, а потім подача перевіреної інформації назад до контракту додатка.

Ця інтегрована архітектура дозволяє Brevis забезпечувати високу ефективність та безпеку при наданні перехресних даних та обчислень, дозволяючи розробникам dApp повністю використовувати потенціал блокчейну. З цією модульною архітектурою Brevis може надавати повністю безпечний, гнучкий та ефективний доступ до даних та обчислювальні можливості для смарт-контрактів on-chain на всіх підтримуваних ланцюгах. Це надає зовсім нову парадигму для розробки dApp. У Brevis є широкий спектр використання, таких як DeFi, заснований на даних зв'язки, залучення користувачів on-chain, zkDID, абстракція соціального облікового запису тощо, що збільшує міжплатформенність даних.

5.4 Лангранж

Langrange та Brevis мають подібну візію, спрямовану на покращення міжопераційності між кількома ланцюжками за допомогою ZK Big Data Stack, який може створювати універсальні докази стану на всіх основних блокчейнах. Інтегруючись з протоколом Langrange, додатки можуть надсилати узагальнені докази стану багато-ланцюжкової системи, які потім можуть бути перевірені неінтерактивно контрактами на інших ланцюжках.

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

Протокол Лангранж спочатку буде сумісний з усіма L1 та L2 rollups, сумісними з EVM. Крім того, Лангранж також планує підтримку несумісних з EVM ланцюгів у найближчому майбутньому, включаючи, але не обмежуючись, Solana, Sui, Aptos, та популярні публічні ланцюги на основі Cosmos SDK.

Відмінність протоколу Langrange від традиційних протоколів моста та обміну повідомленнями:

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

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

Таким чином, доведення стану Лангранжа можна розглядати як оптимізацію для ланцюгових зв'язків «багато-до-одного» (n-to-1). У цьому крос-чейн зв'язку децентралізований додаток (DApp) в одному ланцюжку покладається на агрегацію даних про стан у реальному часі та історичних даних з кількох інших ланцюгів (n). Ця функція значно розширює функціональність та ефективність DApps, дозволяючи їм агрегувати та аналізувати дані з кількох різних блокчейнів для надання більш глибокої та повної інформації. Цей метод значно відрізняється від традиційного одноланцюгового або одноланцюгового зв'язку та забезпечує ширший потенціал і сферу застосування блокчейн-додатків.

Langrange раніше отримувала інвестиції від 1kx, Maven11, Lattice, CMT Digital та криптовалютного гумі.

5.5 Геродот

Herodotus розроблений для надання розумних контрактів синхронного доступу до даних on-chain з інших рівнів Ethereum. Вони вважають, що доказ зберігання може уніфікувати стан кількох rollups, навіть дозволити синхронні читання між рівнями Ethereum. Просто кажучи, це захоплення даних між головним ланцюжком EVM та rollup. Наразі підтримує ETH mainnet, Starknet, Zksync, OP, Arbitrum та Polygon.

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

Процес генерації доказів зберігання приблизно поділяється на три кроки:

Крок 1: Отримати аккумулятор зберігання заголовка блоку перевірки зобов'язань

• Цей крок полягає в тому, щоб отримати «зобов'язання», яке ми можемо перевірити. Якщо накопичувач ще не містить останнього заголовка блоку, який нам потрібно довести, нам спочатку потрібно довести безперервність ланцюга, щоб переконатися, що ми охоплюємо діапазон блоків, що містять наші цільові дані. Наприклад, якщо дані, які ми хочемо довести, знаходяться в блоці 1 000 001, а смарт-контракт, що зберігається в заголовку блоку, охоплює лише блок 1 000 000, то нам потрібно оновити сховище заголовка.
• Якщо цільовий блок вже знаходиться в аккумуляторі, ви можете перейти безпосередньо до наступного кроку.

Крок 2: Доведіть існування конкретного облікового запису

• Цей крок вимагає створення доказу включення від State Trie, що складається з усіх облікових записів у мережі Ethereum. Корінь стану є важливою частиною отримання хешу зобов'язань блоку, а також є частиною сховища заголовка. Важливо зазначити, що хеш заголовка блоку в акумуляторі може відрізнятися від фактичного хешу блоку, оскільки для ефективності міг бути використаний інший метод хешування.

Крок 3: Доведіть конкретні дані в дереві облікових записів

• На цьому етапі можуть бути згенеровані докази включення для даних, таких як нонси, баланси, корені сховищ, або кодові хеші. Кожен обліковий запис Ethereum має трійку сховищ (Merkle Patricia Tree), яка використовується для збереження даних сховища облікового запису. Якщо дані, які ми хочемо довести, знаходяться в сховищі облікового запису, то нам потрібно згенерувати додаткові докази включення для конкретних точок даних у цьому сховищі.

Після створення всіх необхідних доказів включення та обчислювальних доказів формується повний доказ зберігання. Потім цей доказ надсилається на ланцюг, де він перевіряється на відповідність одному початковому зобов'язанню (такому як блокхеш) або кореню MMR, збереженому в заголовку. Цей процес забезпечує автентичність та цілісність даних, а також підтримує ефективність системи.

Herodotus вже підтримується Geometry, Fabric Ventures, Lambda Class та Starkware.

5.6 HyperOracle

Hyper Oracle спеціально розроблений для програмованих нуль-знаньових оракулів, щоб забезпечити безпеку та децентралізацію блокчейну. За стандартом zkGraph Hyper Oracle робить практичними, перевірними та швидкими фінальні обчислення даних та еквівалентних їм обчислень на ланцюжку. Це надає розробникам зовсім новий спосіб взаємодії з блокчейном.

Вузол zkOracle від Hyper Oracle складається головним чином з двох компонентів: zkPoS та zkWASM.

1. zkPoS: Цей компонент відповідає за отримання заголовка блоку та кореня даних блоку блокчейну Ethereum за допомогою доказу з нульовим відомості (zk), щоб забезпечити вірність консенсусу Ethereum. zkPoS також виступає як зовнішній коло до zkWASM.
2. zkWASM: Він використовує дані, отримані з zkPoS як ключовий ввід для запуску zkGraphs. zkWASM відповідальний за виконання користувацьких карт даних, визначених zkGraphs, та генерування доказів нульового знання для цих операцій. Оператори вузлів zkOracle можуть вибрати кількість zkGraphs, які вони хочуть запустити, яка може бути від одного до всіх розгорнутих zkGraphs. Процес генерування zk-доказів може бути делегований розподіленій мережі довідок.

Результатом zkOracle є дані поза ланцюжком, і розробники можуть використовувати ці дані за стандартом zkGraph від Hyper Oracle. Дані також постачаються з zk-сертифікатами для перевірки валідності даних та обчислень.

Для підтримки безпеки мережі Hyper Oracle потрібен лише один вузол zkOracle. Однак у мережі може існувати кілька вузлів zkOracle, які працюють проти zkPoS і кожного zkGraph. Це дозволяє паралельно генерувати докази zk, значно покращуючи продуктивність. Загалом, Hyper Oracle надає розробникам ефективну та безпечну платформу взаємодії з блокчейном, поєднуючи передову технологію zk та гнучку архітектуру вузлів.

У січні 2023 року Hyper Oracle оголосив, що отримав 3 мільйони доларів США у попередньому раунді фінансування, у якому брали участь разом Dao5, Sequoia China, Foresight Ventures та FutureMoney Group.

5.7 Шлях

Pado - це особливе існування серед ZK співпроцесорів. Інші співпроцесори фокусуються на захопленні даних on-chain, тоді як Pado надає можливість захоплювати дані off-chain, маючи на меті привести всі дані Інтернету в смарт-контракти. Він до певної міри заміщує функцію оракула, забезпечуючи при цьому конфіденційність та усуваючи потребу довіри до зовнішніх джерел даних.

5.8 Порівняння між ZK копроцесором та оракул машини

• Затримка: Оракул асинхронний, тому затримка при доступі до плоских даних триває довше порівняно з ZK копроцесором.
• Вартість: Хоча багато оракулів не потребують обчислювальних доказів і, отже, менш витратні, вони менш безпечні. Зберігання доказів коштує дорожче, але є надійнішим.
• Безпека: Максимальний рівень безпеки передачі даних обмежений рівнем безпеки самого оракулу. У порівнянні, ZK-супроцесор відповідає безпеці ланцюга. Крім того, оракули вразливі до атак маніпулювання через використання позаланцюжкових доказів.

На малюнку нижче показано робочий процес Pado:

Pado використовує криптоноди як внутрішні докази. Для того, щоб зменшити припущення про довіру, команда Pado прийме еволюційну стратегію та поступово вдосконалюватиме децентралізацію сервісу prover. Виконавець бере активну участь у процесі пошуку та обміну даними користувача, доводячи достовірність даних користувача, отриманих із мережевих джерел даних. Унікальність полягає в тому, що Pado використовує MPC-TLS (Transport Layer Secure Multi-Party Computation) і IZK (Interactive Zero-Knowledge Proof), щоб дозволити доказам доводити дані «наосліп». Це означає, що валідатори не можуть бачити жодних оригінальних даних, включаючи публічну та приватну інформацію користувачів. Однак верифікатор все одно може забезпечити походження даних будь-яких переданих даних TLS за допомогою криптографічних методів.

1. MPC-TLS: TLS - це протокол безпеки, який використовується для захисту конфіденційності та цілісності даних в Інтернет-комунікаціях. Коли ви відвідуєте веб-сайт і бачите значок "замка" та "https" в URL-адресі, це означає, що ваш візит захищений за допомогою TLS. MPC-TLS імітує функціональність клієнта TLS, що дозволяє аутентифікатору Pado співпрацювати з клієнтом TLS для виконання наступних завдань:
   Важливо зазначити, що ці операції, пов'язані з TLS, виконуються між клієнтом та перевіряючим через протокол обчислення двох сторін (2PC). Дизайн MPC-TLS ґрунтується на деяких технологіях шифрування, таких як обфускаційна схема (GC), передача забуття (OT), IZK тощо.
   • Встановлення TLS-з'єднання, включаючи розрахунок основного ключа, сеансового ключа та інформації для перевірки.
   • Виконувати запити через канал TLS, включаючи генерацію зашифрованих запитів та розшифрування відповідей сервера.
2. EXC: Інтерактивне доказ нульового знання - це доказ нульового знання, в якому доказувач та перевіряючий можуть взаємодіяти. У протоколі IZK результатом перевірки є прийняття або відхилення твердження доказувача. Порівняно з простими NIZK (наприклад, zk-STARKs або zk-SNARKs), протокол IZK має кілька переваг, таких як висока масштабованість для великих тверджень, низька обчислювальна вартість, відсутність потреби у довіреній підготовці та мінімізоване використання пам'яті.

Pado активно розробляє kyc гачок Uniswap, шукаючи більше даних щодо сценаріїв застосування on-chain, та був обраний в перший пакет програми стипендій Consensys.

6. Перспективи в майбутньому

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

З погляду лише попиту, ZK копроцесор є необхідністю. З погляду лише DEX треку, цей гачок має великий потенціал і може зробити багато речей. Якщо у sushiswap немає гачків, він не зможе конкурувати з uniswap, і це буде дуже його швидко вибачить. Якщо zkcoprocessor не використовується для гачків, газ буде дуже дорогим для розробників і користувачів, оскільки гачки вводять нову логіку і роблять смарт-контракти складнішими, що є контрпродуктивним. Так що наразі використання zk копроцесора є найкращим рішенням. Чи з погляду захоплення даних, чи обчислення, кілька методів мають різні переваги і недоліки. Копроцесор, придатний для конкретних функцій, є хорошим копроцесором. Ринок перевірки обчислень на ланцюжку має широкі перспективи і відобразить нову цінність в більшій кількості галузей.

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

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

7. Індекс

https://blog.axiom.xyz/що-таке-zk-копроцесор/

https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA

https://dev.risczero.com/api

https://blog.uniswap.org/uniswap-v4

https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/

https://lagrange-labs.gitbook.io/lagrange-labs/overview/what-is-the-lagrange-protocol

https://docs.herodotus.dev/herodotus-docs/

https://docs.padolabs.org/

Попередження:

1. Ця стаття перепечатана з [ForesightResearch]. Усі авторські права належать оригінальному автору [Майк]. Якщо є заперечення до цього повторного друку, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно цим займуться.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодних інвестиційних порад.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не вказано інше, копіювання, поширення або плагіатування перекладених статей заборонене.