1. Что такое сопроцессор и что это не такое?

Если вас попросили объяснить сопроцессоры не техническому или разработчику всего одним предложением, как бы вы это описали?

Думаю, что сказал доктор Донг Мо, может быть очень близко к стандартному ответу - грубо говоря, сопроцессор дает возможность смарт-контракту выполнять аналитику Dune.

Как разобрать эту фразу?

Представьте ситуацию, когда мы используем Dune - вы хотите делать LP в Uniswap V3, чтобы заработать некоторые комиссии за обработку, поэтому вы открываете Dune и находите последний объем торгов по различным торговым парам на Uniswap, APR комиссий за обработку за последние 7 дней и основные торговые пары Верхние и нижние диапазоны колебаний и т. д...

Или, возможно, когда StepN стал популярным, вы начали спекулировать на обуви, и не были уверены, когда их продавать, поэтому каждый день смотрели на данные StepN на Dune, объем ежедневных транзакций, количество новых пользователей, стоимость обуви... и планировали продать, когда наступил рост. Если тенденция замедлится или начнет идти вниз, быстро убегайте.

Конечно, вы можете не только смотреть на эти данные, но и команды разработчиков Uniswap и StepN также обращают внимание на эти данные.

Эти данные очень важны - они могут не только помочь определить изменения в трендах, но также использовать их для создания новых трюков, как это делают крупные интернет-компании с помощью подхода 'больших данных'.

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

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

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

……

В настоящее время возникает проблема - когда крупные интернет-компании играют с большими данными + ИИ, это в основном черный ящик. Они могут делать все, что им угодно. Пользователи этого не видят и не обращают внимания.

Но на стороне Web3 прозрачность и отсутствие доверия - это наша естественная политическая корректность, и мы отвергаем черные ящики!

Итак, когда вы хотите осуществить вышеописанный сценарий, вы столкнетесь с дилеммой - либо вы можете достичь этого с помощью централизованных средств, "вручную" использовать Dune для подсчета индексных данных в фоновом режиме, а затем развернуть и выполнить его; либо вы можете написать умные контракты для автоматического захвата этих данных на цепи, выполнить расчеты и автоматически развернуть баллы.

Первый может оставить вас с проблемами доверия "политически некорректные".

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

Это время для выхода на сцену сопроцессора. Объедините два только что использованных метода и одновременно используйте шаг "фонового руководства" для "самодоказательства невиновности" с помощью технических средств. Другими словами, используйте технологию ZK для "индекса +" вне цепи. Часть "вычисления" "самодоказывает невиновность", а затем передает ее смарт-контракту. Таким образом, проблема доверия решена, а массовые газовые сборы ушли. Идеально!

Почему это называется «сопроцессором»? Фактически это происходит от «GPU» в истории развития Web2.0. Причина введения GPU как отдельного вычислительного оборудования и его независимого существования от ЦП в то время заключалась в том, что его архитектура могла обрабатывать некоторые вычисления, которые фундаментально сложно обрабатывать ЦП, такие как крупномасштабные параллельные повторяющиеся вычисления, графические вычисления и т. д. Именно благодаря этой архитектуре «ко-процессора» у нас есть замечательные CG-фильмы, игры, модели искусственного интеллекта и т. д. сегодня, поэтому эта архитектура сопроцессора на самом деле является прорывом в архитектуре вычислений. Теперь различные команды сопроцессоров также надеются внедрить эту архитектуру в Web3.0. Здесь блокчейн похож на ЦП Web3.0. Как L1, так и L2, они по своей сути не годятся для таких задач, как «тяжелые данные» и «сложная логика вычислений», поэтому вводится блокчейн-сопроцессор для помощи в обработке таких вычислений, тем самым значительно расширяя возможности приложений блокчейна.

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

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

Некоторое время назад у Starkware был популярный концепт под названием Storage Proof, также называемый State Proof. В основном это делает шаг 1, представленный Геродотом, Лангражем и т. д. Технический упор многих кросс-цепочечных мостов, основанных на ZK технологии, также находится на шаге 1. 1.

Копроцессор - это всего лишь добавление шага 2 после завершения шага 1. После извлечения данных без доверия он может выполнить расчет без доверия.

Итак, чтобы использовать относительно технический термин, чтобы точно описать это, сопроцессор должен быть надмножеством хранилище доказательства/доказательства состояния и подмножеством верифицируемых вычислений.

Одно важное замечание: копроцессор не является Rollup.

С технической точки зрения доказательство ZK Rollup аналогично шагу 2 выше, и процесс шага 1 "получение данных" напрямую реализуется через Sequencer. Даже децентрализованный Sequencer использует какой-то вид соревнования или механизма консенсуса. Вместо доказательства хранения в форме ZK. Что более важно, помимо слоя вычислений ZK Rollup также должен реализовать слой хранения, аналогичный L1 блокчейну. Этот слой хранения является постоянным, в то время как ZK Coprocessor является "бессостоятельным". После завершения вычислений никакое состояние не сохраняется.

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

2. Почему вы должны использовать ZK? Можно использовать OP?

После прочтения вышеуказанного у вас может возникнуть сомнение: должно ли это делаться с ZK в качестве сопроцессора? Это звучит так, как будто "Граф с добавлением ZK", и у нас не кажется, что у нас есть какие-то "большие сомнения" относительно результатов на Графе.

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

Но вновь, действительно ли нам нужно использовать ZK для совместной обработки всех вышеупомянутых сценариев? В конце концов, у нас есть два технических пути, OP и ZK, в Rollup. Недавно популярный ZKML также имеет концепцию OPML соответствующих ветвистых путей. Спрашивается, имеет ли копроцессор также ветвь OP, например, OP-Coprocessor?

На самом деле, это так, но мы пока держим конкретные детали в секрете, и скоро мы предоставим более подробную информацию.

3. Какой копроцессор лучше - Сравнение нескольких распространенных технологических решений копроцессоров на рынке

1. Brevis:

Архитектура Brevis состоит из трех компонентов: zkFabric, zkQueryNet и zkAggregatorRollup.

Далее приведена схема архитектуры Brevis:

zkFabric: Собирает заголовки блоков со всех подключенных блокчейнов и генерирует доказательства ZK консенсуса, подтверждающие правильность этих заголовков блоков. Через zkFabric Brevis реализует взаимодействующий копроцессор для нескольких цепей, который позволяет одному блокчейну получить доступ к любым историческим данным другого блокчейна.

zkQueryNet: открытый рынок движка запросов ZK, который принимает запросы на данные от dApps и обрабатывает их. Запросы на данные обрабатывают эти запросы с использованием проверенных заголовков блоков из zkFabric и генерируют доказательства запросов ZK. Эти движки имеют как высокоспециализированные функции, так и общие языки запросов, чтобы удовлетворить различные потребности приложений.

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

ZK Fabric - ключевая часть генерации доказательств для заголовка блока. Очень важно обеспечить безопасность этой части. Ниже приведена архитектурная диаграмма zkFabric:

Zero-Knowledge Proof (ZKP) на основе zkFabric делает его полностью безопасным без необходимости полагаться на внешнюю проверяющую сущность. Нет необходимости полагаться на внешнюю проверяющую сущность, поскольку его безопасность полностью зависит от базового блокчейна и математически достоверных доказательств.

Сеть zkFabric Prover реализует схемотехнику для протокола легкого клиента каждого блокчейна, и сеть генерирует доказательства правильности заголовков блоков. Доказыватели могут использовать ускорители, такие как графические процессоры, ПЛИС и ASIC, чтобы минимизировать время и стоимость доказательства.

zkFabric полагается на предположения о безопасности блокчейна и базового протокола шифрования, а также на предположения о безопасности базового протокола шифрования. Однако, чтобы обеспечить эффективность zkFabric, требуется как минимум один честный ретранслятор для синхронизации правильной ветки. Поэтому zkFabric принимает децентрализованную ретрансляционную сеть вместо одиночной ретрансляции для оптимизации эффективности zkFabric. Эта сеть ретрансляции может использовать существующие структуры, такие как сеть защиты состояния в сети Celer.

Распределение подтверждений: Сеть подтверждений - это децентрализованная сеть подтверждений ZKP, которая выбирает подтверждающего для каждой задачи генерации доказательств и выплачивает им комиссию.

Текущее развертывание:

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

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

С помощью Brevis, hook решил задачу. Теперь хуки могут читать данные из полной истории цепочки пользователя или LP и выполнять настраиваемые расчеты полностью доверительным образом.

1. Геродот

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

L1 состояния от L2s

Состояния L2 как от L1, так и от других L2

Состояния цепочки приложений L3 для L2 и L1

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

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

Использование деревьев Меркла и Меркла Патриции повышает безопасность блокчейна Ethereum. Путем криптографического хеширования данных на каждом уровне дерева почти невозможно изменить данные без обнаружения. Любые изменения точки данных требуют изменения соответствующего хеша на дереве к корневому хешу, который публично виден в заголовке блокчейна. Эта фундаментальная особенность блокчейна обеспечивает высокий уровень целостности данных и неизменяемость.

Во-вторых, эти деревья позволяют осуществлять эффективную проверку данных с использованием доказательств включения. Например, при проверке включения транзакции или состояния контракта нет необходимости искать весь блокчейн Ethereum, а только путь в соответствующем дереве Меркла.

Доказательство хранения, как определено Геродотом, является объединением:

• Доказательства содержания: Эти доказательства подтверждают наличие конкретных данных в криптографической структуре данных (такой как дерево Меркля или дерево Меркля Патрисии), обеспечивая тем самым, что данные вопроса действительно присутствуют в наборе данных.
• Вычислительное доказательство: Проверка выполнения многошагового рабочего процесса, доказывающая действительность одного или нескольких элементов в обширном наборе данных, таком как весь блокчейн Ethereum или агрегат. Они также проверяют преобразования или операции, примененные к этим данным, помимо указания наличия данных.
• Доказательства нулевого знания: Упрощение объема данных, с которыми должны взаимодействовать смарт-контракты. Доказательства нулевого знания позволяют смарт-контрактам подтверждать правильность утверждения без обработки всех базовых данных.

Workflow :

1. Получить хэш блока

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

1. Получить заголовок блока

После получения соответствующего хэша блока следующим шагом является доступ к заголовку блока. Для этого необходимо хэшировать заголовок блока, связанный с полученным ранее хэшем блока. Затем хэш предоставленного заголовка блока сравнивается с полученным хэшем блока:

Существует два способа получить хеш:

(1) Используйте операцию BLOCKHASH для извлечения

(2) Запрос хэшей блоков, которые были проверены в истории, из накопителя хэшей блоков

Этот шаг гарантирует, что заголовок блока, который обрабатывается, является подлинным. Как только этот шаг завершен, смарт-контракт может получить доступ к любому значению в заголовке блока.

1. Определите необходимые корни (необязательно)

С блок-заголовком в руках мы можем погрузиться в его содержимое, а именно:

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

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

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

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

1. Проверьте данные по выбранному корню (необязательно)

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

В настоящее время поддерживаемые сети:

От Ethereum до Starknet

Из Ethereum Goerliв Starknet Goerli

Из Ethereum Goerliв эру zkSync Goerli

1. Аксиома

Axiom предоставляет разработчикам способ запроса заголовков блоков, значения счетов или хранилища ​​из всей истории Ethereum. AXIOM вводит новый метод связывания на основе криптографии. Все результаты, возвращаемые Axiom, проверяются on-chain через доказательства нулевого знания, что означает, что умные контракты могут использовать их без дополнительных предположений о доверии.

Axiom недавно выпустилHalo2-repl , это оболочка halo2, основанная на браузере и написанная на Javascript. Это позволяет разработчикам писать ZK-схемы, используя только стандартный Javascript, не изучая новый язык, такой как Rust, устанавливать библиотеки доказательств или иметь дело с зависимостями.

Аксиома состоит из двух основных технологических компонентов:

AxiomV1 — кэш блокчейна Ethereum, начиная с Genesis.

AxiomV1Query — Смарт-контракт, выполняющий запросы к AxiomV1.

(1) Значение хэша блока кэша в AxiomV1:

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

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

Во-вторых. Аксиома хранит горный массив Меркля этих корней Меркля, начиная с блока генезиса. Горный массив Меркля строится on-chain путем обновления первой части кэша, корня Меркля Keccak.

(2) Выполните запрос в AxiomV1Query:

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

Эти ZK-доказательства проверяют, находятся ли соответствующие данные on-chain непосредственно в заголовке блока или в учетной записи блока или хранилище trie, проверяя включение (или отсутствие включения) доказательства Merkle-Patricia Trie.

1. Нексус

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

Для точности, архитектура делится на две части:

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

Nexus: децентрализованная проверяемая сеть облачных вычислений, работающая на основе многопартийных вычислений, репликации конечного автомата и универсальной виртуальной машины WASM.

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

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

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

Поскольку Nexus может запускать любые детерминированные WASM-бинарные файлы в реплицируемой среде, ожидается, что он будет использоваться в качестве источника доказательства допустимости/распределенности/устойчивости к сбоям для созданных приложений, включая последователей zk-rollup, оптимистичных последователей rollup и другие доказательства сервера, такие как сама zkVM Nexus Zero.

Отказ от ответственности:

1. Эта статья перепечатана с [Средний]. Все авторские права принадлежат оригинальному автору [АБЦДЕ]. Если у вас есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.