Мы начинаем с типового случая асинхронного вывода с исходного роллапа на L1 и ручного моста в целевой роллап, и заканчиваем гипотетической архитектурой для кросс-роллапной комбинируемости внутри одной транзакции. Мы исследуем, как каждый уровень совместимости повлияет на опыт пользователя, опыт разработчика, потенциал MEV и сами роллапы (в частности, связанные с изменениями инфраструктуры).
Мы остаемся в основном в рамках Ethereum и его L2s для этой статьи и фокусируемся исключительно на ненадежной совместимости. В данном случае «ненадежная совместимость» относится к протокольным каналам, которые не требуют участия сторонних лиц для облегчения передач вне необходимой инфраструктуры, которая уже требуется для большинства rollups.
Ключевые общие компоненты инфраструктуры, которые могут продвинуть нас по лестнице ненадежной совместимости, - это общие последователи, суперстроители и общая урегулирование. Гарантии и новые функции, открываемые этими общими слоями, связаны, но в основном ортогональны по своей природе.
Общие секвенсоры/Суперстроители: Прежде всего улучшения скорости и пользовательского опыта.- Совместное регулирование: Обмен активами без внешней обертки, а также сообщения в протоколе.Для начала мы сначала определим шесть уровней ненадежной совместимости, на которые намекнуто во введении:
L1 Асинхронно: → Совместимость через ручной перевод активов через L1, к которому применяются rollups.- Атомная включенность: Гарантия того, что либо все транзакции в пакете межсетевого взаимодействия будут включены в следующий блок для каждого роллапа, участвующего в пакете, либо ни одна не будет включена.- Общий регулирование: → Несколько роллапов, подключенных к L1 через тот же контракт моста.- Атомарное выполнение: Гарантия того, что либо все транзакции в пакете межсетевого сворачивания будут включены и успешно выполнены в следующем блоке для каждого свертывания, вовлеченного в пакет, либо ни одна из них не будет выполнена. Успешное выполнение означает, что каждая транзакция будет выполнена без отката и будет отражена в обновленном состоянии для каждого свертывания в пакете.- Блочная совместимость на уровне блока: → Следующий блок гарантирует переход на перекрестные связанные пакеты, которые могут содержать зависимые транзакции (tx B на rollup B зависит от результата tx A на rollup A)- Tx-Level Composability: Уровень взаимодействия на уровне смарт-контрактов, требующий всего одной транзакции, которая может вызвать изменения состояния одновременно во многих роллапах (без пакетов). Использование любого протокола на любом роллапе логически эквивалентно использованию различных смарт-контрактов на одной цепочке. Важно отметить, что это подразумевает, что изменения состояния до любого вызова могут быть отменены при его возврате.Для более глубокого понимания каждого уровня мы пройдемся по следующим ключевым случаям использования, чтобы продемонстрировать мощь каждого уровня, а также последствия для пользователей, разработчиков, роллапов и исследователей MEV.
→ Отправить себе: Обмен Eth на Eth или ERC-20 на ERC-20 между двумя роллапами- Покупка токенов → Перекрестный лимитный ордер Rollup: Используя Eth/ERC-20 с Rollup A, приобретите другой ERC-20 на DEX на Rollup B и (по желанию) отправьте обратно на Rollup A## Последствия:Следующие вопросы также будут рассмотрены для более глубокого понимания влияния на ключевых заинтересованных сторон в любой экосистеме rollup.

Обзор изменений для ключевых заинтересованных сторон
Как определено, это относится к текущему режиму ненадежной совместимости по умолчанию. Все роллапы определяются таким образом, потому что они построены на уровне L1 в качестве расчетного слоя и имеют доступ к этому уровню L1 только через контракты моста, где они периодически публикуют обновления состояния для обеспечения безопасности сети.
Единственный канонический способ выполнения любой ненадежной кросс-роллап активности в этом случае - вывести активы из исходного роллапа через канонический мост и вручную внести их в целевой роллап, как только они станут доступны на L1.
Для оптимистичных роллапов задержка вывода составляет ~7 дней, чтобы учесть окно доказательств недостоверности. В ZK роллапе задержка вывода менее определенна, но может составлять от 15 минут до полного дня, как в случае с ZkSync.
Кроме того, обмены между двумя участниками с использованием смарт-контрактов возможны, но это меньший случай использования и не масштабируется эффективно.
СтОит отметить решения третьих сторон, которые в настоящее время существуют:
Отправить самому себе:
Канонично: → Вывести активы из Rollup A → Вручную внести на Rollup B- Третья сторона: → Мост ликвидности / Сети решателейЛимитный ордер Cross-Rollup
Канонически: → Вывод активов из Rollup A → Вручную внести на Rollup B → Выполнить лимитный ордер → Чтобы отправить обратно, нужно было бы внешне обернуть целевой ERC-20- Третья сторона → Начинающееся пространство решений для ограниченных ордеров между rollup → Существуют открытые проекты, использующие намерения для облегчения этогоПоскольку это является стандартным случаем, нет необходимости обсуждать изменения в UX, DevEx, MEV и rollups.
Атомное включение гарантирует только то, что пакет межсетевого переноса будет включен в следующий блок.
Для этого требуется общий секвенсор, но теоретически это можно сделать и без него вручную, если секвенсоры на двух заданных роллапах не работают на максимальной пропускной способности (можно просто отправить две транзакции на каждый роллап индивидуально). Поэтому мы добавили звездочку к необходимой инфраструктуре.
Однако мы не предполагаем, что общий последователь будет запускать полный узел каждого из подключенных роллапов, поэтому не можем гарантировать успешное выполнение пакета транзакций. В этом случае общий последователь может гарантировать только то, что транзакции будут правильно сформированы и будут включены в следующий блок, но не обязательно, что они будут успешно выполнены.
Поскольку нет гарантий выполнения, невозможно программно воспользоваться атомным включением каким-либо осмысленным способом, не рискуя откатом одной из транзакций. В результате мы фактически находимся в точно такой же ситуации, как и совместимость L1 Async.
Рассмотрите инициирование простого обмена между роллапами с гарантией атомарного включения:
Любое решение совместимости, будь то мост ликвидности, фреймворк намерений или обмен xERC-20, будет уязвимо для этого риска, и его невозможно уменьшить. Из-за этого риска текущие решения требуют, чтобы инициирующая транзакция была успешно выполнена и включена в блок на цепочке-источнике перед использованием релеев для передачи отправленного сообщения и выполнения второй транзакции на цепочке-назначении.
Важный момент: Атомное включение не оказывает существенного влияния на потенциал совместимости
Здесь начинается что-то более интересное. В результате общего контракта моста все ликвидные средства, внесенные в экосистему роллапа из L1, могут свободно перемещаться между всеми подключенными роллапами. До этого момента мы не могли совершать обмены между роллапами без прохождения через канонические каналы, внешнюю обертку активов или использования решения третьей стороны.
Зачем создавать общий контракт моста? Чтобы понять, почему наличие общего контракта моста позволяет нам безопасно перемещать активы между роллапами, сначала рассмотрим, что произойдет, если будет возможность иметь Eth в Роллапе A, сжечь его и эмитировать его нативно на Роллапе B без общего контракта моста на L1.

Мы видим, что каждый роллап будет рассинхронизирован с их контрактом моста в основной сети. Контракт моста Rollup B по-прежнему имеет 50 Eth, поэтому пользователь не сможет вывести свой 1 ETH на L1.
Для решения этой проблемы создаются внешние протоколы обертывания активов, которые выпускают внешне обернутую версию токенов через роллапы, символизирующие местное версию где-то в другом месте сети.
С общим слоем расчетов ситуация выглядит иначе. Поскольку вся ликвидность для каждого подключенного роллапа заблокирована в том же мостовом контракте, можно свободно перемещаться между роллапами, поскольку общая сумма ценности в мостовом контракте остается неизменной и всегда может быть выведена.
На уровне контракта L1 действительно нужно обновление о*где *ликвидность заключается в возможности пользователей выводить средства откуда угодно, но это тривиально, потому что все подключенные роллапы могут читать/писать в общий контракт.
С общим слоем расчетов поток может выглядеть следующим образом для простого случая отправки самому себе.
Отправить самому себе:
Можно представить общий контракт моста как уровень внутрипротокольного обмена сообщениями между всеми подключенными роллапами, поэтому теоретически этот поток фактически может быть расширен до любого произвольного стандарта обмена сообщениями.
Это приближает нас к композиции, но из-за необходимых шагов агрегирования доказательств и передачи сообщений только после того, как изменения состояния отражены на L1, есть большие задержки (хотя заметно ниже, чем в случае асинхронного L1). Кроме того, любая сложная активность между роллапами, например использование DEX на роллапе B, начиная с активов на роллапе A для кросс-роллапного лимитного ордера, все равно будет трудным процессом для пользователя, так как им все равно придется отправлять себе и вручную обменивать активы на целевом роллапе. В этом случае нельзя создать атомные кросс-роллапные пакеты.
Еще одно важное преимущество общего расчета заключается в том, что у поставщиков ликвидности или решателей, которые исполняют ордера в нескольких средах, меньше трения. Поскольку их ликвидность на всех подключенных rollups отражается в одном и том же мостовом контракте, им не нужно ждать полного окна вывода, чтобы управлять своей ликвидностью между rollups.
Теперь можно передавать активы в их первоначальной форме без периода вывода L1- Разработчики: Изменения ограничиваются эмитентами токенов, которые теперь могут использовать сообщения в протоколе для выпуска собственных версий ERC-20 на всех подключенных роллапах- Поисковики MEV: Поскольку это происходит на протяжении нескольких блоков для каждого роллапа, нет нового потенциала MEV- Роллапы: Роллапсы должны будут выбрать использование общего контракта моста и, вероятно, добавить предварительные компиляции для обработки сообщений между роллапсамиВажный момент: Общий расчет позволяет осуществлять передачу активов без внешней обертки и произвольную передачу сообщений по всем роллапам, использующим контракт моста и слой агрегации доказательств, но все равно будут иметься незначительные задержки (хотя и значительно меньше, чем на уровне L1 Async), и нельзя создавать атомные пакеты между роллапами.
Атомное выполнение позволяет нам гарантировать успешное выполнение пакетов межсетевого взаимодействия, но как мы увидим, количество случаев использования пакетов межсетевого взаимодействия, не имеющих зависимых транзакций, меньше, чем можно было бы ожидать.
Если любая отдельная транзакция в пакете зависимых транзакций отменяется, то все остальные транзакции становятся недействительными и также должны быть отменены, как это происходит с сжиганием и выпуском токенов через роллапы. Выпуск токенов на целевом роллапе зависит от их сжигания или блокирования на исходном роллапе, поэтому мы можем сказать, что пакет транзакций по сжиганию и выпуску является пакетом зависимых транзакций.
Создание этого пакета невозможно без посредника, такого как суперстроитель, который может создать целевую транзакцию.
Подумайте, что должно быть верным для создания пакетов обмена между роллапами без участия другой стороны, кроме пользователя. Для этого нужно создать пакет для блокировки/сжигания актива на исходном роллапе и выпуска актива на целевом роллапе, но возникают проблемы:
Однако по-прежнему существует несколько случаев использования атомного выполнения без зависимых пакетов межроллапных перекрестных связей. Одним из них является арбитраж междуроллапами:

Перекрестный арбитраж DEX между роллапами с атомным исполнением
Поскольку между этими транзакциями нет строгих зависимостей, любой может создать этот атомарный пакет и отправить его в общий последователь, который гарантирует атомарное выполнение.
Однако, чтобы иметь гарантии атомного исполнения в первую очередь, роллапы должны выбирать общий секвенсор и суперстроителя, который будет запускать полные узлы всех подключенных роллапов, поэтому шаг от атомного исполнения к блочной комбинируемости довольно мал и все общие решения по синхронизации будут это делать. Единственное изменение, которое требуется, заключается в том, что строитель блоков или другая третья сторона должны иметь возможность создавать транзакции от имени пользователя для завершения зависимых пакетов межроллапного взаимодействия.
Маловероятно, что будет построена инфраструктура, которая позволит только атомное выполнение без перехода к более продвинутому уровню композиции. Относительное преимущество перехода к полной композиции на уровне блока значительно превышает сложность достижения этого, учитывая, что инфраструктура уже имеет атомное выполнение.
Вероятно, никаких изменений не будет, хотя возможно, что решения от третьих сторон, такие как намерения, могут быть атомарными, но конкретно, как это происходит, неясно- Разработчики: Вероятно, никаких изменений- Поисковики MEV: Арбитраж межсетевого обмена гораздо безопаснее благодаря атомному выполнению- Rollups: Rollups должны согласиться использовать общий последователь/superbuilders, отправляющий блоки с транзакциями от каждого rollup, желающего взаимодействовать, что может изменить структуру доходов rollup. Пока не ясно, как это изменит.- Последовательность рынков может увеличить доход от роллапов, позволяя опытным строителям покупать пространство ToB.Важный вывод: Несмотря на то, что пакеты кросс-роллапа гарантированно выполняются атомарно, неясно, как эти пакеты будут построены, если нет суперконструктора, создающего часть пакета, поэтому маловероятно, что атомарное выполнение само по себе повлияет на совместимость. Общие секвенсоры/суперстроители должны по умолчанию выполнять сборку для компонуемости на уровне блоков.
(* = optional)
В большей части дискуссий о совместных последовательностях и общих слоях расчетов термин, который часто используется для описания этого уровня совместимости, - это "синхронная компоновка".
Мы немного изменили этот термин, чтобы сделать его более описательным. Обновление номенклатуры до уровня блока предполагает, что возможно составлять между двумя роллапами в пакете транзакций между роллапами, которые будут включены и успешно выполнены в следующем блоке. Синхронная составляемость может быть перепутана с составляемостью на уровне транзакции, которую мы рассмотрим в следующем разделе. Важно, что для этого требуется посредник (общая инфраструктура последовательности), который может быть дирижером и создателем зависимых пакетов транзакций.
На этом уровне мы начинаем видеть истинную совместимость между роллапами не только просто отправляя себе, чтобы участвовать в даппе на другом роллапе.
С добавлением общего последователя, который может создавать транзакции, мы теперь можем создавать пакеты между роллапами, которыми разработчики могут воспользоваться программно.
Есть два случая, которые следует рассмотреть:
С блочной композицией на уровне блоков у нас есть как преимущества атомного выполнения, так и возможность создавать зависимые пакеты транзакций. Давайте рассмотрим наши два иллюстративных примера.
Передача того же токена через xERC-20 (без общего расчета):
Давайте теперь рассмотрим ордер с лимитом для покупки ERC-20 на Rollup B с начальным (другим) ERC-20 с Rollup A и отправкой полученного ERC-20 обратно на Rollup A. В этом случае мы не предполагаем наличие общего слоя расчетов, хотя в случае с ним существует аналогичный поток. Единственное отличие заключается в том, что не требуется дополнительно обертывать активы.
Здесь требуемые транзакции в этом случае:

Ордер лимитного типа Cross-Rollup в среде комбинируемого уровня блоков
Поток:
В случае общей инфраструктуры совместного секвенирования без общего уровня расчетов, необходимо использовать внешнюю обернутую версию Eth и xERC-20, что может привести к худшим рыночным условиям на DEX из-за более слабых пулов ликвидности для обернутых активов. В этом случае пользователю может потребоваться использовать более мягкий лимит с более терпимым проскальзыванием и он может получить субоптимальные цены. Однако исключением является использование USDC. Возможно, что общий секвенсор без общего расчета может сотрудничать с Circle для получения эксклюзивных прав на контракты USDC через роллапы для облегчения нативных трансферов USDC и обменов через роллапы.
С общим расчетным слоем этот внешний обертывание не является необходимым и, вероятно, обеспечивает лучшие цены благодаря более глубоким пулам ликвидности для обмена исходными активами, но суть остается прежней.
Однако, чтобы выполнить этот полный пакет в одном блоке, все транзакции должны быть присутствовать в этом блоке, даже если транзакция представляет собой состояние, которое недопустимо до самого блока (например, наличие Eth на целевой цепи для обмена, если у пользователя нет ничего до блока). По этой причине мы должны доверять секвенсору, что он действительно включил допустимые зависимости в пакет межсетевого переноса. Чтобы доказать действительность каждой транзакции, можно представить доказательства после события.
Это немного менее важно при использовании обернутых активов, поскольку они не влияют на собственную ликвидность, хранящуюся в L1, но всё равно должны быть предусмотрены резервные механизмы, чтобы компенсировать риск злонамеренного последователя или ошибки в коде, позволяющей выполнить пакет транзакций с зависимой транзакцией, которая была отменена.
Массовые улучшения UX в разрешении лимитных ордеров между Rollup в одном блоке- Разработчики Для кросс-роллап-активности, вероятно, потребуется учитывать кросс-роллап, возможно, с использованием пользовательских предварительных компиляций. Вместо просто транзакций разработчики должны думать в терминах пакетов, но, вероятно, что суперстроители и пользовательская инфраструктура роллапа могли бы абстрагировать большую часть сложности для разработчиков.- Поисковики MEV Поисковики MEV имеют практически равные возможности использовать стратегии L1 на пакетах межроллап, но это зависит от того, как реализовано PBS (разделение предложителя-строителя). → Кросс-роллапные пакеты по сути рассматриваются как одна транзакция, поэтому МЭВ может быть обнаружен при фронтраннинге или сэндвичинге этих пакетов, пока они не перемещают цены за пределы допустимых величин проскальзывания (потому что тогда весь пакет будет отменен, и попытки МЭВ провалились)- Роллапы Необходимо будет подключиться к общей инфраструктуре последовательности (включая суперстроителей), а также разрешить доступ к сжиганию/чеканке Eth для общего последователя в случае общего уровня расчетов. Могут внедрить MEV, продавая блокпространство строителям## 6. Транзакционная композиция на уровне## Необходимая инфраструктура:Изменения на уровне VM // Общий расчет // Суперстроители
Композиционная надежность на уровне транзакций относится к тому же уровню функциональности, которую разделяют смарт-контракты на одной цепочке EVM. В этом случае одна транзакция может обновить состояние одновременно на нескольких роллапах и гарантировать, что любые изменения состояния до любого вызова могут быть отменены, если вызов завершается неудачно. Фактически, атомный набор транзакций в среде компоновки на уровне блоков может быть выполнен в рамках одной транзакции между роллапами и виртуальными машинами. Для этого требуются изменения на уровне виртуальной машины для всех подключенных роллапов, а также общий уровень расчетов и суперстроитель.
Мы опишем здесь возможный механизм на высоком уровне. (Насколько нам известно, эта конструкция принадлежит команде Espresso). Во-первых, пользователь отправляет транзакцию кросс-роллапа всем сверткам, состояние которых изменяется транзакцией, или суперконструктору, который может создавать блоки для всех задействованных сверток. Суперпостроитель имитирует транзакцию и формирует списки пар «ввод-вывод», по одному для каждого задействованного свертки, в которых указываются необходимые и ожидаемые сообщения перекрестного свертывания в транзакции. (Обратите внимание, что суперконструктор может сделать это только в том случае, если у него есть безопасные права на последовательность для всех задействованных сверток в течение определенного периода времени). Затем суперпостроитель отправляет смоделированный блок инициатору каждого объединения вместе со списками ожидаемых пар ввода-вывода для каждой транзакции перекрестного свертки. Во время выполнения каждый сверток выполняет свою собственную функцию перехода состояния в обычном режиме, предполагая, что входные данные из списка транзакций перекрестного свертывания верны. Во время расчета списки ввода-вывода могут быть перекрестно сопоставлены и проверены на этапе агрегирования доказательств на уровне общих расчетов. В частности, если какие-либо ожидаемые входные данные для транзакции перекрестного объединения не совпадают с тем, что было указано в другом объединении в качестве выходных данных, процесс сопоставления отклонит всю транзакцию перекрестного объединения.
Хотя с ограниченными новыми функциями, разблокированными с помощью композиции на уровне транзакций за пределами мгновенных кредитов, опыт разработчика по созданию приложений для перекрестного сворачивания может быть значительно улучшен. Возможность создавать dapps, взаимодействующие со всеми подключенными цепочками без размышлений о свертках перекрестного сворачивания, значительно упростит инновации в многосворачивающемся ландшафте. Кроме того, возможно, что в результате возникнут новые сценарии использования и поведение.
Для транзакционной совместимости существует много открытых вопросов дизайна. Например, как разработчики могут выбирать или отказываться от вызовов между роллапами для своих умных контрактов, нужно тщательно рассмотреть. Разрешение произвольной совместимости без ограничений означает, что мы возвращаемся к одному монолитному роллапу. Мы считаем, что здесь ответ заключается в том, чтобы разработчики явно указывали, где необходима совместимость между роллапами в своих контрактах, например, с помощью модификатора Solidity, типа Составнойкоторые помечают определенные точки входа в контракт как вызываемые через cross rollup.
Те же подразумевания, что и при компоновке на уровне блока, с дополнительными расширенными возможностями, такими как flashloans \
→ UX практически идентичен использованию одной цепи для даппов, которые выбирают вход- Разработчики:
Опыт разработчика значительно улучшается, поскольку разработчики dapp могут нативно вызывать контракты между роллапами и использовать результаты этих вызовов, как одиночные вызовы роллапа
→ Инфраструктуре Superbuilder/Sequencer по-прежнему придется размещать транзакции в блоках для роллапов, на которые влияет вызов междуроллапов, но не придется создавать те же пакеты, что и в случае композиции на уровне блока.- Поисковики MEV:
Высокий потенциал MEV, поскольку пакеты перекрестной свертки теперь практически эквивалентны отдельным транзакциям на одной цепи- Роллапы:
Требуется изменение уровня ВМ, а также согласие на общий последователь и общий уровень расчетов
Дополнительные предположения о доверии заключаются в необходимости доверять входам и выходам для других роллапов перед тем, как можно будет проверить состояние с помощью доказательств, но механизмы штрафов могут снизить бремя доверия## Сводка и карта экосистемыПосле того как мы разобрали технические детали каждого уровня совместимости, определенные здесь, мы можем сделать вывод:

Карта экосистемы
Кроме того, стоит отметить, что это относится к текущему росту популярности в среде приложений о приложениях. Приложения - это долгосрочные L2, которые либо обобщены, либо имеют разрешение с целью изоляции конкретных связанных протоколов на одном L2. Вероятно, что когда мы достигнем уровня блока, мы также начнем видеть значительный рост популярности сред среды приложений в результате наличия естественной совместимости между всеми подключенными сетями.
В настоящее время все еще сложно обеспечить ликвидность для этих приложений, но как только более крупная цепь подключится в качестве входа в совместимую среду, скорее всего, мы увидим огороженные садовые экосистемы вокруг общей инфраструктуры.
Другим важным открытым вопросом является то, как урегулируется дизайн-пространство вокруг суперстроителей. Работа в этом направлении все еще довольно молодая, и пока не ясно, каким будет наиболее эффективный и эффективный способ создания сети искусных строителей, способных создавать пакеты межсетевого связывания. Где эти пакеты межсетевого связывания оптимально будут включены в блок, и влияние на доход от межсетевого связывания остается открытым вопросом, и многие команды изучают различные стратегии.
В конечном итоге будущее, скорее всего, будет включать в себя комбинацию внутрипротокольных и внепротокольных мостовых решений, и они будут работать в тандеме, чтобы обеспечить гораздо более эффективный процесс совместимости для всех. Мы считаем, что прогресс, описанный в этой статье, может служить руководством как для разработчиков, так и для строителей, которые стремятся сделать процесс межсетевой совместимости более безупречным для конечных пользователей.
Также вероятно, что появятся совершенно новые парадигмы для взаимодействия между роллапами, которые еще предстоит открыть. Если вы разработчик, работающий над подходами, расширяющими темы здесь или не описанными выше, пожалуйста,reach out(dms открыты). Технология наконец-то достаточно созрела, чтобы оказать реальное давление на поиск решений для фрагментации ликвидности/экосистемы, и мы всегда ищем возможность связаться с основателями, которые рискуют, чтобы создать креативные решения.
Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционным советом.
Перевод статьи на другие языки выполняется командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.





