Оскільки концепція співпроцесорів стала популярною в останні місяці, цей новий варіант використання ZK почав отримувати все більше уваги.

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

1. Що таке співпроцесор, а що ні?

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

Я думаю, що те, що сказав доктор Донг Мо, може бути дуже близьким до стандартної відповіді: прямо кажучи, співпроцесор «надає смарт-контрактам можливість виконувати Dune Analytics».

Як розкласти це речення?

Уявіть собі сценарій, у якому ми використовуємо Dune. Ви хочете зробити LP в Uniswap V3, щоб заробити певну комісію за обробку, тому ви відкриваєте Dune і знаходите нещодавній обсяг торгів різними торговими парами на Uniswap, APR комісії за обробку за останні 7 днів, і основні торгові пари, верхній і нижній діапазони коливань тощо...

Або, можливо, коли StepN став популярним, ви почали спекулювати взуттям і не були впевнені, коли його продати, тому щодня дивилися на дані StepN на Dune, щоденний обсяг транзакцій, кількість нових користувачів, мінімальну ціну взуття… і планували, щоб колись було зростання. Якщо тенденція сповільнюється або йде на спад, біжіть швидко.

Звичайно, ви можете не тільки дивитися на ці дані, але й групи розробників Uniswap і StepN також звертають увагу на ці дані.

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

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

Наприклад, буде запущено «Програму винагороди за лояльність користувачів» на основі тривалості часу, протягом якого користувачі тримають Creation Shoes, щоб надати лояльним користувачам більше розсилок або переваг.

Наприклад, VIP-план, подібний до Cex, можна запустити на основі TVL або обсягу торгів, наданих LP на Uniswap або Trader, що надає трейдеру зниження комісії за транзакцію або збільшення частки комісії LP…

У цей час постає проблема – великі дані великих інтернет-компаній + штучний інтелект – це, по суті, чорний ящик. Вони можуть робити все, що хочуть. Користувачі цього не бачать і їм байдуже.

Але тут, у Web3, прозорість і недовірливість є нашою природною політкоректністю, і ми відкидаємо чорні ящики!

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

Перше призведе вас до «політично некоректних» проблем довіри.

Комісія за газ, згенерована останнім у ланцюжку, буде астрономічною цифрою, і ваш (на стороні проекту) гаманець не зможе собі цього дозволити.

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

Чому його називають «співпроцесором»? Фактично, це походить від «графічного процесора» в історії розвитку Web2.0. Причина, чому графічний процесор був представлений як окреме обчислювальне обладнання та існував незалежно від центрального процесора в той час, полягала в тому, що його архітектура могла обробляти деякі обчислення, які було принципово важко виконувати для центрального процесора, такі як великомасштабні паралельні повторювані обчислення, графіка розрахунки тощо. Саме завдяки цій архітектурі «співпроцесора» ми сьогодні маємо чудові CG-фільми, ігри, моделі штучного інтелекту тощо, тож ця архітектура співпроцесора насправді є стрибком у архітектурі обчислень. Тепер різні групи співпроцесорів також сподіваються ввести цю архітектуру в Web3.0. Блокчейн тут схожий на процесор Web3.0. Незалежно від рівня L1 чи L2, вони за своєю суттю непридатні для таких завдань із «важкими даними» та «складною логікою обчислень», тому для обробки таких обчислень впроваджено блокчейн-співпроцесор, що значно розширює можливості блокчейн-додатків.

Тож те, що робить співпроцесор, можна підсумувати двома речами:

1. Отримати дані з блокчейну та за допомогою ZK довести, що отримані мною дані правдиві та не фальсифіковані;
2. Зробити відповідні розрахунки на основі щойно отриманих мною даних і ще раз за допомогою ZK довести, що обчислені мною результати правдиві й нефальсифіковані. Результати розрахунку смарт-контракт може називати «Low Fee + Trustless».

Деякий час тому у Starkware була популярна концепція під назвою Storage Proof, яка також називається State Proof. В основному він виконує крок 1, представлений Геродотом, Лангражем тощо. Технічна спрямованість багатьох перехресних ланцюгових мостів на основі технології ZK також знаходиться на кроці 1. 1 далі.

Співпроцесор — це не що інше, як крок 1, за яким слідує крок 2. Після вилучення даних без довіри виконайте обчислення без довіри, і все.

Тому, щоб використовувати відносно технічний термін для точного опису, співпроцесор має бути надмножиною Storage Proof/State Proof і підмножиною Verfiable Computation.

Слід зазначити, що співпроцесор не є Rollup.

Технічно кажучи, ZK-доказ Rollup подібний до кроку 2 вище, а процес кроку 1 «отримання даних» реалізується безпосередньо через Sequencer. Навіть децентралізований секвенсор використовує лише якийсь механізм конкуренції або консенсусу для досягнення цього. Візьміть замість Storage Proof цю форму ЗК. Більш важливим є те, що на додаток до рівня обчислень, ZK Rollup також має реалізувати рівень зберігання, подібний до блокчейну L1. Це сховище є постійним, тоді як ZK Coprocessor «без стану». Після завершення обчислення статус «Усі» не зберігається.

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

2. Чому я повинен використовувати ЗК? Чи можна використовувати OP?

Після прочитання вищесказаного у вас можуть виникнути сумніви, чи потрібно використовувати ZK як співпроцесор? Це дуже нагадує «Графік із доданим ZK», і, схоже, у нас немає «великих сумнівів» щодо результатів Графіка.

Це тому, що коли ви використовуєте Graph, реальні гроші в основному не задіяні. Ці індекси обслуговують послуги поза мережею. У зовнішньому інтерфейсі користувача ви бачите обсяг транзакцій, історію транзакцій тощо. Дані можуть надаватися через кілька постачальників індексів даних, таких як Graph, Alchemy, Zettablock тощо, але ці дані не можна вставити назад у смарт-контракт, тому що як тільки ви вставите їх назад, ви додасте додаткову довіру до служби індексування. Коли дані пов’язані з реальними грошима, особливо великими обсягами TVL, ця додаткова довіра стає важливою. Уявіть, що наступного разу, коли друг попросить вас позичити 100 юанів, ви можете просто позичити їх, не моргнувши оком. Так, а якщо я попрошу вас позичити 10 000 юанів або навіть 1 мільйон юанів?

Але знову ж таки, чи дійсно ми повинні використовувати ZK для спільної обробки всіх вищезазначених сценаріїв? Адже у нас в Rollup є два технічні маршрути, ОП і ЗК. Останнім часом популярний ZKML також має концепцію OPML відповідних маршрутів розгалужень. Запитали, чи має співпроцесор також гілку OP, наприклад OP-Coprocessor?

Насправді, це дійсно так, але наразі ми зберігаємо конкретні деталі в таємниці, а незабаром опублікуємо більш детальну інформацію.

3. Який співпроцесор найкращий - Порівняння кількох поширених технічних рішень співпроцесорів на ринку

Бревіс

Архітектура Brevis складається з трьох компонентів: zkFabric, zkQueryNet і zkAggregatorRollup.

Нижче наведено діаграму архітектури Brevis:

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

zkQueryNet: відкритий ринок механізму запитів ZK, який приймає запити даних від dApps і обробляє їх. Запити даних обробляють ці запити за допомогою перевірених заголовків блоків із zkFabric і генерують докази запитів ZK. Ці механізми мають як вузькоспеціалізовані функції, так і загальні мови запитів для задоволення потреб різних програм.

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

ZK Fabric є ключовою частиною генерації доказів для заголовка блоку. Дуже важливо забезпечити безпеку цієї частини. Нижче наведено діаграму архітектури zkFabric:

Легкий клієнт zkFabric, заснований на захисті від нульового знання (ZKP), робить його повністю ненадійним, не покладаючись на будь-яку зовнішню перевірку. Немає необхідності покладатися на будь-який зовнішній орган перевірки, оскільки його безпека повністю залежить від базового блокчейну та математично надійних доказів.

Мережа zkFabric Prover реалізує схеми для протоколу lightclient кожного блокчейну, а мережа генерує докази дійсності для заголовків блоків. Пристрої перевірки можуть використовувати такі прискорювачі, як графічні процесори, FPGA та ASIC, щоб мінімізувати час і вартість перевірки.

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

Розподіл перевірників: Мережа перевірок — це децентралізована мережа перевірок ZKP, яка вибирає перевірку для кожного завдання створення перевірки та сплачує винагороду цим перевіркам.

Поточне розгортання:

Легкі клієнтські протоколи, які зараз реалізовані для різних блокчейнів, включаючи Ethereum PoS, Cosmos Tendermint і BNB Chain, служать прикладами та доказами концепцій.

Наразі Brevis співпрацює з хуком uniswap, який значно додає власні пули uniswap. Однак, порівняно з CEX, UnisWap все ще не має ефективних можливостей обробки даних для створення проектів, які покладаються на великі дані транзакцій користувачів (наприклад, програми лояльності на основі обсягу транзакцій). функція.

За допомогою Brevis Хук вирішив проблему. Хуки тепер можуть зчитувати повні дані ланцюжка історії користувача або LP і виконувати настроювані обчислення абсолютно ненадійним способом.

Геродот

Herodotus — це потужне проміжне програмне забезпечення для доступу до даних, яке забезпечує смарт-контракти з такими функціями для синхронного доступу до поточних і історичних даних у ланцюжку на рівні Ethereum:

1. Стани L1 з L2s
2. Стани L2 як з L1, так і з інших L2
3. L3/App-Chain переходить у L2 та L1

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

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

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

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

Доказом зберігання, як визначено Геродотом, є злиття:

1. Докази збереження: ці докази підтверджують існування певних даних у криптографічній структурі даних (наприклад, дерево Меркла або дерево Меркле Патриції), гарантуючи, що ці дані справді присутні в наборі даних.
2. Обчислювальне підтвердження: Перевірте виконання багатоетапного робочого процесу, підтверджуючи дійсність одного або кількох елементів у широкому наборі даних, наприклад у всьому блокчейні Ethereum або агрегаті. Крім вказівки на наявність даних, вони також перевіряють перетворення або операції, застосовані до цих даних.
3. Докази з нульовим знанням: спростіть кількість даних, з якими повинні взаємодіяти смарт-контракти. Докази з нульовим знанням дозволяють смарт-контрактам підтверджувати дійсність заяви без обробки всіх базових даних.

робочий процес

1. Отримати хеш блоку

Кожні дані в блокчейні належать до певного блоку. Хеш блоку служить унікальним ідентифікатором блоку та підсумовує весь його вміст через заголовок блоку. У робочому процесі підтвердження зберігання нам спочатку потрібно визначити та перевірити хеш блоку, що містить дані, які нас цікавлять. Це перший крок у всьому процесі.

2. Отримати заголовок блоку

Після отримання відповідного хешу блоку наступним кроком є доступ до заголовка блоку. Для цього потрібно хешувати заголовок блоку, пов’язаний із хешем блоку, отриманим на попередньому кроці. Потім хеш наданого заголовка блоку порівнюється з отриманим хешем блоку:

Є два способи отримати хеш:

1. Для отримання використовуйте код операції BLOCKHASH
2. Запитуйте хеш блоків, які були перевірені в історії, з накопичувача хешів блоків

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

3. Визначте потрібні корені (за бажанням)

Маючи під рукою заголовок блоку, ми можемо заглибитися в його вміст, зокрема:

stateRoot: криптографічний дайджест усього стану блокчейну на момент виникнення блокчейну.

receiptsRoot: зашифрований дайджест усіх результатів транзакцій (квитанцій) у блоці.

TransactionsRoot: криптографічний дайджест усіх транзакцій, які відбулися в блоці.

можна декодувати, дозволяючи перевірити, чи включено певний рахунок, квитанцію чи транзакцію до блоку.

4. Перевірте дані щодо вибраного кореня (необов’язково)

З вибраним нами коренем і враховуючи, що Ethereum використовує структуру Merkle-Patricia Trie, ми можемо використати підтвердження включення Merkle, щоб перевірити, що дані існують у дереві. Етапи перевірки залежать від даних і глибини даних у блоці.

Наразі підтримувані мережі:

1. Від Ethereum до Starknet
2. Від Ethereum Goerli до Starknet Goerli
3. Від Ethereum Goerli до zkSync Era Goerli

Аксіома

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

Axiom нещодавно випустила Halo2-repl, веб-переглядач halo2 REPL, написаний на Javascript. Це дозволяє розробникам писати схеми ZK, використовуючи лише стандартний Javascript, без необхідності вивчати нову мову, як-от Rust, установлювати перевірочні бібліотеки чи мати справу з залежностями.

Axiom складається з двох основних технологічних компонентів:

1. AxiomV1 — кеш блокчейну Ethereum, починаючи з Genesis.
2. AxiomV1Query — розумний контракт, який виконує запити до AxiomV1.

Кешування хешів блоків в AxiomV1:

Смарт-контракти AxiomV1 кешують хеші блоків Ethereum, починаючи з блоку genesis, у двох формах:

По-перше, кешується корінь Keccak Merkle 1024 послідовних хешів блоку. Ці корені Merkle оновлюються за допомогою доказів ZK, які підтверджують, що хеш заголовка блоку утворює ланцюжок зобов’язань, що закінчується одним із останніх 256 блоків, доступних безпосередньо для EVM, або хешем блоку, який уже існує в кеші AxiomV1.

По-друге, Axiom зберігає гірський хребет Меркла цих коренів Меркле, починаючи з блоку генезису. Гірський хребет Меркле побудовано на ланцюжку шляхом оновлення першої частини кеша, кореня Keccak Merkle.

Виконайте запит у AxiomV1Query:

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

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

Nexus

Nexus намагається використовувати докази з нульовим знанням, щоб створити універсальну платформу для хмарних обчислень, які можна перевірити. Наразі він не залежить від архітектури машини та підтримує risc 5/WebAssembly/EVM. Nexus використовує систему доказів наднової. Команда перевірила, що пам’ять, необхідна для створення доказу, становить 6 ГБ. У майбутньому його буде оптимізовано на цій основі, щоб звичайні клієнтські комп’ютери могли генерувати докази.

Якщо бути точним, то архітектура ділиться на дві частини:

1. Nexus zero: децентралізована хмарна обчислювальна мережа, що піддається перевірці, на базі доказів із нульовим знанням і універсальної віртуальної машини zkVM.
2. Nexus: децентралізована мережа хмарних обчислень, що піддається верифікації, на базі багатосторонніх обчислень, реплікації кінцевого автомата та універсальної віртуальної машини WASM.

Програми Nexus і Nexus Zero можна писати на традиційних мовах програмування, наразі підтримуючи Rust, з’являться інші мови.

Програми Nexus працюють у децентралізованій мережі хмарних обчислень, яка, по суті, є «безсерверним блокчейном» загального призначення, підключеним безпосередньо до Ethereum. Таким чином, програми Nexus не успадковують безпеку Ethereum, але взамін отримують доступ до вищої обчислювальної потужності (такої як обчислення, сховище та керований подіями введення/виведення) завдяки зменшеному розміру мережі. Програми Nexus працюють у виділеній хмарі, яка досягає внутрішнього консенсусу та надає перевірені «докази» обчислень (а не правдиві докази) за допомогою перевірених мережевих порогових підписів у Ethereum.

Програми Nexus Zero дійсно успадковують безпеку Ethereum, оскільки це універсальні програми з доказами нульового знання, які можна перевірити в ланцюжку на еліптичній кривій BN-254.

Оскільки Nexus може запускати будь-який детермінований двійковий файл WASM у реплікованому середовищі, очікується, що його використовуватимуть як джерело доказу дійсності/розпорошеності/відмовостійкості для згенерованих програм, у тому числі секвенсорів zk-rollup, оптимістичних секвенсорів зведень та інших серверів доказів, як-от сама zkVM Nexus Zero.

Відмова від відповідальності:

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