Разбираем технические преимущества сопроцессора Ethereum ZK Axiom

Автор: Маск Сеть

На саммите ETHShanghai 2023 основатель Axiom Йи Сун представил сопроцессор Ethereum ZK Axiom и его важность с точки зрения доступа к данным и вычислительной мощности. Axiom реализует расширение доступа к данным и вычислений с помощью концепции операции Reflection и реализует достоверность запроса, проверяя цепочку хэшей и поддерживая кэш. Приложения для Axiom включают в себя дорогостоящие приложения, доступ к большим объемам данных, приложения, основанные на протоколах управления историческими данными, и многое другое. Благодаря Axiom смарт-контракты могут получать больше данных и вычислительную мощность, что еще больше способствует развитию приложений Ethereum.

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

Во-первых, давайте разберемся, как пользователь фактически получает доступ к информации Ethereum. Когда мы впервые использовали Ethereum, мы получали информацию о том, что происходит в сети, через вызовы JSON-RPC для архивирования аннотаций. Цель API JSON-RPC — предоставить пользователю информацию об истории сети. По сути, вся информация, которую мы видим о блокчейне, извлекается из этих вызовов API и представляется в виде записи на веб-сайте для чтения пользователем.

Теперь, когда пользователи становятся более искусными во взаимодействии с блокчейном, нам начинают требоваться все более сложные представления цепочки. Поэтому для разных компромиссов пользователей разрабатываются разные типы архивных узлов. Итак, были Geth, Erigon, Nethermind, а теперь и Reth. Мы можем выбрать наиболее подходящий узел архива в соответствии с нашими потребностями.

Если пользователей не устраивает отдельный API JSON-RPC, можно выбрать индексатор для применения постобработки при отслеживании транзакций. Для разных приложений пользователям могут быть интересны данные, возвращаемые из The Graph или Covalent.

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

Теперь, если мы подумаем об этом не с точки зрения пользователя, а с точки зрения смарт-контракта на Ethereum. Конечно, контракты также хотят иметь доступ к данным и выполнять над ними вычисления, но это более сложная задача. На самом деле, если мы зайдем в OpenSea и посмотрим на список CryptoPunk, мы обнаружим, что из всей информации на странице только небольшая часть доступна в смарт-контракте в цепочке.

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

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

То, что строит Axiom, — это то, что она называет сопроцессором Ethereum (ZK Coprocessor), который позволяет определенным смарт-контрактам ненадежно делегировать нашу систему вне сети, чтобы они могли делегировать Axiom чтение данных и поддающиеся проверке вычисления. Чтобы отправить запрос к Axiom, смарт-контракт может отправить транзакцию в нашу систему в сети. Наш автономный узел получит транзакцию и сгенерирует результат на основе исторического запроса Ethereum, а также прикрепит доказательство с нулевым разглашением, чтобы доказать правильность результата. Наконец, мы проверяем результаты в цепочке и достоверно передаем результаты нижестоящим смарт-контрактам.

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

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

Первая часть — это чтение, то есть то, как вводятся запросы Axiom — мы можем надежно читать исторические данные по цепочке.

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

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

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

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

Итак, каковы преимущества Reflection?

Мы можем взять блок текущего Эфириума и вернуться к предыдущему интересующему нас блоку. Если мы получим заголовки блоков между прошлым блоком и текущим блоком, мы можем отменить фиксацию прошлого блока в текущем блоке, проверив хеш-путь между этими заголовками блоков. Затем, если нас интересует какая-то информация из прошлого блока, мы можем предоставить доказательство включения в обязательство этого блока. В частности, это может быть доказательство Merkle Patricia Trie того, что информация существует в дереве состояний блока, дереве транзакций или дереве получения. В EVM, по крайней мере в принципе, доступ к любой прошлой информации о цепочке возможен только через знание последних хэшей блоков.

К сожалению, делать это в EVM дорого. Как только что упоминалось, вы должны проверить хеш-цепочки и доказательства Меркла для всех заголовков блоков, что включает в себя множество хэш-вычислений Keccak для большого объема данных. Поэтому, как только вы вернетесь в прошлое, это станет очень сложно. Поэтому мы применяем операцию Reflection, обернув это доказательство ZK в EVM. Таким образом, вместо того, чтобы помещать все прошлые заголовки блоков и все эти доказательства Меркла в цепочку, а затем проверять их, мы проверяем с нулевым разглашением, существует ли последовательность прошлых заголовков блоков и некоторые доказательства проверки.

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

Позвольте мне кратко коснуться компромиссов концепции работы Reflection на основе ZK.

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

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

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

Затем мы рассмотрим, как реализовать операции Reflection с помощью Axiom.

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

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

Еще одна особенность, которую мы добавляем, — горный хребет Меркле. Он построен поверх этого кэша хэшей блоков, структуры данных, которая позволяет нам ссылаться на каждый хэш блоков в Ethereum в ограниченной ДНК.

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

Теперь давайте поговорим о возможных применениях предполагаемой операции Reflection.

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

Таким образом, первый тип приложения — это приложение, которое Axiom или любой другой тип механизма работы Reflection может быть реализован на Ethereum, но стоимость немного выше.

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

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

Например, интересное приложение позволяет Roll-up на Ethereum считывать состояние базового уровня или другого Roll-up доверенным образом, используя для взаимодействия нулевое знание. Одним из таких приложений может быть разрешение Roll-up считывать моментальные снимки полного баланса токенов ERC20.

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

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

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

Наконец, если мы действительно поднимемся на уровень вычислений, мы думаем, что может быть очень интересно использовать модели машинного обучения для настройки параметров в цепочке. Если вы думаете о традиционных финансовых приложениях, очень часто моделируют сложные будущие параметры на основе больших объемов исторических данных, таких как данные о ценах, экономические данные и т. д. И когда мы смотрим на текущий уровень DeFi, он далек от достижения этого уровня. Я не думаю, что DeFi должен работать точно так же, как традиционные финансы, но мы считаем, что внедрение некоторых исторических баз данных и моделей и информации на основе машинного обучения может помочь создать более динамичный протокол DeFi.

Это всего лишь несколько идей о том, что операции Reflection могут принести блокчейну.