Вступ

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

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

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

Фрагментація стану на різних rollups призводить до поганого користувацького досвіду, зменшення ефективності капіталу та відсутності власної композиції:

Взаємодія: Фрагментація змушує користувачів часто перемикатися мережами, керувати кількома копіями одного Жетону та балансувати різними гаманцями. Це додає тертю та складності, що робить набагато складнішим для користувачів насолоджуватися безшовним досвідом використання Ethereum з простою роботою. Наприклад, припустимо, що у Еліси є її кошти в rollup A, але вона хоче купити Жетон, доступний лише в Rollup B. Замість просто натискання кнопки «Купити», вона повинна спочатку перемкнутися на іншу мережу, перекинути свої кошти з A до B, почекати підтверджень L1, а потім виконати угоду.

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

Композиція: На одному ланцюжку протокол позики може миттєво ліквідувати позицію, викликавши контракт DEX у тому ж самому транзакції—все відбувається в одному атомному, синхроннийУ фрагментованому, багатороллапному світі цей процес стає асинхронним. Протокол може спровокувати ліквідацію на одному роллапі, а потім чекати повідомлення для завершення на DEX іншого роллапу. Якщо щось піде не так, відміна процесу не є прямолінійною. Також відсутні інструменти, що надаються нативно Ethereum, для здійснення міжроллапних викликів угод або гарантії швидкого виконання цих викликів. Ця втрата негайних, атомарних взаємодій підриває композабельність, яка робить екосистему Ethereum настільки потужною.

Сумісність

У своїй суті взаємодія означає забезпечення транзакції, яка починається на одному роллапі та оновлює стан на іншому — наприклад, надсилання токенів з Роллапу A на Роллап B. Ідеально, ця дія така проста, як зменшення вашого балансу на A і збільшення вашого балансу на B одночасно. На практиці досягнення такої безшовної «все-або-нічого» поведінки викликає складнощі між різними роллапами.

Ідеально, взаємодія між роллапами повинна працювати так само, як на Ethereum L1 - синхронно. В синхронному режимі кілька викликів до різних контрактів в різних роллапах можуть бути об'єднані в одну транзакцію, яка або повністю успішна, або повністю невдачлива, забезпечуючи миттєві та атомарні результати.

Навпаки, асинхронна комбінабельність включає в себе кілька кроків, розподілених у часі на різних rollups. Замість одного атомного транзакції, дія може спричинити подію на одному rollup, а потім чекати підтвердження перед завершенням взаємодії на іншому. Асинхронна комбінабельність потребує вирішення відміни: лише один з rollups може вчасно виконати дію, і потім може знадобитися скасувати цей частковий перехід у стані (оскільки контрарольний rollup не виконав свою частину). Синхронна та асинхронна комбінабельність мають багато спільних викликів, про які ми тут обговорюємо.

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

Виклики взаємодії

Досягнення справжньої сумісності між rollups - це не просто обмін повідомленнями вздовж і впоперек; це забезпечення безпечного та швидкого завершення транзакцій. Покладання тільки на Ethereum L1 може означати довгі затримки та високі витрати. У Еліс є кошти на rollup A, але вона хоче купити токен, доступний лише на Rollup B. Є два можливі варіанти:

• Rollup B приймає кошти лише від Аліси, якщо вони перейшли через Ethereum. У цьому випадку Алісі потрібно зняти свої кошти на L1, потім внести їх на rollup B, і, нарешті, придбати токен на rollup B, що призводить до великих затримок і витрат.
• Rollup B надає швидший, дешевший шлях, обробляючи переказ безпосередньо, а не вирішуючи спочатку на Ethereum Layer 1. Однак, як ми пояснюємо нижче, це викладає Rollup B ризикам потенційних переорганізацій, якщо Rollup A збивається з пуття, не вирішує або подає недійсний стан переходу.

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

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

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

Давайте проілюструємо ці виклики на прикладі: припустимо, що Еліс володіє 10 ETH на основній мережі Scroll і хоче передати їх Бобу в Arbitrum. Ідеально, Еліс змогла б переміщувати ліквідність між цими двома ланцюжками при швидкості, вищій за ефіреум. Припустимо, що існувало б таке рішення, в якому Arbitrum зарахував би Еліс 10 ETH в Arbitrum, перш ніж Scroll щось подасть на L1, що може піти не так для Arbitrum?

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

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

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

Обидва несудове вирішення та недійсність будуть легко вирішені, як тільки стане можливим реальний час генерації доказу zk (тобто реальний час підтвердження). Проблема двозначності втім фундаментально відрізняється. Доказ zk може підтвердити, що Еліс відправила 10 ETH Бобу на Arbitrum, але це не гарантує, що Scroll здійснить цей перехід на L1. Самі докази zk не вирішують і ніколи не вирішать двозначність. Знову таки, чекання L1 вирішення вирішує двозначність, але за ціною переваги швидкості rollup. Таким чином, ми фокусуємося на попередній двозначності, тобто гарантіях попередження двозначності до вирішення на Ethereum. Як ми побачимо, кожен підхід включає різні компроміси, зокрема щодо припущень щодо довіри, про які ми обговорюємо нижче.

Архітектура взаємодії

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

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

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

Мережа

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

З появою все більшої кількості ролапів, які стають взаємопов'язаними в цій великій мережі, транзитивність довіри та залежності стає проблемою масштабованості. Якщо Arbitrum довіряє Scroll, але не довіряє zkSync, то Scroll не може довіряти zkSync, зберігаючи довіру до Arbitrum. Тільки взаємно виключні «групи довіри», тобто кліки ролапів, можуть взаємодіяти одна з одною в мережі. Ця проблема залежності посилюється з появою все більшої кількості ролапів у складних випадках взаємодії, де безпека всієї системи обмежується безпекою найслабшого ролапу.

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

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

Центр

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

Перевага цього рішення полягає в тому, що додавання додаткових rollups у змішування не створює більше проблем залежності, оскільки проміжний прошарок діє як "щит" між кожним rollup. Це може включати будь-які довільні ланцюги L2, а також L3s та app rollups - все, що вони повинні зробити, це бути інтегрованими в хаб та насолоджуватися перевагами.

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

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

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

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

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

Існуючі системи

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

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

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

Системи хабів. Еспресо та zkSync Еластичний ланцюгсистеми-центри. У Scroll ми досліджували дизайн центру, який може забезпечити більш масштабовані та надійні рішення для взаємодії. Наш презентація на Columbia CryptoEconomics Workshop 2024 надає огляд дизайну з більш детальною інформацією в наступній публікації.

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

AggLayer Polygon - це ще один тип системи хабів, яка забезпечує спільний шар, з яким всі rollups спілкуються. Однак він відрізняється тим, що уникне додаткових довірчих припущень в цьому спільному шарі. Замість цього вони чекають на вирішення та використовуютьпесимістичні доказищоб забезпечити безпеку. Таким чином, двозначність уникнена лише в час врегулювання. Попередні підтвердження можуть застосовуватися необов'язково для надання швидших гарантій остаточності. AggLayer недавно оголосив проПартнерствоз системами Espresso, яка забезпечує спільний механізм послідовності.

Висновок

Розробка механізму запобігання двозначності для взаємодії швидше, ніж Ethereum, пов'язана з усілякими компромісами, які необхідно ретельно розглянути заради безпеки, децентралізації та надійного нейтралітету. Хоча ця публікація була зосереджена на запобіганні двозначності, є кілька інших критичних проблем взаємодії, які ми тут глибоко не обговорювали, такі як доступність даних, дизайн розрахункового рівня (наприклад, впровадження спільних контрактів на міст і зведення між різними зведеннями), протоколи передачі повідомлень та економічні стимули, необхідні для того, щоб система працювала. Але як сказав Віталік у нещодавньому твіті, ми ближче до вирішення цих крос-чейн проблем, ніж думає більшість людей. Ми вважаємо, що в цьому кінцевому підсумку взаємодії користувачі дійсно відчують, що вони «використовують один Ethereum», а не окремі зведення, як сьогодні.

Відмова від відповідальності:

1. Ця стаття передрукована з [Дослідження Scroll]. Усі авторські права належать оригінальному авторові [Алехандро Ранчаль-Педроса]. Якщо є зауваження до цього перевидання, будь ласка, зверніться до Gate Learnкоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Команда Gate Learn здійснює переклади статей на інші мови. Копіювання, поширення або плагіат перекладених статей заборонені, якщо не зазначено інше.