1. Введение в концепцию

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

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

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

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

2. Зачем нам нужен сопроцессор ZK?

Одним из самых больших узких мест, с которыми сталкиваются разработчики смарт-контрактов, остаются высокие затраты, связанные с вычислениями на цепи. Поскольку для каждой операции необходимо измерять газ, стоимость сложной логики приложения быстро станет слишком высокой для выполнения, потому что, хотя архивные узлы в слое DA блокчейна действительно могут хранить исторические данные, вот почему приложения вроде Dune Off-chain analysis, такие как Analytics, Nansen, 0xscope и Etherscan, могут иметь так много данных из блокчейна и могут вернуться на долгое время, но для смарт-контрактов не просто получить доступ ко всем этим данным. Они могут легко получить доступ только к данным, хранящимся в состоянии виртуальной машины, последним данным блока и другим общедоступным данным смарт-контрактов. Для получения дополнительных данных смарт-контракты могут потратить много усилий на доступ к ним:

Смарт-контракты в Ethereum Virtual Machine (EVM) имеют доступ к хэшам заголовков блоков последних 256 блоков. Эти заголовки блоков содержат всю информацию об активности в блокчейне до текущего блока и сжимаются в 32-байтовое значение хэша с использованием дерева Меркля и алгоритма хэширования Keccak.

Несмотря на то, что данные упакованы в хеш-пакеты, их можно распаковать, но это непросто. Например, если вы хотите использовать самый последний заголовок блока для надежного доступа к определенным данным в предыдущем блоке, это включает в себя сложную последовательность шагов. Во-первых, вам нужно получить данные off-chain из архивного узла, а затем построить дерево Меркла и доказательство валидности блока, чтобы проверить подлинность данных в блокчейне. Впоследствии EVM обработает эти доказательства валидности, проверит и объяснит их. Эта операция не только громоздкая, но и занимает много времени, а газ еще и особенно дорогой.

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

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

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

3. Техническая реализация

Эта часть будет использовать архитектуру Axiom для объяснения того, как копроцессор zk технически решает проблему. Фактически, есть два ядра: захват данных и вычисление. В этих двух процессах ZK одновременно обеспечивает эффективность и конфиденциальность.

3.1 Захват данных

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

Копроцессор ZK решает эту проблему тремя различными способами, балансируя затраты, безопасность и удобство разработки:

1. Храните дополнительные данные в состоянии блокчейна и используйте EVM для хранения всех данных, используемых on-chain read verification co-процессором. Этот подход довольно дорог и нецелесообразен для больших объемов данных.
2. Доверьте Оракула или сеть подписантов для проверки входных данных в сопроцессор. Это требует, чтобы пользователи сопроцессора доверяли Оракулу или провайдеру мультиподписи, что снижает безопасность.
3. Используйте ZK-доказательства, чтобы проверить, были ли какие-либо on-chain данные, используемые во вспомогательном процессоре, зафиксированы в истории блокчейна. Любой блок в блокчейне фиксирует все прошлые блоки и, следовательно, любые исторические данные, обеспечивая криптографические гарантии достоверности данных и не требуя дополнительных доверительных предположений от пользователя.

3.2 Расчет

Выполнение вычислений вне цепи в качестве сопроцессора ZK требует преобразования традиционных компьютерных программ в ZK-цепи. В настоящее время все методы достижения этого имеют огромное влияние на производительность, с доказательствами ZK варьирующимися от 10 000 до 1 000 000 в накладных расходах по сравнению с выполнением программы нативно. С другой стороны, вычислительная модель ZK-цепей отличается от стандартных компьютерных архитектур (например, в настоящее время все переменные должны быть закодированы по модулю большого криптографического простого числа, и реализация может быть недетерминированной), что означает, что разработчикам трудно писать их напрямую.

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

1. Пользовательские схемы: Разработчики пишут свои собственные схемы для каждого приложения. Этот подход имеет наибольший потенциал производительности, но требует значительных усилий разработчика.
2. eDSL/DSL для схем: Разработчики пишут схемы для каждого приложения, но абстрагируются от специфических для ZK проблем в определенном фреймворке (аналогично использованию PyTorch для нейронных сетей). Однако производительность немного ниже.
3. Разработчики zkVM пишут схемы в существующих виртуальных машинах и проверяют их выполнение в ZK. Это обеспечивает самый простой опыт для разработчиков при использовании существующих виртуальных машин, но приводит к снижению производительности и гибкости из-за различных моделей вычислений между виртуальными машинами и ZK.

4. Приложение

Копроцессор ZK имеет широкий спектр применений. Копроцессор ZK теоретически может охватить все сценарии применения, которые может охватить Dapp. Пока это задача, связанная с данными и вычислениями, копроцессор ZK может снизить затраты, увеличить эффективность и защитить конфиденциальность. Далее будет рассмотрено с разных сторон, что может сделать ZK-процессор на уровне приложения.

4.1 Defi

4.1.1 DEX

Возьмем крюк в Uniswap V4 как пример:

Hook позволяет разработчикам выполнять определенные операции в любой ключевой точке на всем протяжении жизненного цикла пула ликвидности - например, до или после торговли токенами, до или после изменения позиции LP, настраиваемые пулы ликвидности, обмены, комиссии Как взаимодействовать с позициями LP, например:

• Time Weighted Average Market Maker (TWAMM);
• динамические комиссии на основе волатильности или других входных данных;
• Ограничение цены цепи;
• Депозит вне диапазона ликвидности в протоколы кредитования;
• Настроенные оракулы на цепи, такие как геометрические средние оракулы;
• Автоматически начислять комиссии по ликвидности на позиции ликвидности;
• Прибыль MEV от Uniswap распределяется среди LP;
• Дисконтная программа лояльности для LP или трейдеров;

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

С долгосрочной точки зрения копроцессор ZK ускорит интеграцию DEX и CEX. С 2022 года мы видим, что DEX и CEX стали функционально согласованными. Все крупные CEX принимают эту реальность и принимают кошельки Web3, создают EVM L2 и используют существующую инфраструктуру, такую как Lightning Network или открытый исходный код, чтобы принять обменную плавность on-chain. Это явление неразрывно связано с усилением ZK копроцессора. Все функции, которые может реализовать CEX, будь то сетевая торговля, последование, быстрые займы или использование пользовательских данных, также могут быть реализованы через ZK копроцессор DEX, а также компонуемость и свобода Defi, а также транзакции малых валют на цепи, сложно достичь с помощью традиционных CEX. В то же время технология ZK также может защитить конфиденциальность пользователей во время выполнения.

4.1.2 Airdrop

Если некоторые проекты хотят провести раздачу токенов, им нужен смарт-контракт для запроса истории действий по адресу, но не хотят раскрывать информацию об адресе пользователя и выполнять его без введения дополнительного доказательства доверия. Например, проект, занимающийся Defi-кредитованием, хочет через взаимодействие между адресом и рядом протоколов кредитования, таких как Aave, Compound, Fraxlend и Spark в качестве стандарта для раздачи токенов, исторические данные и функции конфиденциальности криптопроцессора ZK могут легко решить эту проблему.

4.2 ZKML

Еще одной захватывающей точкой копроцессора ZK является область машинного обучения. Поскольку смарт-контрактам могут быть предоставлены возможности вычислений вне цепи, станет возможным высокоэффективное машинное обучение в цепи. Фактически, копроцессор ZK также является неотъемлемой частью для ввода и вычисления данных ZKML. Он может извлекать входные данные, необходимые для машинного обучения, из онлайн/офлайн исторических данных, импортированных в смарт-контракт, а затем записывать вычисления в ZK-цепь и отправлять их в цепь.

4.3 KYC

KYC - это большой бизнес, и теперь мир веб3 постепенно внедряет соответствие. С помощью ZK-копроцессора можно сделать смарт-контракт проверяемым путем получения любых данных, предоставленных пользователем вне цепи, без необходимости раскрытия какой-либо ненужной информации о пользователях. Фактически, уже внедряются некоторые проекты, такие как KYC-хук Uniswap, который использует ZK-сопроцессор Pado для захвата данных вне цепи без доверия. Доказательства активов, доказательства академических квалификаций, доказательства путешествий, доказательства вождения, доказательства правопорядка, доказательства игроков, доказательства транзакций... Все исторические действия внутри и вне цепи даже могут быть упакованы в полноценную личность и записаны с высокой надежностью. ZK доказывает, что находится в цепи, защищая при этом конфиденциальность пользователя.

4.4 Социальные

Спекулятивный атрибут Friend.tech фактически сильнее, чем социальный атрибут. Основа заключается в его кривой привязки. Возможно ли добавить крюк к кривой привязки friend.tech, чтобы пользователи могли настраивать направление кривой привязки, например, реализовать После окончания безумия торговли ключами и ухода спекулянтов кривая привязки станет более плавной, барьер для настоящих фанатов будет снижен, и настоящий трафик частной сферы будет расти. Или позвольте смарт-контракту получить онлайн/офлайн социальный график пользователя и иметь возможность следовать за вашими друзьями на различных социальных Dapp-ах одним нажатием. Или вы можете создать частный клуб в цепочке, такой как Degen club, и могут войти только адреса, которые соответствуют историческим условиям расхода газа и т. д.

4.5 Игровая

В традиционных Web2-играх пользовательские данные являются очень важным параметром. Покупательское поведение, стиль игры и вклад могут сделать игру более управляемой и обеспечить лучший пользовательский опыт, например, механизм сопоставления ELO в MOBA-играх. Частота покупки скинов и т.д., но эти данные сложно зафиксировать смарт-контрактами в блокчейне, поэтому от них можно только заменить централизованными решениями или просто отказаться. Однако появление сопроцессора ZK делает возможными децентрализованные решения.

5. Проект Party

На этом пути уже есть несколько выдающихся игроков. Идеи на самом деле похожи. Они генерируют ZK-доказательство через доказательство хранения или консенсус, а затем выкладывают его на цепочку. Однако у каждого свои преимущества в технических характеристиках и реализованных функциях.

5.1 Аксиома

Axiom, лидер в области ZK (нулевых знаний) копроцессоров, фокусируется на возможности смарт-контрактов получать доступ ко всей истории Ethereum и любым вычислениям ZK-проверки без доверия. Разработчики могут отправлять on-chain запросы в Axiom, который затем обрабатывает их с помощью ZK-проверки и передает результаты обратно в смарт-контракт разработчика способом, не требующим доверия. Это позволяет разработчикам создавать более сложные on-chain приложения без полагания на дополнительные доверительные предположения.

Для выполнения этих запросов Axiom выполняет следующие три шага:

1. read: Axiom использует ZK доказательства для доверительного чтения данных из заголовков блоков, статуса, транзакций и квитанций исторических блоков Ethereum. Поскольку все данные Ethereum on-chain закодированы в этих форматах, Axiom имеет доступ ко всему, к чему имеют доступ архивные узлы. Axiom проверяет все входные данные в ZK копроцессор через ZK доказательства Меркл-Патриция и цепочки хешей заголовков блоков. Хотя такой подход сложнее разрабатывать, он обеспечивает лучшую безопасность и стоимость для конечных пользователей, поскольку он гарантирует, что все результаты, возвращаемые Axiom, криптографически эквивалентны он-чейн вычислениям, выполненным в EVM.
2. рассчитать: после того как данные будут восприняты, Axiom применяет проверенные расчеты к ним. Разработчики могут указать свою логику расчетов во фронт-энде JavaScript, и допустимость каждого расчета проверяется в ZK proof. Разработчики могут посетить AxiomREPL или просмотреть документацию, чтобы узнать о доступных вычислительных примитивах. Axiom позволяет пользователям получать доступ к on-chain данным и указывать свои собственные расчеты через eDSL. Он также позволяет пользователям писать свои собственные схемы, используя библиотеку ZK circuit.
3. проверить: Axiom предоставляет доказательства ZK о валидности для каждого результата запроса. Эти доказательства гарантируют, что (1) входные данные были правильно извлечены из цепи и (2) вычисления были правильно применены. Эти ZK-доказательства проверяются на цепи в смарт-контрактах Axiom, обеспечивая надежное использование окончательных результатов в смарт-контрактах пользователей.

Поскольку результаты проверяются с помощью ZK-доказательств, результаты Axiom криптографически так же безопасны, как результаты Ethereum. Этот подход не делает предположений о криптоэкономике, стимулах или теории игр. Axiom считает, что этот подход обеспечит наивысший уровень гарантий для приложений смарт-контрактов. Команда Axiom тесно сотрудничала с Фондом Uniswap и получила гранты Uniswap, а также создаст доверительный оракул на Uniswap.

5.2 Нулевой риск

Bonsai: В 2023 году RISC Zero выпустил Bonsai, сервис подтверждения, который позволяет ончейн и оффчейн приложениям запрашивать и получать доказательства zkVM. Bonsai - универсальный сервис нулевого доказательства, который позволяет любой цепи, любому протоколу и любому приложению использовать ZK-доказательства. Он обладает высокой параллельной способностью, программируем и обеспечивает высокую производительность.

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

zkVM - это основа Bonsai и поддерживает широкую совместимость языков, обеспечивая доказуемый код Rust и, потенциально, доказуемый код с нулевым знанием на любом языке, скомпилированном в RISC-V (таком как C++, Rust, Go и т. д.). Через рекурсивные доказательства, компиляторы пользовательских цепей, продолжение состояния и постоянные улучшения алгоритмов доказательства, Bonsai позволяет любому генерировать высокопроизводительные ZK-доказательства для различных приложений.

RISC Zero zkVM: RISC Zero zkVM, впервые выпущенный в апреле 2022 года, может доказать правильное выполнение произвольного кода, позволяя разработчикам создавать ZK-приложения на зрелых языках, таких как Rust и C++. Этот релиз является значительным прорывом в разработке ZK-программного обеспечения: zkVM позволяет создавать ZK-приложения без построения схем и использования специальных языков.

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

Эти приложения включают в себя:

• JSON: Докажите содержимое записи в файле JSON, сохраняя конфиденциальность других данных.
• Где Уолдо: Докажите, что Уолдо присутствует в файле JPG, сохраняя конфиденциальность других частей изображения.
• ZK Checkmate: Покажите, что вы видели ход к мату, не раскрывая выигрышный ход.
• ZK Доказательство эксплуатации: Доказательство того, что вы можете эксплуатировать учетную запись Ethereum, не раскрывая уязвимость.
• Проверка подписи ECDSA: Докажите действительность подписи ECDSA.

Эти примеры реализованы с использованием зрелой программной экосистемы: большинство наборов инструментов Rust доступны из коробки в Risc Zero zkVM. Совместимость с Rust - это переломный момент для мира программного обеспечения ZK: проекты, которые могли бы занять месяцы или годы для разработки на других платформах, могут быть легко решены на платформе RISC Zero.

Кроме того, RISC Zero также обеспечивает высокую производительность, кроме того, zkVM имеет ускорение GPU для CUDA и Metal, а также реализует параллельное доказательство больших программ через продолжение.

Ранее Risc Zero получила финансирование серии А в размере 40 миллионов долларов США от Galaxy Digital, IOSG, RockawayX, Maven 11, Fenbushi Capital, Delphi Digital, Algaé Ventures, IOBC и других учреждений.

5.3 Brevis

Brevis, дочерняя компания Celer Network, сосредотачивается на захвате исторических данных мультичейна. Она дает смарт-контрактам возможность читать свои полные исторические данные с любого чейна и выполнять всеобъемлющие доверительные настраиваемые вычисления. В настоящее время она в основном поддерживает Ethereum POS. Comos Tendermint и BSC.

Интерфейс приложения:Текущая система Brevis поддерживает эффективные и краткие доказательства ZK, предоставляя следующую проверенную ZK информацию об исходной цепочке для контрактов децентрализованных приложений (dApp), подключенных к блокчейну:

1. Хэш блока и связанные с ним статус, транзакции и корни квитанций любого блока на исходной цепи.
2. Значение слота и связанные метаданные для определенного блока, контракта, слота на исходной цепочке.
3. Квитанции о транзакциях и связанные метаданные для любой транзакции на исходной цепочке.
4. Входные данные транзакции и связанная метаданные для любой транзакции на цепи-источнике.
5. Любое сообщение, отправленное любым субъектом на цепочке-источнике любому субъекту на цепочке-цели.

Обзор архитектуры: архитектура Brevis состоит из трех основных частей:

1. Сеть ретранслятора: Она синхронизирует заголовки блоков и информацию о блокчейне из разных блокчейнов и пересылает их в сеть валидаторов для создания доказательств валидности. Затем он отправляет проверенную информацию и связанные с ней доказательства в подключенный блокчейн.
2. сеть проверяющих: Реализация схем для протокола легкого клиента каждого блокчейна, обновлений блоков и генерации доказательств запрошенных значений слотов, транзакций, квитанций и интегрированной логики приложения. Для минимизации времени доказательства, стоимости и затрат на проверку на цепи, сеть проверяющих может агрегировать распределенные доказательства, сгенерированные одновременно. Кроме того, она может использовать ускорители, такие как графические процессоры, ППЛИ и ASIC, для повышения эффективности.
3. Подключение контрактов валидаторов на блокчейне: получение данных, подтвержденных zk, и связанных доказательств, сгенерированных сетью валидаторов, а затем обратная передача проверенной информации контракту dApp.

Эта интегрированная архитектура позволяет Brevis обеспечить высокую эффективность и безопасность при предоставлении данных и вычислений межцепочечного взаимодействия, позволяя разработчикам dApp полностью использовать потенциал блокчейна. Благодаря этой модульной архитектуре Brevis может обеспечивать полностью децентрализованный, гибкий и эффективный доступ к данным и возможности вычислений для смарт-контрактов on-chain на всех поддерживаемых цепочках. Это предоставляет совершенно новую парадигму для разработки dApp. У Brevis есть широкий спектр использования, таких как децентрализованные финансы на основе данных, zkBridges, привлечение пользователей on-chain, zkDID, абстракция социальных аккаунтов и т. д., что увеличивает межцепочечную совместимость данных.

5.4 Лангранж

Langrange и Brevis имеют схожее видение, нацеливаясь на увеличение взаимодействия между несколькими цепями через ZK Big Data Stack, который может создавать универсальные доказательства состояния на всех основных блокчейнах. Путем интеграции с протоколом Langrange приложения могут представлять агрегированные доказательства состояния мультицепи, которые затем могут быть проверены неинтерактивно контрактами на других цепях.

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

Протокол Лангранж в начале будет совместим с L1 и L2 rollups, совместимыми с EVM. Кроме того, Лангранж также планирует поддерживать несовместимые с EVM цепочки в ближайшем будущем, включая, но не ограничиваясь, Solana, Sui, Aptos и популярные общедоступные цепочки, основанные на Cosmos SDK.

Разница между протоколом Langrange и традиционными протоколами мостикования и обмена сообщениями:

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

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

Следовательно, доказательства состояния Лангранжа можно рассматривать как оптимизацию для отношений многие-к-одному (n-к-1) цепей. В этом межцепочном отношении децентрализованное приложение (DApp) на одной цепи полагается на агрегацию данных о состоянии в реальном времени и в исторической перспективе из нескольких других цепей (n). Эта функция значительно расширяет функциональность и эффективность DApps, позволяя им агрегировать и анализировать данные из нескольких различных блокчейнов для предоставления более глубоких и более полных инсайтов. Этот метод существенно отличается от традиционных одиночных или один-к-одной цепи отношений и предоставляет более широкий потенциал и область применения для блокчейн-приложений.

Langrange ранее получила инвестиции от 1kx, Maven11, Lattice, CMT Digital и gumi crypto.

5.5 Геродот

Herodotus предназначен для предоставления смарт-контрактам синхронного доступа к данным в блокчейне с других уровней Ethereum. Они считают, что доказательство хранения может унифицировать состояние нескольких роллапов и даже обеспечить синхронное чтение между уровнями Ethereum. Проще говоря, это сбор данных между основной цепочкой EVM и роллапом. В настоящее время поддерживает основную сеть ETH, Starknet, Zksync, OP, Arbitrum и Polygon.

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

Процесс создания доказательств хранения условно делится на три этапа:

Шаг 1: Получите аккумулятор хранения заголовка блока проверяемых обязательств

• Этот шаг предназначен для получения «обязательства», которое мы можем проверить. Если аккумулятор еще не содержит последний заголовок блока, который нам нужно доказать, сначала нам нужно доказать непрерывность цепочки, чтобы убедиться, что мы охватываем диапазон блоков, содержащих наши целевые данные. Например, если данные, которые мы хотим доказать, находятся в блоке 1 000 001, а смарт-контракт, хранящийся в заголовке блока, охватывает только блок 1 000 000, то нам нужно обновить хранилище заголовков.
• Если целевой блок уже находится в аккумуляторе, вы можете перейти непосредственно к следующему шагу.

Шаг 2: Доказать существование конкретного аккаунта

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

Шаг 3: Докажите конкретные данные в дереве учетной записи

• На этом этапе можно создавать доказательства включения для данных, таких как номера, балансы, корни хранения или codeHash. У каждого учетной записи Ethereum есть хранилище тройки (дерево Меркла Патрисии), которое используется для сохранения данных хранения учетной записи. Если данные, которые мы хотим доказать, находятся в хранилище учетной записи, тогда нам нужно создать дополнительные доказательства включения для конкретных точек данных в этом хранилище.

После генерации всех необходимых доказательств включения и вычислительных доказательств формируется полное доказательство хранения. Затем это доказательство отправляется на цепочку, где оно проверяется по отношению к одному изначальному обязательству (например, блочному хэшу) или корню MMR, хранимому в заголовке. Этот процесс гарантирует подлинность и целостность данных, сохраняя при этом эффективность системы.

Herodotus уже поддерживается Geometry, Fabric Ventures, Lambda Class и Starkware.

5.6 HyperOracle

Hyper Oracle специально разработан для программных нулевых оракулов, чтобы обеспечить безопасность и децентрализацию блокчейна. Через свой стандарт zkGraph, Hyper Oracle делает практичными, верифицируемыми и быстрыми финальностью он-чейн данных и эквивалентных вычислений он-чейн. Он предоставляет разработчикам совершенно новый способ взаимодействия с блокчейном.

Узел zkOracle Hyper Oracle в основном состоит из двух компонентов: zkPoS и zkWASM.

1. zkPoS: Этот компонент отвечает за получение заголовка блока и корневых данных блокчейна Ethereum с помощью доказательства нулевого знания (zk), чтобы гарантировать правильность консенсуса Ethereum. zkPoS также действует как внешняя схема для zkWASM.
2. zkWASM: Он использует данные, полученные из zkPoS в качестве ключевого ввода для запуска zkGraphs. zkWASM отвечает за выполнение пользовательских карт данных, определенных zkGraphs, и создание доказательств нулевого знания для этих операций. Операторы узлов zkOracle могут выбирать количество zkGraphs, которые они хотят запустить, которое может быть от одного до всех развернутых zkGraphs. Процесс генерации zk-доказательств может быть делегирован распределенной сети доказателей.

Результат работы zkOracle - это данные вне цепи, и разработчики могут использовать эти данные через стандарт zkGraph от Hyper Oracle. Данные также поставляются с zk-сертификатами для проверки достоверности данных и вычислений.

Для обеспечения безопасности сети сеть Hyper Oracle требует только одного узла zkOracle. Однако в сети может существовать несколько узлов zkOracle, работающих против zkPoS и каждого zkGraph. Это позволяет генерировать zk-доказательства параллельно, что значительно улучшает производительность. В общем, Hyper Oracle предоставляет разработчикам эффективную и безопасную платформу взаимодействия с блокчейном путем объединения передовой zk-технологии и гибкой архитектуры узлов.

В январе 2023 года Hyper Oracle объявила, что получила 3 миллиона долларов США в предварительном раунде финансирования, в котором приняли участие совместно Dao5, Sequoia China, Foresight Ventures и FutureMoney Group.

5.7 Путь

Pado - особое существо среди сопроцессоров ZK. Другие сопроцессоры сосредотачиваются на захвате ончейн-данных, в то время как Pado предоставляет путь для захвата офчейн-данных, нацеленный на приведение всех данных интернета в смарт-контракты. Он заменяет функцию оракула в определенной степени, обеспечивая при этом конфиденциальность и устраняя необходимость доверять внешним источникам данных.

5.8 Сравнение между ZK копроцессором и оракульной машиной

• Задержка: Оракул асинхронен, поэтому задержка при доступе к плоским данным дольше, чем у сопроцессора ZK.
• Стоимость: Хотя многие оракулы не требуют вычислительных доказательств и, следовательно, менее затратны, они менее надежны. Хранение доказательств обходится дороже, но более безопасно.
• Безопасность: Максимальный уровень безопасности передачи данных ограничивается уровнем безопасности самого оракула. В отличие от этого, ZK сопроцессор соответствует безопасности цепочки. Кроме того, оракулы уязвимы к манипуляциям из-за использования внецепевых доказательств.

На рисунке ниже показана схема работы Pado:

Pado использует криптоузлы в качестве серверных доказательств. Чтобы уменьшить предположения о доверии, команда Pado примет эволюционную стратегию и постепенно улучшит децентрализацию службы доказательства. Прувер активно участвует в процессе поиска и обмена пользовательскими данными, доказывая подлинность пользовательских данных, полученных из сетевых источников данных. Что делает его уникальным, так это то, что Pado использует MPC-TLS (Transport Layer Secure Multi-Party Computation) и IZK (Interactive Zero-Knowledge Proof), чтобы позволить доказателям доказывать данные «вслепую». Это означает, что валидаторы не могут видеть какие-либо исходные данные, включая публичную и частную информацию о пользователях. Тем не менее, верификатор по-прежнему может гарантировать происхождение любых передаваемых данных TLS с помощью криптографических методов.

1. MPC-TLS: TLS — это протокол безопасности, используемый для защиты конфиденциальности и целостности данных интернет-коммуникаций. Когда вы посещаете веб-сайт и видите значок «замок» и «https» на URL-адресе, это означает, что ваше посещение защищено с помощью TLS. MPC-TLS имитирует функциональность клиента TLS, позволяя аутентификатору Pado взаимодействовать с клиентом TLS для выполнения следующих задач: \
   Следует отметить, что эти операции, связанные с TLS, выполняются между клиентом и проверяющим через протокол двустороннего вычисления (2PC). Проектирование MPC-TLS основано на некоторых технологиях шифрования, таких как обфускационный схемы (GC), передача забывания (OT), IZK и т. д.
   • Установите TLS-соединение, включая вычисление основного ключа, ключа сеанса и информации для проверки.
   • Выполняйте запросы через канал TLS, включая генерацию зашифрованных запросов и расшифровку ответов сервера.
2. EXC: Интерактивное доказательство с нулевым разглашением — это доказательство с нулевым разглашением, в котором проверяющий и проверяющий могут взаимодействовать. В протоколе IZK результатом верификатора является принятие или отклонение утверждения доказывающего. По сравнению с простыми NIZK (такими как zk-STARK или zk-SNARK) протокол IZK имеет ряд преимуществ, таких как высокая масштабируемость для больших заявок, низкие вычислительные затраты, отсутствие необходимости в доверенной настройке и минимальное использование памяти.

Pado активно развивает kyc hook Uniswap, ищет больше данных о сценариях приложений on-chain и был выбран в первую партию программы стипендии Consensys.

6. Перспективы на будущее

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

Из одной лишь стороны спроса ZK-сопроцессор необходим. С точки зрения только трека DEX, этот хук имеет большой потенциал и может делать многое. Если у sushiswap нет хуков, он не сможет конкурировать с uniswap, и он будет очень скоро исключен. Если zkcoprocessor не используется для хуков, газ будет очень дорогим для разработчиков и пользователей, потому что хуки вводят новую логику и делают смарт-контракты более сложными, что является контрпродуктивным. Поэтому на данный момент использование zk coprocessor является лучшим решением. Как с точки зрения захвата данных, так и расчетов, у различных методов есть различные преимущества и недостатки. Сопроцессор, подходящий для конкретных функций, - это хороший сопроцессор. Рынок проверяемых вычислений на цепи имеет широкие перспективы и будет отражать новую ценность в более широких областях.

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

Представьте себе сценарий в будущем: используя высокую надежность и конфиденциальность ZK для проверки данных, водители онлайн-такси могут построить сеть агрегации в дополнение к своим собственным платформам. Эта сеть передачи данных может охватывать Uber, Lyft, Didi, bolt и т. Д., Водители онлайн-такси могут предоставлять данные на своих собственных платформах. Вы берете кусочек, я беру кусочек и собираю его вместе в блокчейне. Постепенно создается и агрегируется сеть, независимая от собственной платформы. Все данные о водителях стали крупным агрегатором данных об онлайн-такси, и в то же время они могут сделать водителей анонимными и не допустить утечки их конфиденциальности.

7. Индекс

https://blog.axiom.xyz/what-is-a-zk-coprocessor/

https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA

https://dev.risczero.com/api

https://blog.uniswap.org/uniswap-v4

https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/

https://lagrange-labs.gitbook.io/lagrange-labs/overview/what-is-the-lagrange-protocol

https://docs.herodotus.dev/herodotus-docs/

https://docs.padolabs.org/

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

1. Эта статья перепечатана из [ForesightResearch]. All copyrights belong to the original author [Майк]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Учитькоманда, и они быстро справятся с этим.
2. Ответственность за отказ: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.