Может ли Ethereum сделать роллапы единой сетью?

Краткое содержание

• Трейдер подписал один ордер в экспериментальной сети Rollup X, и солвер CoW Swap исполнил его, используя ликвидность основной сети Ethereum.
• Демонстрации на Devcon 4 ноября также проверили, как кошелёк Safe может использовать права казначейства в разных сетях.
• Команда сообщила о снижении расхода газа на 91% в примере проверки подписи, но этот результат относится только к данной операции.
• Участвующие сети должны создавать доказательства в пределах 12-секундного слота Ethereum и следовать за 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% по сравнению с проверкой непосредственно в основной сети. Измеренная экономия относится к этому упражнению по проверке, а производственное приложение должно учитывать полные затраты на исполнение и расчёт.

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

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

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

Вам также может понравиться: Ethereum Economic Zone представила три кросс-чейн прорыва на Devcon

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

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

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

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

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

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

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

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

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

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

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

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

Представьте, что локальный пул доставил бы актив на сумму $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.