1. Що таке супроцесор і що не є ним?

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

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

Як розібрати це речення?

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

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

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

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

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

Наприклад, на основі тривалості користування користувачами взуттям Chuangshi буде запущена програма "Програма винагороди за лояльність користувачів", щоб надавати відданим користувачам більше повітряних крапель або переваг.

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

……

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

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

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

Перший може залишити вас з "політично некоректними" проблемами довіри.

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

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

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

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

1. Отримати дані з блокчейну та довести через ZK, що отримані мною дані є правдивими та не підробленими;
2. Здійсніть відповідні обчислення на основі даних, які я щойно отримав, і ще раз використовуйте ZK, щоб довести, що результати, які я розрахував, є правдивими і не піддавалися фальсифікації. Результати обчислень можуть бути викликані смарт-контрактом «Низька комісія + Відсутність необхідності в довірі».

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

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

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

Одне з важливих моментів - це те, що копроцесор не є Rollup.

Технічно кажучи, доказ ZK Rollup схожий на крок 2 вище, і процес кроку 1 "отримання даних" безпосередньо реалізовується через Послідовник. Навіть децентралізований Послідовник використовує якийсь вид змагання або механізму консенсусу. Він приймає його замість доказу зберігання у формі ZK. Що є ще важливішим, крім обчислювального рівня, ZK Rollup також повинен реалізувати рівень зберігання схожий на L1 блокчейн. Це зберігання постійне, тоді як ZK Coprocessor є "безстаничним". Після завершення обчислень жоден статус не залишається.

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

2. Чому вам потрібно використовувати ZK? Чи можна використовувати OP?

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

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

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

Фактично, таке є - але ми зараз тримаємо конкретні деталі в таємниці, і скоро ми оприлюднимо більше детальної інформації.

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

1. Коротко:

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

Наступне - це схема архітектури Brevis:

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

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

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

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

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

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

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

Розподіл Prover: мережа доведення - децентралізована мережа доведення ЗПД, яка вибирає доведення для кожного завдання генерації доказу та оплачує винагороду цим доведенням.

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

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

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

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

1. Геродот

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

L1 становиться з L2s

Стани L2 як від L1, так і від інших L2

Стани L3/App-Chain для L2 та L1

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

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

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

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

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

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

Послідовність дій :

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

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

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

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

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

(1) Використовуйте опкод BLOCKHASH, щоб отримати

(2) Запитайте хеші блоків, які були перевірені в історії, з блок-акумулятора хешів

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

1. Визначте необхідні корені (необов'язково)

З наявним заголовком блоку, ми можемо заглибитися у його вміст, зокрема:

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

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

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

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

1. Перевірте дані на відповідність вибраному кореню (необов'язково)

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

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

Від Ethereum до Starknet

З Ethereum Goerliна Starknet Goerli

З Ethereum Goerliдо zkSync Era Goerli

1. Аксіома

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

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

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

AxiomV1 — кеш Ethereum блокчейну, починаючи з Genesis.

AxiomV1Query — Смарт-контракт, який виконує запити до AxiomV1.

(1) Значення хеш-блоку кешу в AxiomV1:

Смарт-контракт AxiomV1 кешує хеші блоків Ethereum з часу блоку генезису у двох формах:

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

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

(2) Виконайте запит в AxiomV1Query:

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

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

1. Nexus

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

Будьте точними, архітектура поділена на дві частини:

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

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

Додатки Nexus та Nexus Zero можна писати традиційними мовами програмування, наразі підтримують Rust, а в майбутньому буде підтримка ще більшої кількості мов.

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

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

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

Disclaimer：

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