Сможет ли Ethereum объединить rollup-сети в единую сеть?

Трейдер на демонстрации в рамках Devcon подписал один ордер в Ethereum-роллапе, купил токены, используя ликвидность в основной сети, и получил их обратно в роллапе. Сделка показывает, как пользователи могли бы получить доступ к более глубокому рынку, не перемещая средства самостоятельно, — подход, который Gnosis планирует сделать своей конфигурацией по умолчанию весной 2027 года.

Команда Ethereum Economic Zone продемонстрировала сделку, в которой пользователь подписал один ордер в экспериментальной сети Rollup X, солвер CoW Swap исполнил его, используя ликвидность основной сети Ethereum, а купленные токены вернулись в роллап. Демонстрация показывает, как трейдер мог бы получить доступ к более глубокому рынку в основной сети, не отправляя туда средства заранее и не ожидая их прибытия перед размещением ордера.

Команда представила сделку на Devcon 4 ноября, как сообщал crypto.news. Это различие имеет значение, когда цены меняются быстро, поскольку котировка, доступная в момент, когда трейдер начинает перемещать средства, может измениться до того, как средства будут готовы к торговле.

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

Как сделка работала бы в двух средах исполнения

Команда Ethereum Economic Zone начала с октябрьской транзакции на 0,001 ETH и обновления состояния роллапа. Своп на Devcon перенёс ту же проблему координации в условия, знакомые трейдерам. Нужно было исполнить ордер против ликвидности в другой сети и доставить полученный актив туда, откуда начал пользователь.

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

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

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

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

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

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

О чём сети должны договориться, прежде чем они смогут исполнять транзакции совместно

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

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

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

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

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

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

Куда дизайн может выйти за пределы торговли

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

Третья демонстрация проверила постквантовую подпись Falcon на роллапе и использовала результат для авторизации перевода в мейннете. Команда сообщила о на 91% меньшем потреблении газа в своём сравнении с выполнением проверки напрямую в мейннете. Измеренная экономия относилась к тому упражнению по проверке, и производственное приложение должно было бы учитывать свои полные затраты на исполнение и расчёт.

Одна подпись всё ещё оставляет рынок для исполнения

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

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

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

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

Как проект перешёл от предложения к devnet

Проект был публично представлен на EthCC весной компаниями Gnosis и ZisK при поддержке Ethereum Foundation. Первоначальное предложение касалось ликвидности и приложений, которые оказались распределены между разными сетями второго уровня. Rollup X даёт разработчикам среду для проверки того, как общая транзакция может использовать эти приложения.

Выбор демонстрации имеет значение не случайно. Перевод небольшого количества ETH между средами проверяет относительно прямую операцию. Своп вводит необходимость удовлетворить ордер за счёт рыночной ликвидности и вернуть актив. Изменение владельца Safe включает разрешения. Проверка подписи требует, чтобы одна среда выполнила проверку, а другая действовала на основе её результата. Каждый случай проверяет свою зависимость.

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

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

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

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

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

Что должна была бы покрывать цена кросс-чейн свопа

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

Представьте, что локальный пул доставил бы актив на сумму $9 900 после всех сборов по ордеру с эталонной стоимостью $10 000. Кросс-чейн маршрут, который может исполнить сделку за $9 980 до издержек исполнения, имеет до $80 запаса, прежде чем локальная котировка станет лучше. Если достижение лучшего пула стоит $30, кросс-чейн маршрут доставит $9 950. При $100 добавленных издержек локальный маршрут предлагает больше. Эти числа иллюстрируют сравнение и не описывают живую котировку.

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

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

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

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

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

Safe делает кросс-чейн полномочия частью проблемы

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

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

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

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

Институциональный интерес выходит за пределы сцены Devcon. Consensys объявила о системе интероперабельности для банков и заявила, что планирует поддерживать стандарт EEZ. Для банка совместимость будет соседствовать с вопросами о том, кто может использовать систему, какие меры контроля применяются к каждой операции и как она фиксирует результат в существующих системах.

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

Что демонстрация Falcon говорит о выполнении вычислений в другом месте

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

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

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

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

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

Gnosis придётся провести существующие приложения через переход

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

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

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

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

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

На что обратить внимание

• Поддерживаемые маршруты. Кошельки и приложения, публикующие сети, в которых доступна одна и та же операция.
• Котировки исполнения. Сопоставимый чистый результат и доля неудачных ордеров для локальных и кросс-сетевых сделок.
• Производительность слотов. Повторные тесты, демонстрирующие доступность доказательств и восстановление при реорганизации Ethereum.
• Разрешения казначейства. Опубликованные правила области действия, срока действия и отзыва для интеграций Safe.
• Вехи Gnosis. Публичные тесты миграции и прогресс в достижении цели весны 2027 года.

Часто задаваемые вопросы