Вступ

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

1. Містки ліквідності часто стають метою найбільших криптовалютних взломів (наприклад, вторгнення через міст червного отвору на $321 млн)
2. Зовнішньо обгорнуті активи є небажаними, і дані показали, що люди вважають за краще тримати активи у власному форматі, коли це можливо (наприклад, є $22 млрд вартості канонічно з'єднаних активів і лише $3 млрд вартості зовні обгорнутих активів, згідно з L2Beat)
3. Фреймворки намірів ґрунтуються на сторонніх учасниках, які потребують певної ненадійності, і супроводжуються додатковими витратами для забезпечення міжроллапної активності (наприклад, користувачі ланцюга Degen)втрата >80% токенівчерез те, що офіційний міст є не канонічним) централізовані інтент-фреймворки також означають меншу конкуренцію, що може призвести до неоптимальної ціноутворення та ефективності

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

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

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

Підготовчі заходи

Визначення

Фундаментально, ненадійна сумісність вимагає наявності спільного ресурсу, до якого мають доступ будь-які два протоколи, які бажають взаємодіяти. У випадку Ethereum L1 всі смарт-контракти існують в одному середовищі, де спільно використовується повний стан Ethereum, тому вони завжди матимуть найвищий рівень сумісності. Однак L2 обмежується лише обмінним рівнем через окремі містки контракти, тому сумісність значно обмежена.

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

1. Спільні послідовники / Супербілдери: переважно оновлення швидкості та користувацького досвіду.
2. Спільна розрахункова система: Активи обмінюються без зовнішньої обгортки, а також через внутрішньопротокольні повідомлення.

Для початку ми спочатку визначимо шість рівнів ненадійної сумісності, на які натякається в огляді:

1. L1 Асинхронний:
   → Сумісність через ручний переказ активів через L1, які розв'язуються роллапами.
2. Атомне включення:
   → Гарантія того, що усі транзакції в пакеті міжролап будуть включені до наступного блоку для кожної ролап, що бере участь в пакеті, або жодна з них.
3. Спільний розрахунок:
   → Кілька ролапів, що підключаються до L1 через той самий контракт мосту.
4. Атомне виконання:
   Гарантія того, що усі транзакції у пакеті cross-rollup будуть включені та успішно виконані у наступному блоку для кожного rollup, що бере участь у пакеті, або ж жодна з них не буде виконана. Успішне виконання означає, що кожна транзакція виконується без повернення та відображається в оновленому стані для кожного rollup у пакеті.
5. Сумісність на рівні блоку:
   → Наступний блок гарантує на перехресних пакетах роллап, які можуть містити залежні транзакції (tx B на роллап B залежить від результату tx A на роллап A)
6. Рівень композиції на рівні Tx:
   → Взаємодія на рівні смарт-контрактів, що потребує лише одну транзакцію, яка може викликати зміни стану одночасно в багатьох rollups (без пакетів). Використання будь-якого протоколу на будь-якому rollup логічно еквівалентно використанню різних смарт-контрактів на одному ланцюжку. Важливо, це означає, що зміни стану до будь-якого виклику можуть бути скасовані при поверненні.

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

Ілюстративні приклади:

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

Послідовності:

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

1. Вживання користувача
   Як змінюється досвід користувача, досягаючи цього рівня сумісності?
2. Досвід розробника
   Як змінюється досвід розробника, досягаючи цього рівня сумісності?
3. Потенціал MEV
   Чи є потенціал для нових можливостей MEV, якщо ми досягнемо такого рівня сумісності?
4. Наслідки роллапу
   Чи потрібно rollup вибирати будь-яку нову інфраструктуру для досягнення цього? Які зміни в структурах комісій для rollup? Які потенційні переваги можуть мати rollups, щоб брати участь в цій інфраструктурі?

Високорівневий огляд

Огляд змін для ключових зацікавлених сторін

Шестирівневий прогрес до ненадійної сумісності

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. Атомарна інклюзія

Необхідна інфраструктура

Спільний послідовник *

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

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

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

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

Розгляньте можливість ініціювання простого крос-ролап свопу з гарантіями лише атомарного включення:

1. Пакет свопів крос-ролапу
   → Tx 1: Заблокуйте / Випаліть токени на джерелі роллапу
   → Tx 2: Створити токени на адресу користувача на роллапі призначення

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

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

Важливий висновок: Атомне включення не суттєво впливає на потенціал сумісності

3. Спільний розрахунок

Необхідна Інфраструктура:

Шаровий контракт-міст

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

Навіщо будувати договір на спільний міст? Щоб зрозуміти, чому наявність контракту на спільний міст дозволяє нам без довіри переміщувати активи між зведеннями, спочатку розглянемо, що станеться, якщо можна буде розмістити ETH у Rollup A, спалити його та карбувати на Rollup B без спільного контракту на міст на L1.

Ми бачимо, що кожний rollup вийшов би із синхронізації з їх контрактом моста на mainnet. Контракт моста rollup B все ще має 50 Eth, тому користувач не зможе зняти свої 1 Eth на L1.

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

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

Тут потрібно оновлення на рівні контракту L1 щододе ліквідність полягає в тому, щоб дозволити користувачам виводити кошти з будь-якого місця, але це тривіально, оскільки всі підключені rollups можуть читати / записувати до спільного контракту.

З спільним рівнем розрахунків потік може виглядати наступним чином для простого випадку відправки самому собі.

Відправити собі:

1. Користувач створює початкову транзакцію:
   → Tx 1: виведення Eth на rollup A (з повідомленням про випуск на rollup B)
   → Транзакція пакетується та надсилається до контракту L1
   → Він агрегується в корінь транзакції, який групує всі спільні розрахункові ролапи
2. Rollup B імпортує цей кореневий хеш транзакції
3. Relayer подає транзакцію на витіснення разом з доказом Меркля для rollup B
4. Rollup B перевіряє транзакцію на спалювання за допомогою доказу Меркла та кореня транзакції
5. Користувач має Eth на Rollup B
6. Rollup B подає докази на L1

Ми можем розширити цей потік на будь-який ERC-20, у якому є контракти на всіх rollups у спільній екосистемі розрахунків.

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

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

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

Наслідки для зацікавлених сторін:

1. Користувачі:
   Тепер можна переносити активи у власній формі без періоду виведення L1
2. Розробники:
   Зміни обмежені випускникам токенів, які тепер можуть використовувати вбудовані повідомлення для випуску власних версій ERC-20 на всіх підключених роллапах
3. Пошуковики MEV:
   Оскільки це відбувається протягом кількох блоків для кожного rollup, немає нового потенціалу MEV
4. Rollups:
   Rollups будуть змушені вибрати використання спільного контракту моста та ймовірно додати попередні компіляції для обробки повідомлень між rollup

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

4. Атомна страта

Необхідна інфраструктура:

Спільні послідовники // Супербудівники

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

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

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

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

1. Контракти на вихідному роллапі можуть видаляти повідомлення лише при блокуванні / згорянні вихідного початкового активу, вони не можуть викликати та створювати транзакцію на цільовому роллапі.
   → Саме тому існують протоколи повідомлень та ретрансляційні мережі.
   → Повідомлення може бути використано для структуризації того, яким має бути виклик на призначення, але воно фактично не може створити транзакцію само по собі.
2. Створення другої транзакції на призначеному роллапі для витрати:
   → Користувач сам не може створити цю tx, оскільки він не має прав на чеканку токенів на rollup B
   → Тобто ланцюг призначення потребує підтвердження того, що токени були сожжені / заблоковані на джерелі, але це підтвердження не доступно до виконання початкової транзакції, що порушило б наші вимоги до атомарності.
   → Будь-яка інша сторона, яка теоретично могла створити другу транзакцію з правом чеканки, може створити транзакцію «мінт» на цільовому ланцюжку у будь-який момент, не створивши спочатку «випалення» або блокування джерела, що є великою вразливістю.

Ми бачимо, що навіть якщо ми могли б гарантувати виконання пакунків cross-rollup, ми зіштовхуємося з труднощами у тому, як ми могли б їх спочатку побудувати, щоб передавати активи вартості.

Тим не менш, є декілька випадків використання для атомного виконання без залежних пакетів між рулонами. Один із них - арбітраж між рулонами.

Арбітраж Cross-Rollup DEX з атомним виконанням

Оскільки між цими транзакціями відсутні жорсткі залежності, кожен може створити цей атомний пакет і надіслати його до спільного послідовника, який гарантуватиме атомне виконання.

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

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

Наслідки для зацікавлених сторін:

1. Користувачі:
   Можливо, ніяких змін, хоча можливо, що рішення сторонньої сторони, такі як наміри, можуть бути атомними, але конкретно як це не зовсім ясно
2. Розробники:
   Ймовірно, немає змін
3. Пошуковики MEV:
   Арбітраж між роллапами набагато безпечніший завдяки атомному виконанню
4. Rollups:
   Rollups повинні погодитися використовувати спільний послідовник/супербілдери, які подають блоки з транзакціями з кожного rollup, який бажає взаємодіяти, що може змінити структуру доходів rollup. Ще неясно, як це зміниться. \

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

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

5. Компонування на рівні блоків

Необхідна інфраструктура:

Спільний послідовник // Супербудівельник // Шар доказового агрегування// Спільний контракт моста

(* = опціонально)

У багатьох дискусіях про спільні послідовники та спільні рівні розрахунків термін, який часто використовується для опису цього рівня сумісності, - «синхронне компоновання».

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

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

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

Є два випадки, які слід врахувати:

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

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

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

Передача того самого токену через xERC-20 (без спільного розрахунку):

1. Користувач має ERC-20
2. Користувач створює tx через dapp:
   → Депонуйте ERC-20 в xERC-20 локбокс, щоб отримати обернену версію xERC-20
   → Спалити xERC-20
   → Відправте повідомлення, що сигналізує спільній інфраструктурі послідовного перенесення того, що ініційовано перехід міжролапу разом із відповідними даними для полегшення обміну
3. Superbuilder забирає транзакцію та створює перехресний пакет rollup
   → 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 на A
2. Mint xERC-20 на B
3. Обміняйте початковий xERC-20 на цільовий ERC-20 на B
4. Завернути та спалити цільовий ERC-20 на B
5. Створити xERC-20 на A

Ось потенційний потік того, як це може працювати:

Лімітний ордер Cross-Rollup в середовищі композиції на рівні блоку

Плин:

1. Користувач ініціює першу транзакцію:
   → Загорніть і запишіть xERC-20 з повідомленням, що видається для визначення параметрів свопу (ланцюжок призначення, адреса DEX, ERC-20 для обміну, ціна лімітного ордера, логічне значення для відправки назад чи ні)
2. Супербілдер бачить транзакцію і створює пакет:
   → 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 будуть оптимістично довіряти спільному послідовнику/супербілдеру для створення правильних пакетів між rollup. Це передусім через те, що цей пакет між rollup містить залежні транзакції, які окремі rollups не можуть перевірити до того, як блок буде доданий до ланцюжка кожного rollup і агрегований до рівня вирішення на L1. Прикладом є початкове спалювання та монетизація Eth з джерела на призначення. Важливо, щоб Eth був фактично спалений на джерелі, перш ніж буде виготовлений на призначенні, інакше подвійні витрати можливі.

Однак, щоб мати цей повний пакет виконаний в одному блоку, всі транзакції повинні бути присутні в цьому блоку, навіть якщо транзакція представляє стан, який є недійсним перед самим блоком (наприклад, мати Eth на цільовому ланцюжку для обміну, якщо у користувача його немає до блоку). З цієї причини ми повинні довіряти послідовнику, що він фактично включив дійсні залежності в пакет cross-rollup. Хтось міг би подати докази після факту, щоб довести дійсність кожної транзакції.

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

Наслідки для зацікавлених сторін:

1. Користувачі
   Масштабні вдосконалення UX у встановленні обмежень між роллапами в одному блоку
2. Розробники
   Потрібно мати у свідомості можливість перекочування для діяльності перекочування, ймовірно, використовуючи спеціальні передвстановлення. Замість просто транзакцій розробники повинні мислити в термінах пакунків, але ймовірно, що супербілдери та інфраструктура спеціального ролапу можуть абстрагувати більшість складностей розробника.
3. Пошуковики MEV
   Пошуковикам MEV фактично мають еквівалентну можливість використовувати стратегії L1 на пакунках між rollup, але це залежить від того, як реалізовано PBS (відокремлення пропонента-будівника).
   → Крос-роллап пакети в основному розглядаються як одна угода, тому МВЕ може бути знайдено за допомогою фронтраннінгу або сендвічування цих пакетів, поки вони не змінюють ціни поза терпимими значеннями просічення (тому що тоді весь пакет скасується, і спроби МВЕ будуть невдалими)
4. Rollups
   Потрібно буде вибрати спільну інфраструктуру послідовності (включаючи супербілдерів), а також дозволити доступ до спалення/виготовлення Eth спільному послідовнику у випадку спільного рівня вирішення.
   Можна внутрішнім чином усвідомити MEV, продавши блок-простір будівельникам

6. Складність на рівні транзакції

Необхідна інфраструктура:

Зміни на рівні ВМ // Спільний розрахунок // Супербудівники

Композиція на рівні транзакцій посилається на той самий рівень функціональності, яку розумні контракти на одному ланцюжку EVM діляться. У цьому випадку одна транзакція може оновлювати стан одночасно на кількох rollups, і забезпечити, що будь-які зміни стану до будь-якого виклику можуть бути скасовані, якщо виклик не повертається успішно. Фактично, атомний пакет транзакцій в середовищі композиції на рівні блоків може бути виконаний в межах однієї транзакції між rollup та VM. Це потребує змін на рівні VM для всіх підключених rollups, крім спільного рівня врегулювання та супербілдера.

Тут ми опишемо можливий механізм на високому рівні. (Наскільки нам відомо, ця конструкція заслуга команди «Еспресо»). По-перше, користувач надсилає транзакцію крос-ролапу всім зведенням, стан яких змінюється транзакцією, або суперконструктору, який може створювати блоки для всіх залучених зведень. Суперконструктор моделює транзакцію та формує списки пар введення-виведення, по одному для кожного залученого зведення, які визначають необхідні та очікувані перехресні зведення повідомлень у межах транзакції. (Зауважте, що суперконструктор може зробити це лише в тому випадку, якщо він має безпечні права на секвенування всіх залучених зведень протягом певного періоду часу). Потім суперконструктор надсилає змодельований блок ініціатору кожного зведення разом зі списками очікуваних пар входів-виходів для кожної транзакції крос-зведення. Під час виконання кожне зведення виконує свою власну функцію переходу стану, як зазвичай, за умови, що вхідні дані зі списку транзакцій перехресного зведення є правильними. Під час розрахунків списки входів-виходів можуть бути перехресно порівняні та доведені безпечними на етапі агрегації доказів на рівні спільного розрахунку. Зокрема, якщо будь-які очікувані вхідні дані для транзакції крос-ролапу не збігаються з тими, які інший зведений вказав як вихід, процес розрахунку відхилить усю транзакцію крос-зведення.

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

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

Наслідки для зацікавлених сторін

1. Користувачі:
   Ті ж наслідки, що й при композиції на рівні блоку з додатковими розширеними можливостями, такими як flash-кредити
   → UX практично ідентичний з використанням однієї ланцюжка для додатків, які вибирають участь
2. Розробники:
   Досвід розробника значно покращується, оскільки розробники додатків можуть нативно викликати контракти через міжроллап та використовувати виводи з цих викликів, як одиночні виклики роллап
   → Інфраструктура Superbuilder/Sequencer все ще повинна розміщувати транзакцію в блоках для роллапів, на які впливає міжроллапний виклик, але не повинна створювати ті ж самі пакети, що й у випадку композабільності на рівні блоку.
3. Пошуковики MEV:
   Високий потенціал MEV, оскільки пакети перехідного зв'язку тепер практично еквівалентні одиночним транзакціям на одному ланцюжку
4. Rollups:
   Потрібні зміни на рівні VM, а також вибір спільного послідовника та спільного рівня врегулювання \
   → Додаткові припущення про довіру, пов'язані з необхідністю довіряти вхідним та вихідним даним для інших rollups перед тим, як мати можливість перевірити стан за допомогою доказів, але механізми стриження можуть зменшити обтяження довіри

Огляд та карта екосистеми

Після проходження технічних деталей кожного рівня взаємодії, визначеного тут, ми можемо підсумувати:

1. Спільний розрахунок дозволяє здійснювати обміни між різними роллапами без зовнішнього заворушення активів та створює внутрішньопротокольні шляхи обміну повідомленнями між усіма підключеними роллапами
2. Спільне послідовне виконання / Супербілдери дозволяють гарантувати виконання наступного блоку у пакетах між роллапами
3. Блок-рівень композиції дозволяє створювати складні, швидкі, залежні пакети для перекидання, що досягають майже рівня узгодження контракту з контрактом.
   → З додаванням спільного розрахунку ці пакети міжролупу можуть бути створені без використання зовнішніх упакованих активів
4. Послідовний рівень комбінування можливий, і, хоча нові випадки використання можуть бути для більш висококваліфікованих користувачів, вони мають потенціал значно покращити досвід розвитку крос-роллапу.

На даний момент існує багато проектів, які виникають для створення цих нативно сумісних екосистем. Ось загальний огляд ландшафту:

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

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

Заключні думки

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

Додатково варто відносити це до поточної популярності, що зростає в галузі appchains. Appchains - це довгополосні L2, які або узагальнені, або з дозволом, з метою утворення силосування конкретних пов'язаних протоколів на одному L2. Ймовірно, коли ми досягнемо компонуваності на рівні блоку, ми також почнемо бачити значний прогрес середовищ appchain внаслідок наявності вбудованої компоновки між усіма підключеними мережами.

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

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

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

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

Подяки

Ця стаття вирісла з надзвичайно плідної круглого столу з інтероперабельності роллапу, яку провів 1kx на EthCC. Особлива подяка йде Noah Pravecek, Еллі Девідсон, та Терріза перегляд ранніх версій цієї статті та надання зворотнього зв'язку, а також до Marti, mteam, та Бо Дудля подальших розмов на цю тему.

Disclaimer：

1. Ця стаття перепечатана з [дзеркалоПересилайте оригінальний заголовок «Trustless Interoperability між Rollups: пейзаж, конструкції та виклики», Усі авторські права належать оригінальному автору [Marshall Vyletel Jr.]. Якщо є заперечення проти цієї перепублікації, будь ласка, зв'яжітьсяВорота Навчаннякоманда, і вони оперативно цим займуться.

2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодної інвестиційної поради.

3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.