Чи зможе Ethereum зробити rollup-и єдиною мережею?

Трейдер на демонстрації Devcon підписав одне замовлення на Ethereum rollup, купив токени, використовуючи ліквідність у mainnet, і отримав їх назад на rollup. Угода показує, як користувачі могли б отримати доступ до глибшого ринку, не переміщуючи кошти самостійно, — підхід, який Gnosis планує зробити своїм стандартним налаштуванням навесні 2027 року.

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

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

Gnosis планує навесні 2027 року зробити цей дизайн стандартним. Для трейдерів практичним випробуванням буде те, чи зможуть їхні гаманці та торгові застосунки запропонувати цей маршрут і чи ціна, доступна в mainnet, все ще робитиме його вигідним після витрат на виконання.

Як працювала б угода в двох середовищах виконання

Команда Ethereum Economic Zone почала з жовтневої транзакції на 0,001 ETH та оновлення стану rollup. Своп на Devcon переніс ту саму проблему координації в умови, знайомі трейдерам. Він мав виконати замовлення проти ліквідності в іншому ланцюжку та доставити отриманий актив туди, звідки почав користувач.

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

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

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

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

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

Для гаманця однаково практичним тестом є запис транзакцій, який він може показати після закінчення терміну дії ордера. Якщо користувач підписує один раз і торгівля успішна, користувач повинен мати можливість побачити отриманий актив і те, який рахунок його отримав. Якщо маршрут не вдається, гаманець все одно потребує способу відрізнити прострочений ордер від транзакції, що очікує на розрахунок. Це важливо під час ринкового руху, коли трейдер може розмістити другий ордер і потребує знати, чи перший ще може виконатися.

Про що мережі повинні домовитися, перш ніж вони зможуть виконувати операції разом

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

Gnosis описує дві умови для мереж, що приєднуються до дизайну EEZ. Вони повинні створювати доказ протягом слота Ethereum і дотримуватися Ethereum у разі реорганізації. Gnosis подає це як умови для підключеної мережі, залишаючи деякі варіанти реалізації окремим учасникам.

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

Друга умова стосується того, що відбувається, коли нещодавня історія Ethereum змінюється. Транзакція в іншій мережі могла покладатися на подію в нещодавньому блоці мейннету. Якщо конкуруючий блок замінює його, підключена система потребує правил для обробки залежної транзакції. Узгодження обмежує можливість однієї сторони зберегти результат, заснований на події мейннету, яка більше не належить до прийнятого ланцюга.

Цей зв'язок важливий для користувачів, оскільки одна скоординована транзакція та остаточний розрахунок описують різні властивості. Скоординоване виконання стосується того, чи можуть кроки завершитися разом. Остаточний розрахунок стосується того, коли учасники можуть вважати результат остаточним за правилами задіяних мереж. Гаманець може запропонувати один погляд на операцію, все ще розрізняючи включену транзакцію від тієї, що досягла статусу розрахунку, який вимагає бізнес.

Попередня інженерна робота Gnosis стосувалася зобов'язань щодо кореня блоку, лімітів газу та того, як здійснюватимуться оновлення. Ці вибори впливають на те, як мережі можуть розпізнавати результати одна одної та скільки роботи застосунки можуть просити їх виконувати. Жовтнева віха розмістила просту операцію в мейннеті, тоді як листопадові демонстрації дали розробникам більш різноманітні навантаження для випробування.

Де дизайн може вийти за межі торгівлі

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

Третя демонстрація перевірила постквантовий підпис Falcon на rollup і використала результат для авторизації переказу в мейннеті. Команда повідомила про на 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 говорить про виконання обчислень в іншому місці

Показова демонстрація використовувала rollup для перевірки підпису Falcon і передала цей результат до дії в mainnet. Команда повідомила про скорочення споживання газу на 91% порівняно з перевіркою в mainnet. Цей приклад має вужчий обсяг, ніж твердження про вартість кожної транзакції, яка могла б використовувати цю конструкцію. Він порівнює визначену операцію на двох шляхах виконання.

Можливість полягає в тому, щоб виконувати обчислювально дорогу перевірку в середовищі, придатному для неї, дозволяючи іншому контракту покладатися на відповідь. Застосунок, який виконує перевірку лише зрідка, може оцінювати економію інакше, ніж той, що повторює її для кожного замовлення. Рішення також залежить від того, як застосунок перевіряє результат і які інші кроки він має виконати, щоб його використати.

Постквантова перевірка є одним із застосувань цієї схеми. Контракту може знадобитися інша інформація з підключеного середовища, перш ніж він зможе продовжити, наприклад, чи має обліковий запис право виконувати операцію. Спільна проблема полягає в тому, щоб зробити результат доступним у межах того самого вікна виконання. Різні перевірки можуть мати дуже різні вимоги до обчислень і доказів.

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

Існує подібна відмінність для розробників, які оцінюють демонстрацію Falcon. Газ, витрачений контрактом на читання результату перевірки, і вартість створення цього результату в іншому місці належать до різних середовищ виконання. Вимірювання першого відображає реальне обмеження для застосунку, який інакше мав би виконувати перевірку в mainnet. Сервіс, який вирішує, чи може він запропонувати цю функцію, повинен враховувати також і друге. Йому також потрібно знати, чи може перевірка завершитися під навантаженням, коли багато запитів можуть конкурувати за одну й ту саму потужність.

Gnosis доведеться провести існуючі застосунки через перехід

GnosisDAO авторизувала перехід від окремої мережі до EEZ rollup через GIP 153 у серпні. Міграція важлива, оскільки існуючі користувачі та застосунки мають баланси, адреси та залежності, прив’язані до живої мережі. Для них впровадження нової схеми виконання та розрахунків є зміною інфраструктури, яку вони вже використовують.

Питання, на які має відповісти живий застосунок, відрізняються від тих, що стосуються мережі розробки. Його користувачам потрібно знати, як переносяться баланси, які гаманці та постачальники інфраструктури підтримують міграцію і де отримати надійний запис активності під час переходу. Торговельні платформи повинні враховувати можливість того, що інтеграції стануть доступними в різний час.

Rollup, який може отримувати доступ до ринків mainnet, може бути здатний запропонувати маршрути ще до того, як він збудує глибокі власні пули для кожної пари токенів. Мережа з усталеною ліквідністю має інше рішення. Її застосунки можуть обирати між локальним виконанням і спільним маршрутом, а постачальники ліквідності, які вже є в мережі, можуть бачити, як ці вибори впливають на активність у їхніх пулах.

Міграція також перевірить різницю між запуском мережі та зробленням функції типовою для користувачів. Перший блок може продемонструвати, що новий ланцюжок працює. Типовий маршрут користувача вимагає, щоб гаманці, застосунки та інші постачальники використовували новий шлях у звичайній діяльності. Раніші повідомлення описували ціль близько рубежу року для початкового розгортання. Листопадове оновлення Gnosis вказує весну 2027 року як ціль для типової роботи.

Gnosis дає розробникам місце, щоб поставити ці питання щодо розгортання з наявними застосунками. Міграція поставила б виконання, підтримку гаманців та операційні процедури в один графік, уможливлюючи відстеження того, як команда справляється із затримками чи частковими інтеграціями. Її листопадове оновлення визначає весну 2027 року як ціль для зроблення цієї конструкції типовою. Операції Devcon відбувалися на Rollup X.

На що звернути увагу

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

Часті запитання