Поскольку концепция сопроцессоров стала популярной в последние месяцы, этот новый вариант использования 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, что позволит снизить комиссию за транзакцию Trader или увеличить долю вознаграждения LP...

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

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

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

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

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

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

Почему его называют "сопроцессором"? На самом деле, это происходит от "GPU" в истории развития Web2.0. Причина, по которой GPU был представлен как отдельное вычислительное оборудование и существовал независимо от CPU, заключалась в том, что его архитектура могла обрабатывать некоторые вычисления, которые были принципиально сложны для CPU, например, крупномасштабные параллельные повторяющиеся вычисления, графические вычисления и т.д. . Именно благодаря этой "сопроцессорной" архитектуре у нас сегодня есть замечательные 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. Что еще более важно, так это то, что в дополнение к расчетному уровню ZK Rollup также необходимо реализовать уровень хранения, подобный блокчейну L1. Это хранилище является постоянным, в то время как Сопроцессор ZK "не имеет статусов". После завершения вычисления статус "Все" не сохраняется.

С точки зрения сценариев применения, сопроцессор можно рассматривать как сервисный плагин для всех уровней 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. Какой сопроцессор лучше - Сравнение нескольких распространенных технических решений сопроцессоров на рынке

Brevis

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

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

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

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

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

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

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

Сеть zkFabric Prover реализует схему для протокола lightclient каждого блокчейна, и сеть генерирует доказательства достоверности заголовков блоков. Проверяющие могут использовать ускорители, такие как GPU, FPGA и ASIC, чтобы минимизировать время и стоимость доказательства.

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

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

Текущее размещение:

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

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

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

Геродот

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

1. Состояния L1 от состояний L2
2. Состояния L2 как от L1, так и от других L2
3. Состояния L3/App-Chain для L2 и L1

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

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

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

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

Доказательство хранения, по определению Геродота, - это слияние:

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

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

1.Получение хэша блока

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

2.Получение заголовка блока

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

Есть два способа получить хэш:

1. Используйте опкод BLOCKHASH, чтобы получить
2. Запросите хэш блоков, которые были проверены в истории, из Block Hash Accumulator

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

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

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

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

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

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

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

4.Проверка данных на соответствие выбранному корню (необязательно)

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

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

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 последовательных хэшей блоков. Эти корни Меркле обновляются с помощью ZK-доказательств, проверяющих, что хэш заголовка блока образует цепочку обязательств, заканчивающуюся одним из последних 256 блоков, непосредственно доступных EVM, или хэшем блока, который уже существует в кэше AxiomV1.

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

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

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

Эти ZK-доказательства проверяют, находятся ли соответствующие внутрицепочечные данные непосредственно в заголовке блока или в тройке счета или хранения блока, проверяя доказательство включения (или невключения) тройки Меркле-Патрича.

Nexus

Nexus пытается использовать доказательства с нулевым знанием для создания универсальной платформы для верифицируемых облачных вычислений. В настоящее время он не зависит от машинных технологий и поддерживает risc 5/ WebAssembly/ EVM. Nexus использует систему доказательств Supernova. Команда проверила, что память, необходимая для создания доказательства, составляет 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, секвенсоры optimistic rollup и другие серверы доказательств, такие как сам zkVM Nexus Zero.

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

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