Чому кажуть, що ZK - це кінцева гра?

Історичне тло коопроцесора

У традиційній галузі обчислювальної техніки супроцесор - це обчислювальний блок, відповідальний за обробку різних складних завдань для ЦП. Супроцесори є дуже поширеними в галузі обчислювальної техніки, наприклад, в 2013 році Apple представила супроцесор M7, який значно підвищив чутливість руху для розумних пристроїв. Відомий всім графічний прискорювач GPU був представлений компанією Nvidia в 2007 році і відповідає за обробку графічного рендерингу та інших завдань для ЦП. GPU прискорює роботу програм, що виконуються на ЦП, відвантажуючи обчислювально інтенсивний та часоємкий код, ця архітектура відома як “гетерогенний” / “змішаний” розрахунок.

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

На ланцюжку Ethereum є дві серйозні проблеми, які перешкоджають розвитку додатків:

1. У зв’язку з високим Комісія за газ, необхідним для роботи, звичайна передача жорстко закодована як 21000 Gas Limit, що показує нижню лінію Комісія за газ мережі Ethereum, а інші операції, включаючи зберігання, коштуватимуть дорожче лонг Gas, що обмежить сферу розробки у блокчейні додатків, лонг та велика кількість кодів контрактів пишуться лише навколо операцій з активами, і як тільки справа доходить до складних операцій, буде потрібно велика кількість Gas, що є «Масовим прийняттям» для додатків та користувачів є серйозною перешкодою.
2. Оскільки смарт-контракти існують в межах віртуальної машини, насправді вони можуть отримати доступ лише до даних останніх 256 блоків. Особливо після оновлення Pectra, яке вводить пропозицію EIP-4444, повні вузли більше не будуть зберігати дані минулих блоків. Це призводить до втрати даних і затримує з’явлення інноваційних додатків, які базуються на даних. Зрештою, популярні додатки, такі як TikTok, Instagram, додатки DeFi з багатою кількістю даних, LLM та інші, побудовані на основі даних. Саме тому ми випустили протокол Layer3 Momoka, який базується на даних. Ми вважаємо, що блокчейн - це дуже плавний потік даних, оскільки усі дані на ланцюжку є відкритими та прозорими. Проте, насправді все не так. Відсутність належної інфраструктури заважає потоку даних, що обмежує появу продуктів «Mass Adoption».

Ми виявили, що обмеженням появи нового обчислювального парадигми «Mass Adoption» є обчислення та дані. Однак це є недоліком самої блокчейн-платформи Ethereum, яка з самого початку не була розроблена для обробки великого обсягу обчислень та завдань з великою кількістю даних. Але як досягти сумісності з цими обчисленнями та завданнями з великою кількістю даних? Ось тут з’являється поняття сумісної обробки, де сама ланцюг Ethereum виступає як процесор, а сумісна обробка схожа на графічний процесор. Ланцюг може обробляти деякі некомп’ютерні активи та прості операції з даними, але додатки, які хочуть гнучко використовувати дані або обчислювальні ресурси, можуть використовувати сумісну обробку. З розвитком технології ZK для забезпечення надійної обробки та використання даних сумісної обробки в позаблокчейній мережі, більшість сумісних обробників розроблені на основі ZK.

Щодо ZK Coporcessor, його використання охоплює широкий спектр сценаріїв застосування для будь-якої реальної сфери додатків dapp, таких як соціальні мережі, ігри, Defi-конструктори, системи контролю ризиків на основі даних у блокчейні, Oracle, зберігання даних, навчання мовою великих моделей та розуміння і так далі. Теоретично, будь-яке застосування Web2 може бути реалізовано з використанням ZK пристрою обробки, при цьому Ethereum виступає як остаточний шар розрахунків, що забезпечує безпеку додатку.

У традиційному світі термін «супроцесор» також не має чіткого визначення, будь-який окремий чіп, що може служити як допоміжний для виконання завдань, називають супроцесором. Внутрішня галузь має різні визначення ZK-супроцесора, такі як ZK-Query, ZK-Oracle, ZKM, які можуть допомагати запитувати повні дані на ланцюжку, надійні дані поза ланцюжком та результати обчислень поза ланцюжком. З цього визначення видно, що насправді шар 2 також може вважатися супроцесором Ethereum. У наступних розділах ми також порівняємо подібності та відмінності між шаром 2 та загальним ZK-супроцесором.

Огляд проектів співпроцесора

Деякі проекти зі співпроцесором ZK, джерело зображення: Gate Ventures

Наразі відомі три головні складові у галузі обробки у зовнішньому середовищі, а саме індексування даних у блокчейні, оракули та ZKML, причому проект General-ZKM охоплює всі три сценарії. Віртуальні машини, що працюють поза блокчейном, мають свої особливості: Delphinus сконцентрована на zkWASM, тоді як Risc Zero спеціалізується на архітектурі Risc-V.

Архітектура технології супроцесора

Ми на прикладі загального процесора ZK проаналізуємо його архітектуру, щоб читачі зрозуміли відмінності у технології та механізмі дизайну цієї універсальної віртуальної машини, щоб визначити тенденції в розвитку майбутніх процесорів, зокрема, зосередиться на аналізі трьох проектів: Risc Zero, Lagrange та Succinct.

Risc Zero

У Risc Zero його криптографічний процесор називається Bonsai.

Архітектура Bonsai, джерело: Risc Zero

Компоненти Bonsai, джерело зображення: Risc Zero

У Bonsai було побудовано повний набір компонентів, пов’язаних з незалежним від ланцюга доказом знання. Його метою є стати незалежним від ланцюга копроцесором, заснованим на архітектурі набору інструкцій Risc-V, з високою універсальністю і підтримкою мов, включаючи Rust, C++, Solidity, Go тощо. Основні функції включають:

1. Загальний zkVM, який може виконувати будь-яку віртуальну машину в середовищі нульового знання/перевірки.
2. Система генерування доказів ZK, яку можна безпосередньо інтегрувати в будь-який смарт-контракт або ланцюг
3. Універсальний rollup, який розподіляє будь-який обчислення, підтверджене на Bonsai, на ланцюг, щоб мережеві майнери могли здійснювати підтвердження.

Складові його включають:

1. Мережа підтверджувачів: За допомогою API Bonsai підтверджувачі отримують ZK-код, який потрібно перевірити в мережі, потім вони виконують алгоритм доведення, щоб згенерувати ZK-доведення. Ця мережа в майбутньому буде відкрита для всіх.
2. Request Pool: Цей пул є сховищем запитів на підтвердження, що ініціюють користувачі (схоже на мемпул Ethereum, призначений для тимчасового зберігання транзакцій), після чого цей Request Pool буде відсортований Sequencer, згенерувати блок, в якому багато запитів на підтвердження будуть розбиті для підвищення ефективності підтвердження.
3. Rollup Engine: Цей механізм збирає результати доказів, зібрані в мережі доказів, а потім упаковує їх у Root Proof і завантажує в Ethereum Основна мережа, щоб у блокчейні валідатори перевірили в будь-який час.
4. Image Hub: це візуальна платформа для розробників, де можна зберігати функції та повні програми, тому розробники можуть викликати відповідні API через розумний контракт, що надає ланцюгу розумних контрактів можливість викликати програми поза блокчейном.
5. State Store: Bonsai також вводить зберігання стану поза блокчейном, де вони зберігаються як пари ключ-значення в базі даних. Це дозволяє зменшити витрати на зберігання на блокчейні та зменшити складність смартконтрактів за допомогою платформи ImageHub.
6. Ринок підтвердження: Верхній та середній рівні ZK-ланцюга доведення, ринок обчислювальної потужності використовується для забезпечення взаємозв’язку між сторонами, що надають обчислювальну потужність та сторонами, що її шукають.

Лагранж

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

Це стосується двох функцій:

1. Перевірена база даних: за допомогою індексації сховища розумного контракту на ланцюжку, стан, створений розумним контрактом на ланцюжку, зберігається у базі даних. По суті, це перебудова зберігання, стану та блоку ланцюжка, а потім зберігається у ланцюжку бази даних поза блокчейном для зручного пошуку.
2. Обчислення за принципом MapReduce: принцип MapReduce полягає в тому, що на великій базі даних використовується паралельне обчислення з розділенням даних по багатьом екземплярам, після чого результати об’єднуються разом. Ця архітектура, яка підтримує паралельне виконання, була названа Лагранжем zkMR.

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

Структура бази даних Лагранж, джерело зображення: Лагранж

Це структура відображення даних, які зберігаються у контракті. Тут зберігаються змінні стану контракту, і кожен контракт має власний Storage Trie, який зберігається у вигляді дерева MPT в Ethereum. Дерево MPT, хоча й просте, має низьку ефективність, і саме це стало причиною розробки розробниками Ethereum якості Verkel. У Lagrange кожен вузол може використовувати докази SNARK/STARK, а батьківський вузол містить докази дочірніх вузлів, що потребує використання техніки рекурсивних доказів.

статус рахунку, джерело: Лагранж

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

Структура блока даних, джерело інформації: Лагранж

Lagrange в новій структурі даних створив структуру даних блоку, яка є дружньою до доведення SNARKs, де кожне листя цього дерева є заголовком блоку, розмір цього дерева фіксований, якщо Ethereum генерує блоки кожні 12 секунд, то ця база даних може бути використана протягом близько 25 років.

У віртуальній машині ZKMR в Lagrange обчислення складається з двох кроків:

1. Map：розподілена машина відображає всі дані, щоб створити пари ключ-значення.
2. Зменшити: розподілений комп’ютер обчислює докази окремо, а потім всі докази об’єднуються.

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

Процес роботи копроцесора Лагранжа, джерело зображення: Лагранж

Ось його процес виконання:

1. Розробник реєструє свій смарт-контракт на платформі Lagrange, а потім подає запит на підтвердження свого смарт-контракту на ланцюгу Lagrange, при цьому контракт агента відповідає за взаємодію з контрактом розробника.
2. Lagrange поза блокчейном шляхом розкладає запит на паралельні завдання та розподіляє їх між різними підтверджувачами для спільної перевірки.
3. Цей доказувач фактично є мережею, безпека якої забезпечується технологією Restaking від EigenLayer.

Лаконічний

Мета Succinct Network - інтегрувати програмовані факти в кожну частину стеку розробки блокчейну (включаючи L2, копроцесор, кросчейн міст тощо).

Процес роботи Succinct, джерело зображення: Succinct

Succinct може приймати спеціалізовані мови програмування (DSL), такі як Solidity та нуль-знань, передавати їх на позаблокчейновий копроцесор Succinct, виконувати індексацію даних цільового ланцюжка, а потім надсилати запити на підтвердження на ринок підтверджень. Це дозволяє майнерам з CPU, GPU та іншими чіпами, такими як ETC, надсилати підтвердження в мережу підтверджень. Його особливість полягає в тому, що ринок підтверджень сумісний з будь-якою системою підтверджень, оскільки майбутнє передбачає тривалий період співіснування різних систем підтвердження.

Ланцюжок ZKVM Succinct, відомий як SP (Succinct Processor), може підтримувати мову Rust та інші мови LLVM поза блокчейном, його основні особливості включають:

1. Рекурсія + перевірка: на основі технології STARKs рекурсивна доказова техніка може експоненційно підвищити ефективність стиснення ZK.
2. Підтримка упаковувача SNARKs до STARKs: здатність одночасно використовувати переваги SNARKs та STARKs, щоб вирішити проблему компромісу між розміром доведення та часом перевірки.
3. Архітектура zkVM, орієнтована на попередню компіляцію: для деяких загальних алгоритмів, таких як SHA256, Keccak, ECDSA та інші, можливе попереднє компілювання для скорочення часу генерації та перевірки доказів під час виконання.

Порівняння

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

1. Проблема індексування/синхронізації даних: Тільки повні у блокчейні дані та функції синхронного індексування можуть задовольнити вимоги додатків на основі великих даних, в іншому випадку сфера їх застосування відносно проста.
2. На основі технологій: технології SNARKs та STARKs мають різні точки вибору, протягом середньострокового періоду використовується переважно технологія SNARKs, а в довгостроковій перспективі - технологія STARKs.
3. Чи підтримується рекурсія: лише з підтримкою рекурсії можна більш ефективно стиснути дані та реалізувати паралельні доведення обчислень, тому повна реалізація рекурсії є технічною визначною рисою проекту.
4. Система доведення: система доведення безпосередньо впливає на розмір та час генерації доведення, це є найважливішим аспектом вартості ZK технології, наразі головним чином використовується власний ринок обчислювальної потужності та мережа доведення.
5. Екологічне співробітництво: можна визначити, чи технічний напрямок є прийнятним користувачами B-платформи через реальний попит третьої сторони.
6. Підтримувані VC та фінансування: можливо, це може вказувати на подальшу підтримку ресурсів.

Джерело зображення: Gate Ventures

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

Відмінності та схожості між ко-процесором та Layer2

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

1. У якості компонента ланцюга ZK Layer2 поза блокчейном ці шари Layer2 можуть замінити свою віртуальну машину на ко-процесор.
2. Як додаток на громадському ланцюзі розгружати обчислювальну потужність на позаблокчейновий супроцесор.
3. Як оракул-машина, яка отримує дані, що можна перевірити на інших ланцюгах, на додатку громадського ланцюга.
4. Як міст між двома ланцюгами для передачі повідомлень.

Ці сценарії застосування є лише частиною, для копроцесора нам потрібно розуміти його потенціал у реальному часі синхронізації даних по всьому ланцюжку та високої продуктивності, низькі витрати на надійні обчислення, можливість безпечного перебудови майже всіх проміжних програмних засобів блокчейну за допомогою копроцесора. Включаючи Chainlink, The Graph також розробляють свою власну ZK-оракул-машину та запити; а також провідні містки міжланцюжкового зв’язку, такі як Wormhole, Layerzero, розробляють технологію міжланцюжкового зв’язку на основі ZK; навчання та надійний міркування з використанням LLM (великі модельні оракули) та інше.

Проблеми, з якими стикаються співпроцесори

1. Розробників стримує опір, ZK-технологія в теорії можлива, але наразі існує багато технічних труднощів, зовнішнє розуміння також складне, тому коли нові розробники приєднуються до екосистеми, через необхідність володіти певною мовою та інструментами розробника, це може бути значним опором.
2. Трек знаходиться в дуже ранній стадії, продуктивність zkVM дуже складна і включає багато аспектів (включаючи апаратне забезпечення, продуктивність одного вузла та багатовузлову, використання пам’яті, вартість рекурсії, вибір хеш-функції та інші фактори), наразі в кожному аспекті є проекти в стадії розробки, трек знаходиться в дуже ранній стадії, картина ще неясна.
3. Попередні умови, такі як апаратне забезпечення, все ще не втілилися на практиці. З апаратної точки зору, наразі основними є ASIC та FPGA, виробники включають Ingonyama, Cysic та інші, але вони все ще знаходяться на етапі експериментів і не впроваджені в комерційну діяльність. Ми вважаємо, що апаратне забезпечення - це передумова широкого впровадження технології ZK.
4. Технічний шлях схожий, важко мати технічне перевагу наступного покоління, зараз головним чинником є ресурси VC та здатність команди з BD, щоб здобути позицію в екосистемі основних додатків та громадських ланцюгів.

Загальний висновок та перспективи

ZK технологія має велику універсальність, вона також допомагає екосистемі Ethereum з орієнтації на децентралізацію перейти до орієнтації на довіру. “Не довіряй, перевіряй”, це найкраща практика ZK технології. ZK технологія може перебудувати кросчейн мости, оракул-машини, запити на ланцюгу, обчислення поза ланцюгом, віртуальні машини та багато інших сценаріїв застосування, а універсальний ZK Coprocessor є одним з інструментів для втілення ZK технології. Щодо ZK Coporcessor, його застосування має широкі межі, і може охопити будь-який реальний сценарій застосування dapp, теоретично будь-яке застосування Web2, що можливе, може бути реалізоване за допомогою ZK копроцесора.

Крива поширення технологій, джерело зображення: Gartner

Здавна технічний прогрес відстає від уявлень людей про прекрасне життя (наприклад, від Чанъэ до Аполлона), якщо щось справді інноваційне, перевертаюче та необхідне, то техніка обов’язково це здійснить, лише питання часу. Ми вважаємо, що загальний ZK-процесор слідує цьому тенденції розвитку. У нас є два показники «Масового прийняття» ZK-процесора: реальний доказ в ланцюжку та низькі витрати поза ланцюжком. Якщо обсяг даних достатній, існує реальний час синхронізації та низькі витрати на перевірку поза ланцюжком, тоді парадигма розробки програмного забезпечення може радикально змінитися, але ця мета є повільною ітерацією, тому ми акцентуємо увагу на пошуку проектів, які відповідають цим двом тенденціям або цінностям, крім того, причетність ZK-обчислювальних чіпів є передумовою масового комерціалізації ZK-процесора; цей цикл є недостатньо інноваційним, він є справжнім вікном для побудови наступного технологічного періоду «Масового прийняття» та застосування, ми передбачаємо, що в наступному циклі ланцюжок ZK-індустрії зможе комерціалізуватися, тому зараз саме час знову звернути увагу на технології, які справді можуть дозволити Web3 обслуговувати взаємодію 1 млрд осіб на ланцюжку.