Введение

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

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

Проблема фрагментации

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

Пользовательский опыт: Фрагментация заставляет пользователей часто переключаться между сетями, управлять несколькими копиями одного и того же токена и манипулировать различными кошельками. Это добавляет трение и сложность, делая сложнее для пользователей наслаждаться безшовным, «просто работающим» опытом с Ethereum. Например, предположим, что у Алисы есть ее средства на роллапе A, но она хочет купить токен, доступный только на роллапе B. Вместо того, чтобы просто нажать «Купить», ей нужно сначала переключиться на другую сеть, перевести свои средства с A на B, дождаться подтверждения на L1, а затем выполнить сделку.

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

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

Совместимость

По своей сути, функциональная совместимость означает возможность транзакции, которая начинается в одном свертке и обновляет состояние в другом — например, отправка токенов из Rollup A в Rollup B. В идеале это действие так же просто, как одновременное снижение баланса в точке A и увеличение баланса в точке B. На практике достижение такого бесшовного поведения «все или ничего» является сложной задачей между различными свертками.

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

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

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

Интероперабельность вызовов

Достижение истинной совместимости между роллапами — это не просто отправка сообщений туда и обратно; это обеспечение безопасного и быстрого завершения транзакций. Полагаться исключительно на Ethereum L1 может означать длительные задержки и высокие затраты. У Элис средства на роллапе A, но она хочет купить токен, доступный только на роллапе B. Есть два варианта:

• Rollup B принимает средства только Алисы, если они мостятся через Ethereum. В этом случае Алисе необходимо вывести свои средства на L1, затем внести их в rollup B и, наконец, купить токен в rollup B, что приведет к значительной задержке и затратам.
• Rollup B предоставляет более быстрый и дешевый путь, обрабатывая передачу напрямую, а не сначала урегулировать на уровне 1 Ethereum. Однако, как мы объясним ниже, это подвергает Rollup B потенциальным рискам переупорядочивания, если Rollup A уклоняется от ответственности, не урегулирует или представляет недействительное состояние перехода.

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

• Эквивокация: Rollup транслирует противоречивые состояния на разные цепочки, фактически обещая одинаковые активы несколько раз.
• Недействительность: Переход состояния может никогда не быть доказуемо правильным на L1.
• Не урегулирование: Процесс генерации доказательств или урегулирования может замедлиться на неопределенное время.

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

Давайте проиллюстрируем эти вызовы на примере: предположим, что Алиса владеет 10 ETH на основной сети Scroll и хочет передать их Бобу в Arbitrum. В идеале, Алиса смогла бы перемещать ликвидность между этими двумя цепями нативно с более быстрыми, чем у Ethereum, задержками. Предположим, что такое решение существует, и Arbitrum зачислил Алисе 10 ETH в Arbitrum до того, как Scroll отправит что-либо на L1, что может пойти не так для Arbitrum?

• Двусмысленность: Скролл уклоняется, совершая на L1 другой переход состояний, в котором транзакция Элис не включена, фактически украв 10 ETH у Арбитрум (которому нужно провести реорганизацию, чтобы иметь возможность завершить).
• Недействительность: Прокрутка не эквивалентна, но переход состояния, содержащий транзакцию, недействителен, и поэтому Прокрутка никогда не сможет завершить его (т.е. доказать это) на уровне L1 и передать средства Арбитруму. Снова, Арбитрум должен провести реорганизацию, чтобы иметь возможность завершить.
• Неоконченный расчет: Скролл не уклоняется, и переход состояния действителен, но назначенные доказатели Скролла выходят из сети, и поэтому расчет не происходит. Арбитруму нужно снова провести реорганизацию.

Интегрируя Arbitrum 10 ETH, отправленных от Alice в Scroll, до того как Scroll фиксирует на L1 (в случае двусмысленности) и перед тем как Scroll урегулирует (в случае недействительности и неразрешения), Arbitrum берет на себя риск на своей цепочке, зависящий от соображений безопасности Scroll.

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

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

Архитектура взаимодействия

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

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

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

Сеть

Mesh-модель работает так, как и следовало ожидать: роллапы общаются друг с другом напрямую, но при этом сами отвечают за расчеты с Ethereum L1:

Поскольку все больше и больше роллапов становятся взаимосвязанными в этой большой сетке, транзитивность доверия и зависимости становятся проблемой для масштабируемости. Если Arbitrum доверяет Scroll, но не доверяет zkSync, то Scroll не может доверять zkSync, сохраняя доверие Arbitrum. Только непересекающиеся «группы доверия», т.е. клики роллапов, могут взаимодействовать друг с другом в сетке. Эта проблема зависимости усугубляется по мере вовлечения в сложные случаи взаимодействия все большего числа роллапов, где безопасность всего ограничена безопасностью наименее защищенного роллапа.

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

Тем не менее, быстро становится очевидным, что эту модель сложно масштабировать, если мы хотим добавить больше и больше роллапов, другие L2 и даже appchain L3 в сетку.

Хаб

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

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

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

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

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

• Использование существующего роллапа: Этот вариант имеет преимущество быть самым простым, так как роллап уже существует и, вероятно, был протестирован в бою, и развертывание смарт-контрактов на нем будет лишь вопросом времени.
• Создание выделенного компонента: Вместо того, чтобы просить роллапы полагаться на все свойства безопасности существующего роллапа, мы вместо этого создаем новый выделенный компонент для действия в качестве центра. Преимущество здесь заключается в том, что у этого нового компонента будет минимизированный вектор поверхности ошибок/эксплойтов благодаря специальной подгонке под потребности кросс-цепочки (и даже может быть формально проверен!).
• Использование самого Ethereum L1: Этот вариант предполагает использованиеПредварительные подтверждения на основенапрямую на уровне 1, чтобы иметь все преимущества: использовать максимально децентрализованный уровень для максимальной активности и безопасности, обеспечивая при этом практически мгновенные подтверждения, минимизированное время вывода и т. д.

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

Существующие системы

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

Системы Mesh. OPСуперцепь и Arbitrum Кластеры цепочекэто сети сетей, где цепи должны взаиморасчеты вместе - если одна цепь уклоняется от ответственности, все связанные цепи должны переорганизоваться. Цепи должны доверять друг другу для предварительных подтверждений расчетов.

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

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

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

AggLayer от Polygon - это еще один тип вспомогательной системы, которая предоставляет общий уровень, через который все роллапы общаются. Однако он отличается тем, что избегает дополнительных доверительных предположений в этом общем уровне. Вместо этого они ждут урегулирования и используютпессимистическое доказательстводля обеспечения безопасности. Таким образом, двусмысленность предотвращается только во время расчетов. Предварительные подтверждения могут быть использованы по желанию для обеспечения более быстрой окончательной гарантии. Недавно AggLayer объявил опартнерствос помощью Espresso Systems, обеспечивающей общий механизм последовательности.

Заключение

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

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

1. Эта статья перепечатана из [Исследование Scroll]. Все авторские права принадлежат оригинальному автору [Alejandro Ranchal-Pedrosa]. Если есть возражения по поводу этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционной рекомендацией.
3. Команда Gate Learn выполняет переводы статей на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.