Введение

На Ethereum произошло кембрийское взрывное расширение роллапов. На момент написания статьи насчитывается 91 активный L2 & L3 и 82 предстоящих согласно L2Beat. В результате также имеется значительное количество фрагментации в терминах ликвидности, пользовательского опыта и инструментов разработчика. Текущие решения в области совместимости оставляют желать лучшего, так как они опираются на комбинацию сторонних мостов, внешне обернутых активов и фреймворков намерений, каждый из которых несет свой набор проблем.

1. Мосты ликвидности часто являются целями крупнейших криптовалютных взломов (например, хак моста червя за $321 млн)
2. Внешне обернутые активы нежелательны, и данные показывают, что люди предпочли бы держать активы в их естественной форме всякий раз, когда это возможно (например, существует $22 млрд. ценных бумаг, мостовых по каноническим данным, и только $3 млрд. внешне обернутых активов, согласноL2Beat)
3. Фреймворки намерений зависят от третьих сторон, которым требуется некоторое незначительное доверие, и сопровождаются дополнительными сборами для облегчения деятельности межсетевого роллапа (например, пользователь цепи Деген)потеря более 80% токеновиз-за того, что официальный мост является неканоническим)а. Централизованные намерения также означают более низкую конкуренцию, что может привести к неоптимальной ценовой политике и производительности

В этой статье мы исследуем ландшафт ненадежной совместимости, определяя и обсуждая шесть уровней решений совместимости между фрагментированными экосистемами роллапов.

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

Мы остаемся в основном в рамках Ethereum и его L2s для этой статьи и фокусируемся исключительно на ненадежной совместимости. В данном случае «ненадежная совместимость» относится к протокольным каналам, которые не требуют участия сторонних лиц для облегчения передач вне необходимой инфраструктуры, которая уже требуется для большинства rollups.

Предварительные мероприятия

Определения

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

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

1. Общие секвенсоры/Суперстроители: Прежде всего улучшения скорости и пользовательского опыта.
2. Совместное регулирование: Обмен активами без внешней обертки, а также сообщения в протоколе.

Для начала мы сначала определим шесть уровней ненадежной совместимости, на которые намекнуто во введении:

1. L1 Асинхронно:
   → Совместимость через ручной перевод активов через L1, к которому применяются rollups.
2. Атомная включенность:
   Гарантия того, что либо все транзакции в пакете межсетевого взаимодействия будут включены в следующий блок для каждого роллапа, участвующего в пакете, либо ни одна не будет включена.
3. Общий регулирование:
   → Несколько роллапов, подключенных к L1 через тот же контракт моста.
4. Атомарное выполнение:
   Гарантия того, что либо все транзакции в пакете межсетевого сворачивания будут включены и успешно выполнены в следующем блоке для каждого свертывания, вовлеченного в пакет, либо ни одна из них не будет выполнена. Успешное выполнение означает, что каждая транзакция будет выполнена без отката и будет отражена в обновленном состоянии для каждого свертывания в пакете.
5. Блочная совместимость на уровне блока:
   → Следующий блок гарантирует переход на перекрестные связанные пакеты, которые могут содержать зависимые транзакции (tx B на rollup B зависит от результата tx A на rollup A)
6. Tx-Level Composability:
   Уровень взаимодействия на уровне смарт-контрактов, требующий всего одной транзакции, которая может вызвать изменения состояния одновременно во многих роллапах (без пакетов). Использование любого протокола на любом роллапе логически эквивалентно использованию различных смарт-контрактов на одной цепочке. Важно отметить, что это подразумевает, что изменения состояния до любого вызова могут быть отменены при его возврате.

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

Иллюстративные примеры:

1. Передача токена
   → Отправить себе: Обмен Eth на Eth или ERC-20 на ERC-20 между двумя роллапами
2. Покупка токенов
   → Перекрестный лимитный ордер Rollup: Используя Eth/ERC-20 с Rollup A, приобретите другой ERC-20 на DEX на Rollup B и (по желанию) отправьте обратно на Rollup A

Последствия:

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

1. Пользовательский опыт
   Как изменится опыт пользователя, достигнув этого уровня совместимости?
2. Опыт разработчика
   Как изменяется опыт разработчика при достижении этого уровня совместимости?
3. Потенциал MEV
   Есть ли потенциал для новых возможностей MEV, если мы достигнем такого уровня совместимости?
4. Последствия Rollup
   Rollup должен подписаться на какую-либо новую инфраструктуру, чтобы достичь этого? Какие изменения в структуре комиссий для rollup? Какие могут быть потенциальные преимущества для rollup от участия в этой инфраструктуре?

Обзор высокого уровня

Обзор изменений для ключевых заинтересованных сторон

Шестиступенчатое движение к ненадежной совместимости

1. L1 Асинхронный

Необходимая инфраструктура:

N/A

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

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

Для оптимистичных роллапов задержка вывода составляет ~7 дней, чтобы учесть окно доказательств недостоверности. В ZK роллапе задержка вывода менее определенна, но может составлять от 15 минут до полного дня, как в случае с ZkSync.

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

СтОит отметить решения третьих сторон, которые в настоящее время существуют:

1. Мосты ликвидности
2. Фреймворки намерений

Оба наших иллюстративных примера требуют сторонних решений для облегчения.

Отправить самому себе:

1. Канонично:
   → Вывести активы из Rollup A
   → Вручную внести на Rollup B
2. Третья сторона:
   → Мост ликвидности / Сети решателей

Лимитный ордер Cross-Rollup

1. Канонически:
   → Вывод активов из Rollup A
   → Вручную внести на Rollup B
   → Выполнить лимитный ордер
   → Чтобы отправить обратно, нужно было бы внешне обернуть целевой ERC-20
2. Третья сторона
   → Начинающееся пространство решений для ограниченных ордеров между rollup
   → Существуют открытые проекты, использующие намерения для облегчения этого

Поскольку это является стандартным случаем, нет необходимости обсуждать изменения в UX, DevEx, MEV и rollups.

2. Атомное включение

Необходимая инфраструктура

Общий секвенсор *

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

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

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

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

Рассмотрите инициирование простого обмена между роллапами с гарантией атомарного включения:

1. Пакет обмена между Rollup
   → Tx 1: Блокировка/сжигание токенов при объединении источника
   → Tx 2: Создать токены для адреса пользователя на целевом rollup

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

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

Важный момент: Атомное включение не оказывает существенного влияния на потенциал совместимости

3. Совместное урегулирование

Требуемая инфраструктура:

Уровень агрегации доказательств // Общий контракт моста

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

Зачем создавать общий контракт моста? Чтобы понять, почему наличие общего контракта моста позволяет нам безопасно перемещать активы между роллапами, сначала рассмотрим, что произойдет, если будет возможность иметь Eth в Роллапе A, сжечь его и эмитировать его нативно на Роллапе B без общего контракта моста на L1.

Мы видим, что каждый роллап будет рассинхронизирован с их контрактом моста в основной сети. Контракт моста Rollup B по-прежнему имеет 50 Eth, поэтому пользователь не сможет вывести свой 1 ETH на L1.

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

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

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

С общим слоем расчетов поток может выглядеть следующим образом для простого случая отправки самому себе.

Отправить самому себе:

1. Пользователь создает первоначальную транзакцию:
   → Tx 1: вывести Eth на rollup A (с сообщением о монетизации на rollup B)
   → Транзакция пакетируется и отправляется в контракт L1
   → Он агрегируется в корень транзакции, который группирует все общие расчётные роллапы
2. Rollup B импортирует этот корень tx
3. Релеер отправляет транзакцию на добычу вместе с доказательством Меркля для скручивания B
4. Rollup B проверяет транзакцию сжигания с использованием доказательства о корне Меркла и транзакции
5. Пользователь создает Eth на Rollup B
6. Rollup B подает доказательство в L1

Мы можем расширить этот поток на любой ERC-20, у которого есть контракты на всех rollups в общей экосистеме расчетов.

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

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

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

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

1. Пользователи:
   Теперь можно передавать активы в их первоначальной форме без периода вывода L1
2. Разработчики:
   Изменения ограничиваются эмитентами токенов, которые теперь могут использовать сообщения в протоколе для выпуска собственных версий ERC-20 на всех подключенных роллапах
3. Поисковики MEV:
   Поскольку это происходит на протяжении нескольких блоков для каждого роллапа, нет нового потенциала MEV
4. Роллапы:
   Роллапсы должны будут выбрать использование общего контракта моста и, вероятно, добавить предварительные компиляции для обработки сообщений между роллапсами

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

4. Атомарное исполнение

Необходимая инфраструктура:

Общие последователи // Суперстроители

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

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

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

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

1. Контракты на исходном роллапе могут только генерировать сообщение при блокировке/сжигании исходного актива, они не могут вызывать и создавать транзакцию на целевом роллапе.
   → Вот почему существуют протоколы сообщений и ретрансляционные сети.
   → Сообщение можно использовать для структурирования того, что должен быть вызов на месте назначения, но оно не может создать саму транзакцию.
2. Создание второй транзакции на целевом роллапе для выпуска монет:
   Пользователь не может создать эту tx самостоятельно, потому что у него нет прав на майнинг токена на rollup B
   → Т.е.) Целевая цепочка нуждается в доказательстве того, что токены были сожжены/заблокированы на исходной цепочке, но это доказательство недоступно до завершения начальной транзакции, что нарушило бы наше требование атомарности.
   → Любая другая сторона, которая теоретически может создать вторую транзакцию с правом чеканки, может создать «чеканку» транзакции на целевой цепочке в любой момент без предварительного создания «сжигания» или блокировки на исходной, что является огромной уязвимостью.

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

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

Перекрестный арбитраж DEX между роллапами с атомным исполнением

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

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

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

Последствия для заинтересованных сторон:

1. Пользователи:
   Вероятно, никаких изменений не будет, хотя возможно, что решения от третьих сторон, такие как намерения, могут быть атомарными, но конкретно, как это происходит, неясно
2. Разработчики:
   Вероятно, никаких изменений
3. Поисковики MEV:
   Арбитраж межсетевого обмена гораздо безопаснее благодаря атомному выполнению
4. Rollups:
   Rollups должны согласиться использовать общий последователь/superbuilders, отправляющий блоки с транзакциями от каждого rollup, желающего взаимодействовать, что может изменить структуру доходов rollup. Пока не ясно, как это изменит.

• Последовательность рынков может увеличить доход от роллапов, позволяя опытным строителям покупать пространство ToB.

Важный вывод: Несмотря на то, что пакеты кросс-роллапа гарантированно выполняются атомарно, неясно, как эти пакеты будут построены, если нет суперконструктора, создающего часть пакета, поэтому маловероятно, что атомарное выполнение само по себе повлияет на совместимость. Общие секвенсоры/суперстроители должны по умолчанию выполнять сборку для компонуемости на уровне блоков.

5. Композиция на уровне блока

Необходимая инфраструктура:

Общий последователь // Суперстроитель // Слой агрегации доказательств// Общий мостовой контракт

(* = optional)

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

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

На этом уровне мы начинаем видеть истинную совместимость между роллапами не только просто отправляя себе, чтобы участвовать в даппе на другом роллапе.

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

Есть два случая, которые следует рассмотреть:

1. Композиция на уровне блока
2. Совместимость на уровне блоков + общий уровень расчетов

В обоих случаях мы можем создавать пакеты cross-rollup для более сложной деятельности, но во втором случае с совместным расчетом мы можем использовать нативные активы, которые могут иметь лучшие ценовые последствия, например, для деятельности DEX с перекрестным объединением.

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

Передача того же токена через xERC-20 (без общего расчета):

1. Пользователь имеет ERC-20
2. Пользователь создает tx через dapp:
   → Поместите ERC-20 в сейф xERC-20, чтобы получить упакованную версию xERC-20
   → Сжечь xERC-20
   → Передать сообщение, сигнализирующее об инициировании переноса между роллапами, вместе с соответствующими данными для облегчения обмена
3. Superbuilder принимает транзакцию и создает пакет кросс-роллапа
   → Tx 1: Упомянутая транзакция обертывания и сжигания
   → Tx 2: Создание xERC-20 на rollup B
4. Superbuilder представляет этот перекрестный роллап общему секвенсору
   Поскольку суперстроитель запускает полный узел двух подключенных роллапов, они симулируют транзакции, чтобы гарантировать успешное выполнение пакета. Если хотя бы одна транзакция откатится, весь пакет будет откачен.
5. Общий последователь подает блок, содержащий обе транзакции, на уровень DA, а также на узлы, которые выполнить изменение состояния
6. xERC-20 майнится пользователю на Rollup B

С общим слоем расчетов поток еще более упрощен, потому что нет необходимости сначала обернуть ERC-20 в xERC-20 для обмена.

Давайте теперь рассмотрим ордер с лимитом для покупки ERC-20 на Rollup B с начальным (другим) ERC-20 с Rollup A и отправкой полученного ERC-20 обратно на Rollup A. В этом случае мы не предполагаем наличие общего слоя расчетов, хотя в случае с ним существует аналогичный поток. Единственное отличие заключается в том, что не требуется дополнительно обертывать активы.

Здесь требуемые транзакции в этом случае:

1. Завернуть и сжечь ERC-20 на А
2. Mint xERC-20 on B
3. Обмен начального xERC-20 на целевой ERC-20 на B
4. Обернуть и сжечь целевой ERC-20 на B
5. Mint xERC-20 на А

Здесь потенциальный поток того, как это могло бы работать:

Ордер лимитного типа Cross-Rollup в среде комбинируемого уровня блоков

Поток:

1. Пользователь инициирует первую транзакцию:
   → Обернуть и Сжечь xERC-20 с сообщением, отправленным для указания параметров обмена (цепь назначения, адрес DEX, ERC-20 для обмена, цена лимитного ордера, булево значение для возврата или нет)
2. Superbuilder видит транзакцию и создает пакет:
   → Tx 1: Пользователь создает tx, описанный выше
   → Tx 2: Создание xERC-20 на месте назначения (суперстроителю должны быть предоставлены права на создание)
   → Tx 3: Ордер лимит с использованием данных из tx 1
   → Tx 4: Обернуть и сжечь ERC-20 на B, предполагая полное выполнение лимитного ордера с сообщением о выпуске на исходной цепи
   → Tx 5: Создание xERC-20 на целевой цепи из выходных данных обмена на исходной цепи

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

В случае общей инфраструктуры совместного секвенирования без общего уровня расчетов, необходимо использовать внешнюю обернутую версию Eth и xERC-20, что может привести к худшим рыночным условиям на DEX из-за более слабых пулов ликвидности для обернутых активов. В этом случае пользователю может потребоваться использовать более мягкий лимит с более терпимым проскальзыванием и он может получить субоптимальные цены. Однако исключением является использование USDC. Возможно, что общий секвенсор без общего расчета может сотрудничать с Circle для получения эксклюзивных прав на контракты USDC через роллапы для облегчения нативных трансферов USDC и обменов через роллапы.

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

Оптимистический Доверчивый Последователь

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

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

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

Последствия для заинтересованных сторон:

1. Пользователи
   Массовые улучшения UX в разрешении лимитных ордеров между Rollup в одном блоке
2. Разработчики
   Для кросс-роллап-активности, вероятно, потребуется учитывать кросс-роллап, возможно, с использованием пользовательских предварительных компиляций. Вместо просто транзакций разработчики должны думать в терминах пакетов, но, вероятно, что суперстроители и пользовательская инфраструктура роллапа могли бы абстрагировать большую часть сложности для разработчиков.
3. Поисковики MEV
   Поисковики MEV имеют практически равные возможности использовать стратегии L1 на пакетах межроллап, но это зависит от того, как реализовано PBS (разделение предложителя-строителя).
   → Кросс-роллапные пакеты по сути рассматриваются как одна транзакция, поэтому МЭВ может быть обнаружен при фронтраннинге или сэндвичинге этих пакетов, пока они не перемещают цены за пределы допустимых величин проскальзывания (потому что тогда весь пакет будет отменен, и попытки МЭВ провалились)
4. Роллапы
   Необходимо будет подключиться к общей инфраструктуре последовательности (включая суперстроителей), а также разрешить доступ к сжиганию/чеканке Eth для общего последователя в случае общего уровня расчетов.
   Могут внедрить MEV, продавая блокпространство строителям

6. Транзакционная композиция на уровне

Необходимая инфраструктура:

Изменения на уровне VM // Общий расчет // Суперстроители

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

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

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

Для транзакционной совместимости существует много открытых вопросов дизайна. Например, как разработчики могут выбирать или отказываться от вызовов между роллапами для своих умных контрактов, нужно тщательно рассмотреть. Разрешение произвольной совместимости без ограничений означает, что мы возвращаемся к одному монолитному роллапу. Мы считаем, что здесь ответ заключается в том, чтобы разработчики явно указывали, где необходима совместимость между роллапами в своих контрактах, например, с помощью модификатора Solidity, типа Составнойкоторые помечают определенные точки входа в контракт как вызываемые через cross rollup.

Влияние на заинтересованные стороны

1. Пользователи:
   Те же подразумевания, что и при компоновке на уровне блока, с дополнительными расширенными возможностями, такими как flashloans \
   → UX практически идентичен использованию одной цепи для даппов, которые выбирают вход
2. Разработчики:
   Опыт разработчика значительно улучшается, поскольку разработчики dapp могут нативно вызывать контракты между роллапами и использовать результаты этих вызовов, как одиночные вызовы роллапа
   → Инфраструктуре Superbuilder/Sequencer по-прежнему придется размещать транзакции в блоках для роллапов, на которые влияет вызов междуроллапов, но не придется создавать те же пакеты, что и в случае композиции на уровне блока.
3. Поисковики MEV:
   Высокий потенциал MEV, поскольку пакеты перекрестной свертки теперь практически эквивалентны отдельным транзакциям на одной цепи
4. Роллапы:
   Требуется изменение уровня ВМ, а также согласие на общий последователь и общий уровень расчетов \
   Дополнительные предположения о доверии заключаются в необходимости доверять входам и выходам для других роллапов перед тем, как можно будет проверить состояние с помощью доказательств, но механизмы штрафов могут снизить бремя доверия

Сводка и карта экосистемы

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

1. Общий расчет позволяет осуществлять обмен между роллапами без внешней обертки активов и создает внутрипротокольные пути сообщений между всеми подключенными роллапами
2. Общая последовательность/Суперстроители позволяют гарантировать выполнение следующего блока в пакетах межсетевых транзакций
3. Блочная композиция на уровне блока позволяет создавать сложные, быстрые, зависимые пакеты перекрестного связывания, достигая почти уровня смарт-контракта для смарт-контракта композиционной экосистемы.
   С добавлением общего расчета эти пакеты перекрестной связи могут быть созданы без использования внешне завернутых активов
4. Возможна компоновка на уровне транзакции, и хотя новые возможности, которые открываются, могут быть предназначены для более опытных пользователей, у нее есть потенциал значительно улучшить опыт разработки межсетевого взаимодействия.

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

Карта экосистемы

Карта экосистемы

Заключительные мысли

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

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

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

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

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

Также вероятно, что появятся совершенно новые парадигмы для взаимодействия между роллапами, которые еще предстоит открыть. Если вы разработчик, работающий над подходами, расширяющими темы здесь или не описанными выше, пожалуйста,reach out(dms открыты). Технология наконец-то достаточно созрела, чтобы оказать реальное давление на поиск решений для фрагментации ликвидности/экосистемы, и мы всегда ищем возможность связаться с основателями, которые рискуют, чтобы создать креативные решения.

Благодарности

Эта статья выросла из невероятно содержательной круглой стола по вопросам совместимости роллапов, проведенного 1kx на EthCC. Отдельное спасибо Noah PravecekGateЭлли Дэвидсон, и Терриза прочтение ранних версий этой статьи и обратную связь, а также кMarti, mteam, и Бо Дудля дальнейших разговоров на эту тему.

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

1. Эта статья перепечатана из [зеркалоПересылайте оригинальный заголовок «Ненадежная совместимость между Роллапами: ландшафт, конструкции и проблемы», Все авторские права принадлежат оригинальному автору [Маршалл Вайлтел мл.]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь Шлюз Учитькоманда и они оперативно справятся с этим.

2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционным советом.

3. Перевод статьи на другие языки выполняется командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.