0. Введение

В этом посте мы рассмотрим недавно популярные концепции zkCoprocessor и zkOracle и сравним их различия.

1. Определение zkCoprocessor

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

1. ZK: В то время как ученые часто говорят о функциях конфиденциальности Zero Knowledge, в контексте блокчейна ZK часто означает краткость и действительность технологии. Даже проекты, построенные на ZK Rollup, называют себя zkSomething.
2. До сих пор многие действительно не осознавали, что Доступность данных — это не Хранение данных, поэтому для решения этой терминологической проблемы некоторые людипредложенный замена DA на DP(Публикация данных), или превращение всего значения DA в публикацию данных + хранение данных (1, 2).

Мы видим аналогичное явление в термине zkCoprocessor. Все используют этот термин, но они не обязательно относятся к одним и тем же вещам.

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

а) От самих себя проекта

Определение 1 от Axiom: zkCoprocessor доказывает исторические данные onchain.

Концепция zkCoprocessor была популяризирована Axiom, которая изначально задумала ее как zkAttestor. Из идеи Axiom zkCoprocessor представляет собой компонент, который "доказывает исторические данные on-chain и доверительно использует эти данные в смарт-контракте".

Обратите внимание, что команда Brevis сказала, что эти типы zkCoprocessors по сути являются слоем API/DSL поверх базовой zk схемы. Поэтому это нельзя программировать.

Определение 2 из RISC Zero: zkCoprocessor переносит вычисления с цепи на цепь.

RISC Zero также часто называет себя zkCoprocessor. С их точки зрения, они видят zkCoprocessor как более широкое понятие, «инструмент для использования ZKPs для выгрузки вычислений с цепи на внецепочную».

b) Из сообщества

Определение от Петериса (то же, что и 1): zkCoprocessor может получить доступ к историческому состоянию onchain.

Петерис из Aera Finance веритчто zkCoprocessor действует очень похоже на стейт оракул, основная функция которого - доступ к историческим данным. В то же время, он и Rishabh из BananaHQсчитает, что описание определения 2 больше похоже на zkVM, чем на подкласс zkCoprocessor.

Определение от Messari, Modular Media и Kobi (то же самое, что и 2): zkCoprocessor выгружает вычисления с цепи на цепь.

Messari также дал свое собственное определение zkCoprocessor. Сами, исследователь в Messari, веритчто zkCoprocessor позволяет разработчикам смарт-контрактов легко выносить сложную логику за пределы цепи без новых доверительных предположений. Модульный медиа такжедает ту же концепцию. Kobi из Geometryсравнивает rollup с сопроцессором, Бревис добавил, что zkCoprocessor торги за счет затрат на поддержание постоянного хранилища состояния против сверхускоренной производительности, Taiko придумал дизайн Ускорительный Rollupкоторые дополнительно исследовали идею Rollup Coprocessor. Это та же самая определение, что и RISC Zero.

c) От нас

Подводя итог, мы приходим к выводу, что на практике существует два типа zkCoprocessor, и они следующие:

1. Доступ к данным zkCoprocessor: в основном подает определенные данные (исторический блок, историческое состояние) в определенное место (смарт-контракт).
2. zkVM Compute zkCoprocessor: вычисляет с использованием offchain zkVM, затем передает результат обратно onchain.Сжимает O(n) вычисление в простую O(1) проверку.

2. Определение zkOracle

а) Оракул

Hyper Oracle предоставляет нам объяснение Oracle в Определение zkOracle для Ethereum.

Oracle практически подводит итог «инфраструктуре» в любом пространстве блокчейна, как лучшее определение, чем сопроцессор.

Если входными данными для инфраструктуры/оракула являются данные вне сети, а выходными данными являются ончейн, то это входной оракул (например, Chainlink Price Feed). И наоборот, это выходной оракул (например, The Graph). Если сначала выходной оракул, затем входной оракул, то это оракул ввода-вывода (например, Gelato Network).

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

б) zkOracle

Возьмем гипероракул в качестве примера, какова связь между zkOracleи zkCoprocessor?

Обсуждаемый в статье Defining zkOracle for Ethereum zkOracle на самом деле обладает возможностями как zkCoprocessors.

Например, zkOracle, такой как Гипер Oracle:

1. Доступ к историческим данным в недоверительном способе.
2. Может выполнять программные вычисления.

3. zkCoprocessor и zkOracle

Когда мы напрямую сравниваем два типа zkCoprocessor с zkOracle, мы видим, что zkOracle имеет все функции zkCoprocessor одновременно:

1. асинхронная обработка для смарт-контракта
2. взаимодействие и расширение возможностей существующих приложений на L1 или L2
3. снятие вычислений в ресурсоограниченной системе

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

Два zkCoprocessors расширяют свои соответствующие вертикали, например, Data Access zkCoprocessor разблокирует сценарии межцепочечных взаимодействий, а zkVM Compute zkCoprocessor представляет собой zkVM-основанный zk rollup.

4. Построить с zkCoprocessor или zkOracle

Какой выбрать при построении?

Пошагово мы можем принимать решения о создании приложения.

a) DApp с чистым умным контрактом

Во-первых, чистая реализация контрактов Solidity по-прежнему очень хороший выбор. Хотя чистые смарт-контракты не предоставляют некоторые из лучших новейших функций, они все еще достаточны.в определенных сценарияхТакже текущая доступность Arbitrum Stylus разблокировала множество новых приложений с чистым смарт-контрактом.

b) DApp, требующий более полного доступа к данным

Во многих случаях разработчики могут захотеть использовать Data Access zkCoprocessor или zkOracle для смарт-контрактов, чтобы получить доступ к более богатым источникам данных.

В этом сценарии, если использовать Data Access zkCoprocessor отдельно, вычисление все равно обрабатывается в смарт-контракте. Роль zkCoprocessor заключается в упрощении сложности получения данных традиционным способом, а не в увеличении вычислительной мощности смарт-контракта.

В данном сценарии мы видим множество небольших проектов, связанных с данными, а не полноценных DApps в традиционном смысле:

1. Использование zkCoprocessor Аксиома: Управление LP улучшено, Возмещение MEVictim
2. Используя zkOracle Гипер Оракул: Цена Uniswap v2, активность торгов на OpenSea, монитор объема USDT

c) DApp that Needs Heavy Compute

Часто некоторые сложные алгоритмы не могут быть вычислены напрямую на цепи, для игр вычислительная логика очень сложна, например, etherquake и GameOfLife, которые стоят $2k для запуска одного шага. Или сложные алгоритмы, связанные с машинным обучением, которые невозможно выполнить на цепи. Поэтому нам нужен zkVM zkCoprocessor или zkOracle для выполнения вычислений за пределами цепи, а затем представить их на цепи в качестве ZKP.

В этом примере мы можем увидеть некоторый из их неограниченного вычислительного потенциала:

1. Используя zkCoprocessor Bonsai: Zeth (доказывает Reth в zkVM), zk-настроение
2. Используя zkOracle Hyper Oracle или zkWASM: zkGo (Prove L2-Geth в zkVM, Type-0 zkEVM), zkAMM

г) Децентрализованное приложение нового поколения с полным набором функций (DeFi 3.0)

Наконец, мы говорили о приложениях, которые можно создать только с помощью zkOracle. Возьмем в качестве примера приложение DeFi, полноценный DeFi очень сложен. Следующее поколение приложений DeFi, или DeFi 3.0 DApps, потребуется:

1. Более полный доступ к данным
2. Неограниченные вычисления
3. Автономный (для ликвидации, обновления параметров, управления протоколом)

Мы уже обсудили, как zkOracle объединяет возможности как zkCoprocessors, одновременно выполняя первые два функциональных требования. Как zkOracle выполняет автономную функцию и как zkCoprocessor этого не делает?

1. zkOracle: Никакого человеческого вмешательства не требуется. Доступ к данным и выполнение вычислительных задач могут быть полностью определены и выполнены в программном и автоматизированном режиме. Все вызовы onchain всегда являются доверенными и действительными.
2. zkCoprocessor: Требует ончейн-мониторинга и фильтрации ответа вычислений релеем или добавления дополнительных сложных механизмов.

Итак, что означает отсутствие автономного режима в zkCoprocessor:

1. Недостаточная децентрализация
2. Риск потенциально сложных механизмов
3. Нагрузка на психику разработчика

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

Следует отметить, что Хуки также могут обрабатывать некоторые отсутствующие функции zkCoprocessor, но ТОЛЬКО в сценариях, например, DeFi, и не универсально.

Отказ:

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