Исследуйте кроссчейн коммуникации с точки зрения объединения

Автор: Лиза А., Taiko Labs, перевод: Jinse Finance xiaozou

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

1. Введение в межсетевой обмен сообщениями

Для межсетевого взаимодействия все стороны (L2, L3 и т. д.) должны иметь прямой доступ к последнему корню состояния Ethereum.

Все слои депозита имеют «встроенный» механизм кроссчейна, который можно использовать для доступа к корню состояния L1, который будет передан на L2 в качестве сообщения о депозите.

1**.1** Два типа доступа к корню состояния

Тип 1: Чтение корня состояния напрямую — можно выполнить с помощью кода операции или предварительно скомпилировать. Однако до сих пор он не реализован, поэтому доказательств не требуется.

Брехт Девос описывает возможный метод прямого считывания состояния в исследовательской статье: "... мы можем предоставить предварительно скомпилированный контракт, который может напрямую вызывать смарт-контракт в целевой цепочке. Это предварительно скомпилированное непосредственно в исходной цепочке вставляет и выполняет код смарт-контракта другой цепочки. Это гарантирует, что смарт-контракты всегда имеют доступ к последнему доступному состоянию эффективным и легко доказуемым способом».

· Также описано в RFP компании Optimism "Подтверждение концепции удаленного статического вызова".

Тип 2: Генерация доказательств — т. е. подтверждение утверждения об одной цепочке блоков в другой цепочке блоков.

«Перекрестный обмен сообщениями с доказательствами» имеет два подхода:

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

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

1**.2** Метод «Перекрестный обмен сообщениями с подтверждением»

1.2.1 Обмен сообщениями между цепочками облегченных клиентов

Докажите данные по цепочке B

Получить данные доказательства Меркла из полного узла цепочки B (архивировать узел архивации, если требуется доказательство хранения для определенных исторических состояний);

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

Проверочный контракт вычисляет хэш-значение блока на основе данных заголовка блока, запрашивает смарт-контракт легкого клиента в цепочке A (отслеживает хеш-значение блока цепочки B) и проверяет, является ли хеш-значение допустимым;

Данные подтверждения сверяются с корнем состояния bytes32 в заголовке блока.

1**.2.2** Доказательство хранения

Proof of Storage имеет два варианта «рабочего процесса»:

· Создать доказательство хранения → использовать в цепочке

· Создать доказательство хранения → создать доказательство zk → использовать в цепочке

Объект также может упаковать несколько наборов доказательств в одно доказательство (как доказательство хранения, так и доказательство zk). Это необязательный шаг оптимизации, который пока не обсуждается.

Давайте рассмотрим три основных этапа «рабочего процесса» доказательства хранилища: создание доказательства хранилища, создание доказательства zk и его использование в цепочке.

(1) Создать подтверждение хранения

· Доказательство хранения позволяет нам использовать конфиденциальное обязательство, чтобы доказать, что определенная информация существует в блокчейне и является достоверной;

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

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

Чтобы проверить Proof of Storage, получатель может использовать предоставленные данные и путь Merkle или Verkle для повторного вычисления корневого хэша. Если пересчитанный корневой хэш совпадает с известным корневым хэшем, получатель может быть уверен, что данные являются подлинными и являются частью отправленного набора данных.

(2) Создать ZKP (доказательство с нулевым разглашением)

Тем не менее, доказательство хранения типа Ethereum составляет около 4 КБ — довольно много для публикации всего доказательства хранения в целевой цепочке, поскольку проверка доказательства будет очень дорогой. Поэтому разумно использовать ZKP (например, ZK-SNARK) для сжатия, что может уменьшить размер доказательства и удешевить его проверку.

（3）А****рулон ЗКП

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

Развернуть можно следующим образом:

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

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

** Хранение вне сети: ** Храните данные вне сети и размещайте определенные блоки данных в сети по запросу. Это актуально для решений, которым по какой-то причине необходимо хранить большие объемы данных (например, узлы архива Ethereum из блока генезиса). Минусы: то же, что и сжатие в цепочке; плюсы: дальнейшее снижение стоимости данных.

1**.2.3** Доверенная третья сторона

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

1**.2.4** «Универсальная» система доказательств

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

1**.2.5 Некоторые неизвестные проблемы обмена сообщениями ZK****межсетевой сети**

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

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

2**、Пример кроссчейн решения для обмена сообщениями**

· Su****ccinct Labs использует облегченный клиент для проверки консенсуса от исходной цепочки до уровня консенсуса целевой цепочки. Идея состоит в том, что существует легкий клиентский протокол, гарантирующий, что узлы могут синхронизировать заголовки блоков конечного состояния блокчейна. ZKP используется для создания доказательств консенсуса.

· La****grange Labs создает неинтерактивное кросс-чейн доказательство состояния. Лагранж доказывает, что сеть отвечает за создание корня состояния. Каждый узел Лагранжа содержит часть закрытого ключа шарда, который свидетельствует о состоянии конкретной цепочки. Каждый корень состояния — это пороговый подписанный корень Verkle, который можно использовать для подтверждения состояния конкретной цепочки в определенное время. Корень состояния является полностью общим и может использоваться в доказательстве состояния для проверки текущего состояния любого контракта или кошелька в цепочке.

· He****rodotus использует ZKP Proof of Storage для предоставления смарт-контрактов и синхронного доступа к данным в цепочке других уровней Ethereum. Для проверки он использует собственный обмен сообщениями L1<>L2 для синхронизации хэшей блоков между свертками Ethereum.

=ноль; Foundation (Mina, L1) позволяет смарт-контрактам на Ethereum проверять действительность состояния Mina. Создайте специальное доказательство состояния, дешевое для проверки на Ethereum (локальные доказательства Mina на Ethereum дороги). Гипотетически (когда-нибудь в будущем) приложения могут напрямую использовать инструмент генерации доказательств Mina для проверки действительности транзакций между цепочками. =nil; У Foundation также есть Proof Market, где пользователи/проекты могут в первую очередь покупать/продавать доказательства SNARK, которые разрешают ненадежный доступ к данным.

Аксиома: Если Axiom до сих пор сгенерировал ZKP для леджера — ему не нужно генерировать ZKP для конкретного блока — он может передать этот ZKP в цепочку (как ретранслятор) или даже предоставить доступ к это ЗКП.

3. Межсетевой обмен сообщениями L2

• Отказ от ответственности: обмен сообщениями между сетями все еще развивается для большей части L2. Весь приведенный ниже анализ основан на информации из открытых источников. Тем не менее, решения, упомянутые в статье, могут находиться на стадии исследования и тестирования, и в процессе объединения могут быть использованы другие методы. *

**（1）**Тайко

Taiko хранит хэши блоков для каждой цепочки. Для каждой пары цепочек он развертывает два смарт-контракта, в которых хранятся хэши друг друга. В примере L2 ←→L1 каждый раз, когда на Taiko создается блок L2, хеш-значения периферийных блоков на L1 сохраняются в контракте TaikoL2. Также в случае L1 ←→L2 режим работы такой же.

Последний известный корень Merkle, хранящийся в целевой цепочке, можно получить, вызвав getCrossChainBlockHash(0) в контракте TaikoL1/TaikoL2 и получив значение/сообщение для проверки. Родственный хэш последнего известного корня Merkle можно получить, вызвав запрос eth_getProof с использованием стандартного RPC в «исходной цепочке».

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

**(2)**Старкнет

Starknet использует Proof of Storage для ненадежного обмена сообщениями между сетями.

Протокол обмена сообщениями L2→L1

· Во время выполнения транзакции Starknet контракт в Starknet отправляет сообщение L2→L1.

Параметры сообщения (содержащие контракт получателя и связанные данные на уровне L1) затем добавляются к соответствующему обновлению состояния (дерево основного хранилища).

· Сообщения L2 хранятся на L1 смарт-контракта.

· Выдать событие на L1 (сохранить параметры сообщения).

Адреса получателей на L1 могут получить доступ к сообщению и использовать его как часть транзакции L1 путем повторного предоставления параметров сообщения.

· Сообщения кросс-чейна хранятся в магистральном дереве.

L2 → L1

L1 → L2

**（3）**Оптимизм

Связь между L1 и L2 осуществляется с помощью двух специальных смарт-контрактов, называемых «мессенджерами».

· Для транзакций Optimism (L2) в Ethereum (L1) необходимо предоставить доказательство Merkle сообщения на L1 после записи корня состояния. После того, как эта подтверждающая транзакция становится частью цепочки L1, начинается период проверки ошибок. После этого периода ожидания любой пользователь может «завершить» транзакцию, инициировав вторую транзакцию в Ethereum, отправив сообщение целевому контракту L1.

· Сообщения между цепочками хранятся в магистральном дереве.

（4）Ар****битрум

Билеты с повторной попыткой — это канонический метод, который Arbitrum использует для создания сообщений L1-L2, т. е. транзакций L1, которые инициализируют сообщения для выполнения на L2. Retryable может быть отправлен на L1 за фиксированную плату (зависит только от размера его calldata). Основное дерево состояний используется для межсетевой связи пользовательских форматов данных в смарт-контрактах. Отправка повторно запрашиваемого билета на L1 отделена/асинхронна от выполнения на L2. Retryables обеспечивают атомарность между операциями между цепочками. Если запрос транзакции L1 отправлен успешно (т. е. без отката), то повторное выполнение на L2 имеет сильную гарантию того, что оно в конечном итоге будет успешным.

У Arbitrum есть два ствола: Цепь Nitro поддерживается в формате дерева состояний Ethereum, дерева Меркла. Дерево утверждений хранит состояние цепочки Arbitrum, подтвержденное в Ethereum через «утверждение». Правила, которые продвигают цепочку Arbitrum, детерминированы. Это означает, что при заданном состоянии цепочки и некоторых новых входных значениях есть только один допустимый выход. Следовательно, если дерево доказательств содержит несколько листьев, не более одного листа может представлять допустимое состояние цепочки.

Система исходящих сообщений Arbitrum допускает любой вызов контракта с уровня 2 на уровень 1, то есть сообщение инициируется с уровня 2 и, наконец, выполняется на уровне 1. Сообщения L2-L1 (также известные как «исходящие сообщения») имеют много общего с сообщениями L1-L2 Arbitrum (повторяемые), хотя есть некоторые заметные различия. Часть состояния L2 цепочки Arbitrum, то есть та часть, которая засвидетельствована в каждом блоке RBlock, является корнем Merkle всех сообщений L2–L1 в истории цепочки. После подтверждения проверенного RBlock (обычно примерно через неделю после подтверждения) корень Merkle включается в контракт Outbox и публикуется в L1. Затем контракт Outbox позволяет пользователям выполнять свои сообщения.

**（5）**Полигон zkEVM

· Мост SC этого zkEVM использует специальное дерево Меркла, называемое деревом выхода, для каждой сети, участвующей в обмене данными или транзакции актива.

Он использует корни Merkle (в отдельном дереве состояний), схему архитектуры моста можно найти на github.

Развертывание zkEVM Bridge SC внесло несколько изменений на основе депозитного контракта Ethereum 2.0. Например, он использует специально разработанное дерево Меркла только для добавления, но использует ту же логику, что и депозитный контракт Ethereum 2.0. Другие отличия относятся к базовым хэшам и листовым узлам.

Главной особенностью смарт-контракта Polygon zkEVM Bridge является использование дерева выходов и глобального дерева выходов, где корень глобального дерева выходов является основным источником состояния истинности. Следовательно, L1 и L2 имеют два разных корневых менеджера глобальных выходов, а Bridge SC имеет отдельную логику.

（6）Черт возьми

· Мостовые контракты, развернутые на Ethereum и Scroll, позволяют пользователям передавать произвольные сообщения между уровнями L1 и L2. В дополнение к этому протоколу обмена сообщениями мы также создали не требующий доверия протокол моста, позволяющий пользователям соединять активы ERC-20 между уровнями L1 и L2. Чтобы отправить сообщение или средства из Ethereum в Scroll, пользователь вызывает транзакцию sendMessage в контракте Bridge. Релейеры проиндексируют эту транзакцию на L1 и отправят ее заказчику для включения в блоки L2. В бридж-контракте L2 процесс отправки сообщения из Scroll обратно в Ethereum аналогичен.

· Межсетевые сообщения хранятся в обычных очередях сообщений. Заказчик принимает межсетевые сообщения из этой очереди и добавляет их в цепочку как обычные транзакции.

**（7）**Эра zksync

• Отказ от ответственности: содержание в этом разделе касается только zksync Era, что может отличаться от межсетевого обмена сообщениями в ZK Stack, который представляет собой модульную структуру для построения независимой суперцепи ZK. *

· Каждый пакет транзакций имеет одно сообщение L2->L1.

· Невозможно отправлять транзакции напрямую из L2 в L1. Однако вы можете отправлять сообщения любой длины из zkSync Era в Ethereum, а затем обрабатывать полученные сообщения в Ethereum с помощью смарт-контракта L1. zkSync Era имеет функцию подтверждения запроса, которая возвращает логический параметр, указывающий, было ли сообщение успешно отправлено на L1. Получите доказательство Меркла, содержащееся в сообщении, наблюдая за Ethereum или используя метод zks_getL2ToL1LogProof API zksync-web3.

· Для L1→L2 смарт-контракт zkSync Era позволяет отправителю запросить транзакцию в Ethereum L1 и передать данные в zkSync Era L2.

· Бридж-контракт:

4. Вывод

Кроссчейн-коммуникация является неотъемлемой частью «обязательных» приложений для массового внедрения блокчейна (например, межсетевой кошелек социального восстановления, описанный в статье Виталика). Большинство кроссчейн-решений, используемых в настоящее время, предназначены для L1 ←→L2, чтобы покрыть функцию вывода средств. Эти решения могут быть распространены на большее количество блокчейнов. Но в то же время могут быть реализованы более продвинутые решения для межсетевой связи, такие как «состояние прямого чтения» без доказательства вообще или «доказательство хранения» без доверия. Для большинства L2 все еще есть возможности для улучшения межсетевого взаимодействия.