Native Rollups використовують власний STF L1 як валідатор стану на рівні застосування.
Написав: Спільнота в'єтнамського ланцюга
Протягом останніх двох років Ethereum повністю присвятив себе шляху "Rollup-центру". Ця стратегія включає в себе блокування ETH у місткі контракти, виконання угод поза ланцюгом та використання доказів - чи то доказів шахрайства, чи то доказів знань (ZKP) - для перевірки стану та обробки виведення на Layer2 (L2).
!
Проте існує велике викликання: Ethereum сам по собі не надає перевірку виконання EVM, що змушує роллапи незалежно від ланцюжка втілювати власну систему підтвердження для перевірки переходу стану.
Ефіріум часто зазнає важких розділень, що може призвести до змін у EVM, що означає, що команда роллапів повинна бути відповідальною за підтримку та оновлення своїх власних реалізацій. Це, як правило, вимагає створення комісії з безпеки або впровадження системи управління на основі голосування за токени, щоб керувати оновленнями їх місткіх контрактів та механізмів підтвердження.
У нашій попередній серії ми розглянули Based rollup та Booster rollup. Тепер ми перейдемо до більш глибокого вивчення концепції роллапів.
Яка різниця між Based、Booster та нативним?
Можливо, існує багато плутанини між визначеннями Based rollup, Booster rollup та оригінального rollup. У попередніх статтях ми вже розглянули Based rollup та Booster rollup, тому радимо переглянути їх перед читанням цього тексту. Проте ми швидко підсумуємо ці три типи.
На основі rollups використовується набір перевіряючих L1 для сортування транзакцій, що сприяє децентралізації, але через відносно довгий час блоку L1 (наприклад, 12 секунд) може впливати на пропускну здатність. Тим не менше, намагаються поліпшити цей досвід, використовуючи технологію попередньої підтвердження, щоб користувачі могли насолоджуватися швидшим підтвердженням транзакцій під час постійних інновацій у громаді.
Booster Rollups розширюють виконання та зберігання, симулюючи обробку на L1 на L2, щоб застосунки могли масштабуватися без необхідності повторної розгортки. Цей підхід, хоч і забезпечує масштабованість, порівняно з традиційними роллапами, вносить додаткову складність, що потребує більш складних інженерних зусиль для розробки та підтримки.
Нативні роллапи використовують функцію переходу стану L1 (STF) як верифікатор переходу стану на рівні застосування. Однак, хоча Optimism, Arbitrum та інші роллапи працюють в еквівалентному середовищі, такому як EVM, вони зазвичай містять складні або нереалістичні власні модифікації, які не можна безпосередньо реалізувати на Ethereum.
Оригінальний роллапи колись називався законним роллапи і детально обговорювався в різних письмах. Крім того, термін "нормативний rollup" коротко використовувався @apolynya. Однак термін "законний" в кінцевому підсумку був замінений на "оригінальний", щоб показати, що існуючі еквівалентні роллапи EVM можуть бути оновлені до цієї моделі. Термін "оригінальний" був запропонований @danrobinson та анонімним учасником з Lido.
Як працює оригінальний роллап?
Пропозиція про впровадження виконання Rollup вводить попередню компіляцію EXECUTE, яка призначена для використання у валідаторі переходу стану Rollup. Ця попередня компіляція дозволить команді Rollup використовувати її у своєму контракті валідатора, щоб надати системі підтвердження на основі Based, а також успадкувати від Ethereum відповідну перевірку.
Оскільки цей новий прекомпілятор у певній мірі схожий на концепцію «EVM в EVM», він буде оновлюватися в рамках соціальної згоди Ethereum через процес хардфорка, що забезпечить відображення змін в EVM у прекомпіляторі, дозволяючи rollup успадкувати підтвердження Ethereum та зменшувати відповідальність команди rollup у сфері безпеки або управління багатопідписними, тим самим забезпечуючи користувачам більш фундаментальну безпеку.
ВИКОНАТИ ПЕРЕДКОМПІЛЯЦІЮ Як перевірник стану EVM, що дозволяє роллапам використовувати вбудовані засоби Ethereum на рівні застосування. Він використовує введення, такі як pre_state_root, post_state_root, trace та gas_used, для перевірки перетворення за допомогою механізму ціноутворення газу, схожого на EIP-1559. З урахуванням потреб у масштабованості роллап, перевірники можуть змусити виконання правильності перетворення стану роллап шляхом повторного виконання або доведенням SNARK. Крім того, вбудовано затримку по одному слоту для пом'якшення централізованого ризику, такого як змагання за MEV на основі доказів.
Ця попередньо скомпільована програма спрощує розробку rollups, підтримуючи 'rollup без довіри' в системі доведень. Якщо поєднати з дизайном Based rollup, де сортування та система доведень управляються Ethereum, ця структура може досягти повної бездовірності, що часто називається 'ultrasound rollup'. Вона підвищує комбінативність та має потенціал для реального розрахунку, що стимулює розробку rollup з більшою комбінативністю та безпекою.
Запропонована попередня компіляція дій подібна до EVM, повторне виконання угод rollup для перевірки їх правильності. Це протирічить основним перевагам rollup, оскільки їх перевага полягає в виконанні поза ланцюгом, подання лише доказів дійсності до Ethereum. Навпаки, попередня компіляція суттєво відображає те, що Ethereum вже робив, і не додає жодної вартості у зменшенні обчислювального навантаження з L1.
Вибір валідаторів, схожих на EVM, а не zk-валідаторів, обумовлений недосконалістю поточної технології ZK. Застосований на широку шкалу zkVM вже показав свою вразливість, а швидке розвиток ZKP призводить до ризику та негнучкості при жорсткому закодуванні конкретних zk-валідаторів на ланцюгу. На відміну від цього, Ethereum надає перевагу різноманітності та нейтральності, дозволяючи експериментувати з різними zk-клієнтами, а не блокуючи себе на одному валідаторі.
Проте це не означає, що попередня компіляція не дала внесок у масштабованість Ethereum. Хоча Ethereum забезпечує свою безпеку, тримаючи zk-перевірювачі поза ланцюгом, вона використовує цю попередню компіляцію для перевірки zk-доказів, наданих rollup. Це дозволяє верифікаторам Ethereum уникати повного моделювання всіх rollup-транзакцій з нуля до кінця. Натомість, покладаючись на зовнішні zk-докази, мережа зберігає свої гарантії безпеки, одночасно прагнучи досягти масштабованості у виконанні.
Основна перевага роллапів полягає в чому?
За допомогою вбудованого роллапу багато складних операцій можуть бути попередньо обробленими, що робить шахрайське доказування або перевірку SNARK більш простими. Це означає, що потрібно менше коду для написання та підтримки, не потрібні додаткові системи, такі як мережа доведення або комісія з безпеки.
На високих витратах перевірки SNARK на ланцюжку, багато zk-rollup рідко розраховують транзакції для зменшення витрат. Попереднє компілювання EXECUTE може допомогти знизити ці витрати, об'єднуючи кілька доказів за допомогою SNARK у рекурсивний спосіб. Цей метод дозволяє ефективніше перевіряти транзакції в rollup, тим самим забезпечуючи більш вигідну вартість перевірки поза ланцюжком.
У традиційних роллапах забезпечення відсутності помилок - виклик, який зазвичай вимагає обширної перевірки. Багато команд знижують ризик, приймаючи централізоване сортування, щоб запобігти виникненню зловмисних блоків. Однак за допомогою попередньо компільованого виконання можливе створення більш безпечного та бездозвільного механізму сортування. Цей підхід дозволяє роллапу успадкувати безпеку L1 та забезпечує замінність активів, оскільки угоди перевіряються безпосередньо в довірчому середовищі Ethereum.
Є багато роллапів, сумісних з EVM, але майже немає еквівалентних EVM: зазвичай для оновлення роллапу, щоб він відповідав змінам у головному ланцюжку блоків, потрібна команда або система голосування, що може призвести до ризику. Вбудований роллап може автоматично оновлюватися разом з головним ланцюжком блоків, узгоджуючи все без додаткових правил або голосувань.
Для zk-роллапів досягнення дуже низького часу підтвердження, наприклад 100 мілісекунд, є завданням високої складності. У порівнянні з цим, вбудовані роллапи можуть дозволяти більш "повільний" графік підтвердження, розширити його до повної слоти. Цей підхід зменшує тиск на миттєве створення підтверджень, можливо, підвищує надійність та посилює інтеграцію з L1.
Чи всі роллапи будуть нативними?
Усі стеки rollup, такі як OP Stack та Arbitrum Orbit Stack, мають потенціал перетворитися на «інші роллапи», що безпосередньо успадковують безпекові характеристики Ethereum. Це оновлення зробить користувачів більш задоволеними, оскільки безпека буде посилена, а команди rollup відчуватимуть себе більш спокійно, оскільки їм більше не потрібно буде радитися з комісією з безпеки. Тим часом, команди rollup все ще зможуть продовжувати конкурувати, надаючи ефективний шар спільного сортування, та отримувати витрати на сортування, максимізуючи MEV.
Проте не всі роллапи будуть переходити до первинної форми. Деякі L2 функції несумісні з первинними роллапами, включаючи унікальні типи угод, різні методи рахування газу та попередньо скомпільовані файли, які не можна знайти на головному ланцюжку L1. Різноманітність VM між L2 роллапами, які спільно використовують одну загальну базу безпеки, є великою перевагою сьогоднішньої L2 екосистеми, наприклад,
@EclipseFND є SVM роллап
@movementlabsxyzMoveVM зведення
@Starknet - це CairoVM rollup
Як вказав @doganeth_en, майбутні роллапи будуть поділені на три категорії: корпоративні роллапи, роллапи, орієнтовані на продуктивність, а також «вирівнювання» власні роллапи.
Підприємства будуть зосереджуватися на управлінні, сортуванні та володінні своїми роллапи, що дуже підходить для компаній, які бажають мати контроль, схожий на web2, щодо порядку виконання угод та додатків.
Роллапи, орієнтовані на продуктивність, використовуватимуть розрахунки Ethereum, але покладатимуться на альтернативну доступність даних для оптимальної продуктивності, наприклад @megaeth_labs з @eigen_da для доступності даних. Ці роллапи менш децентралізовані, але збільшують корисність ETH за рахунок певних функцій Ethereum.
Нативні роллапи будуть повністю інтегровані з інфраструктурою Based Ethereum та нададуть: децентралізований рівень Ethereum, спільне виконання з прямим доступом до стану та дешевшу позацепочкову перевірку ZK. Ці роллапи сприяють мережевому ефекту Ethereum, можливо, діляться прибутком, але їхній розвиток залежить від природних економічних стимулів.
Висновок
Нативні роллапи представляють собою значний прогрес у центральному шляху розвитку роллапів Ethereum, забезпечуючи спосіб більш відповідний для інфраструктури, заснованої на Ethereum. Шляхом введення попередньої компіляції EXECUTE, нативні роллапи спрощують управління, усувають залежність від багатоадресних підписів, комітету з безпеки або системи голосування на основі токенів. Цей підхід не лише збільшує безпеку, але й дозволяє роллапам більш ефективно масштабуватися, використовуючи off-chain zk-докази, тим самим забезпечуючи мінімізацію довіри та масштабованість.
Незважаючи на широкі перспективи цього пропозиції, вона не є безвикликовою. Навіть якщо більшість існуючих роллапів вважаються еквівалентними EVM, вони зазвичай мають невеликі зміни в EVM. Тому перехід до моделі нативного роллапу може становити додаткове завдання для розробки роллапів з власною реалізацією EVM.
Незважаючи на це, власні роллапи надають привабливий шлях, що поєднує безпеку та гнучкість Ethereum з дизайном rollup. Сприяючи вирівнюванню з L1, вони стимулюють інновації, одночасно зменшуючи фрагментацію, зроблять екосистему Ethereum майбутнього ще щільнішою та стійкою.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Розшифровка наступного покоління Ethereum L2: нативні роллапи
Native Rollups використовують власний STF L1 як валідатор стану на рівні застосування.
Написав: Спільнота в'єтнамського ланцюга
Протягом останніх двох років Ethereum повністю присвятив себе шляху "Rollup-центру". Ця стратегія включає в себе блокування ETH у місткі контракти, виконання угод поза ланцюгом та використання доказів - чи то доказів шахрайства, чи то доказів знань (ZKP) - для перевірки стану та обробки виведення на Layer2 (L2).
!
Проте існує велике викликання: Ethereum сам по собі не надає перевірку виконання EVM, що змушує роллапи незалежно від ланцюжка втілювати власну систему підтвердження для перевірки переходу стану.
Ефіріум часто зазнає важких розділень, що може призвести до змін у EVM, що означає, що команда роллапів повинна бути відповідальною за підтримку та оновлення своїх власних реалізацій. Це, як правило, вимагає створення комісії з безпеки або впровадження системи управління на основі голосування за токени, щоб керувати оновленнями їх місткіх контрактів та механізмів підтвердження.
У нашій попередній серії ми розглянули Based rollup та Booster rollup. Тепер ми перейдемо до більш глибокого вивчення концепції роллапів.
Яка різниця між Based、Booster та нативним?
Можливо, існує багато плутанини між визначеннями Based rollup, Booster rollup та оригінального rollup. У попередніх статтях ми вже розглянули Based rollup та Booster rollup, тому радимо переглянути їх перед читанням цього тексту. Проте ми швидко підсумуємо ці три типи.
На основі rollups використовується набір перевіряючих L1 для сортування транзакцій, що сприяє децентралізації, але через відносно довгий час блоку L1 (наприклад, 12 секунд) може впливати на пропускну здатність. Тим не менше, намагаються поліпшити цей досвід, використовуючи технологію попередньої підтвердження, щоб користувачі могли насолоджуватися швидшим підтвердженням транзакцій під час постійних інновацій у громаді.
Booster Rollups розширюють виконання та зберігання, симулюючи обробку на L1 на L2, щоб застосунки могли масштабуватися без необхідності повторної розгортки. Цей підхід, хоч і забезпечує масштабованість, порівняно з традиційними роллапами, вносить додаткову складність, що потребує більш складних інженерних зусиль для розробки та підтримки.
Нативні роллапи використовують функцію переходу стану L1 (STF) як верифікатор переходу стану на рівні застосування. Однак, хоча Optimism, Arbitrum та інші роллапи працюють в еквівалентному середовищі, такому як EVM, вони зазвичай містять складні або нереалістичні власні модифікації, які не можна безпосередньо реалізувати на Ethereum.
Оригінальний роллапи колись називався законним роллапи і детально обговорювався в різних письмах. Крім того, термін "нормативний rollup" коротко використовувався @apolynya. Однак термін "законний" в кінцевому підсумку був замінений на "оригінальний", щоб показати, що існуючі еквівалентні роллапи EVM можуть бути оновлені до цієї моделі. Термін "оригінальний" був запропонований @danrobinson та анонімним учасником з Lido.
Як працює оригінальний роллап?
Пропозиція про впровадження виконання Rollup вводить попередню компіляцію EXECUTE, яка призначена для використання у валідаторі переходу стану Rollup. Ця попередня компіляція дозволить команді Rollup використовувати її у своєму контракті валідатора, щоб надати системі підтвердження на основі Based, а також успадкувати від Ethereum відповідну перевірку.
Оскільки цей новий прекомпілятор у певній мірі схожий на концепцію «EVM в EVM», він буде оновлюватися в рамках соціальної згоди Ethereum через процес хардфорка, що забезпечить відображення змін в EVM у прекомпіляторі, дозволяючи rollup успадкувати підтвердження Ethereum та зменшувати відповідальність команди rollup у сфері безпеки або управління багатопідписними, тим самим забезпечуючи користувачам більш фундаментальну безпеку.
ВИКОНАТИ ПЕРЕДКОМПІЛЯЦІЮ Як перевірник стану EVM, що дозволяє роллапам використовувати вбудовані засоби Ethereum на рівні застосування. Він використовує введення, такі як pre_state_root, post_state_root, trace та gas_used, для перевірки перетворення за допомогою механізму ціноутворення газу, схожого на EIP-1559. З урахуванням потреб у масштабованості роллап, перевірники можуть змусити виконання правильності перетворення стану роллап шляхом повторного виконання або доведенням SNARK. Крім того, вбудовано затримку по одному слоту для пом'якшення централізованого ризику, такого як змагання за MEV на основі доказів.
Ця попередньо скомпільована програма спрощує розробку rollups, підтримуючи 'rollup без довіри' в системі доведень. Якщо поєднати з дизайном Based rollup, де сортування та система доведень управляються Ethereum, ця структура може досягти повної бездовірності, що часто називається 'ultrasound rollup'. Вона підвищує комбінативність та має потенціал для реального розрахунку, що стимулює розробку rollup з більшою комбінативністю та безпекою.
! image-20240930222847819.png
Запропонована попередня компіляція дій подібна до EVM, повторне виконання угод rollup для перевірки їх правильності. Це протирічить основним перевагам rollup, оскільки їх перевага полягає в виконанні поза ланцюгом, подання лише доказів дійсності до Ethereum. Навпаки, попередня компіляція суттєво відображає те, що Ethereum вже робив, і не додає жодної вартості у зменшенні обчислювального навантаження з L1.
Вибір валідаторів, схожих на EVM, а не zk-валідаторів, обумовлений недосконалістю поточної технології ZK. Застосований на широку шкалу zkVM вже показав свою вразливість, а швидке розвиток ZKP призводить до ризику та негнучкості при жорсткому закодуванні конкретних zk-валідаторів на ланцюгу. На відміну від цього, Ethereum надає перевагу різноманітності та нейтральності, дозволяючи експериментувати з різними zk-клієнтами, а не блокуючи себе на одному валідаторі.
Проте це не означає, що попередня компіляція не дала внесок у масштабованість Ethereum. Хоча Ethereum забезпечує свою безпеку, тримаючи zk-перевірювачі поза ланцюгом, вона використовує цю попередню компіляцію для перевірки zk-доказів, наданих rollup. Це дозволяє верифікаторам Ethereum уникати повного моделювання всіх rollup-транзакцій з нуля до кінця. Натомість, покладаючись на зовнішні zk-докази, мережа зберігає свої гарантії безпеки, одночасно прагнучи досягти масштабованості у виконанні.
Основна перевага роллапів полягає в чому?
За допомогою вбудованого роллапу багато складних операцій можуть бути попередньо обробленими, що робить шахрайське доказування або перевірку SNARK більш простими. Це означає, що потрібно менше коду для написання та підтримки, не потрібні додаткові системи, такі як мережа доведення або комісія з безпеки.
На високих витратах перевірки SNARK на ланцюжку, багато zk-rollup рідко розраховують транзакції для зменшення витрат. Попереднє компілювання EXECUTE може допомогти знизити ці витрати, об'єднуючи кілька доказів за допомогою SNARK у рекурсивний спосіб. Цей метод дозволяє ефективніше перевіряти транзакції в rollup, тим самим забезпечуючи більш вигідну вартість перевірки поза ланцюжком.
У традиційних роллапах забезпечення відсутності помилок - виклик, який зазвичай вимагає обширної перевірки. Багато команд знижують ризик, приймаючи централізоване сортування, щоб запобігти виникненню зловмисних блоків. Однак за допомогою попередньо компільованого виконання можливе створення більш безпечного та бездозвільного механізму сортування. Цей підхід дозволяє роллапу успадкувати безпеку L1 та забезпечує замінність активів, оскільки угоди перевіряються безпосередньо в довірчому середовищі Ethereum.
Є багато роллапів, сумісних з EVM, але майже немає еквівалентних EVM: зазвичай для оновлення роллапу, щоб він відповідав змінам у головному ланцюжку блоків, потрібна команда або система голосування, що може призвести до ризику. Вбудований роллап може автоматично оновлюватися разом з головним ланцюжком блоків, узгоджуючи все без додаткових правил або голосувань.
Для zk-роллапів досягнення дуже низького часу підтвердження, наприклад 100 мілісекунд, є завданням високої складності. У порівнянні з цим, вбудовані роллапи можуть дозволяти більш "повільний" графік підтвердження, розширити його до повної слоти. Цей підхід зменшує тиск на миттєве створення підтверджень, можливо, підвищує надійність та посилює інтеграцію з L1.
Чи всі роллапи будуть нативними?
Усі стеки rollup, такі як OP Stack та Arbitrum Orbit Stack, мають потенціал перетворитися на «інші роллапи», що безпосередньо успадковують безпекові характеристики Ethereum. Це оновлення зробить користувачів більш задоволеними, оскільки безпека буде посилена, а команди rollup відчуватимуть себе більш спокійно, оскільки їм більше не потрібно буде радитися з комісією з безпеки. Тим часом, команди rollup все ще зможуть продовжувати конкурувати, надаючи ефективний шар спільного сортування, та отримувати витрати на сортування, максимізуючи MEV.
Проте не всі роллапи будуть переходити до первинної форми. Деякі L2 функції несумісні з первинними роллапами, включаючи унікальні типи угод, різні методи рахування газу та попередньо скомпільовані файли, які не можна знайти на головному ланцюжку L1. Різноманітність VM між L2 роллапами, які спільно використовують одну загальну базу безпеки, є великою перевагою сьогоднішньої L2 екосистеми, наприклад,
Як вказав @doganeth_en, майбутні роллапи будуть поділені на три категорії: корпоративні роллапи, роллапи, орієнтовані на продуктивність, а також «вирівнювання» власні роллапи.
Підприємства будуть зосереджуватися на управлінні, сортуванні та володінні своїми роллапи, що дуже підходить для компаній, які бажають мати контроль, схожий на web2, щодо порядку виконання угод та додатків.
Роллапи, орієнтовані на продуктивність, використовуватимуть розрахунки Ethereum, але покладатимуться на альтернативну доступність даних для оптимальної продуктивності, наприклад @megaeth_labs з @eigen_da для доступності даних. Ці роллапи менш децентралізовані, але збільшують корисність ETH за рахунок певних функцій Ethereum.
Нативні роллапи будуть повністю інтегровані з інфраструктурою Based Ethereum та нададуть: децентралізований рівень Ethereum, спільне виконання з прямим доступом до стану та дешевшу позацепочкову перевірку ZK. Ці роллапи сприяють мережевому ефекту Ethereum, можливо, діляться прибутком, але їхній розвиток залежить від природних економічних стимулів.
Висновок
Нативні роллапи представляють собою значний прогрес у центральному шляху розвитку роллапів Ethereum, забезпечуючи спосіб більш відповідний для інфраструктури, заснованої на Ethereum. Шляхом введення попередньої компіляції EXECUTE, нативні роллапи спрощують управління, усувають залежність від багатоадресних підписів, комітету з безпеки або системи голосування на основі токенів. Цей підхід не лише збільшує безпеку, але й дозволяє роллапам більш ефективно масштабуватися, використовуючи off-chain zk-докази, тим самим забезпечуючи мінімізацію довіри та масштабованість.
Незважаючи на широкі перспективи цього пропозиції, вона не є безвикликовою. Навіть якщо більшість існуючих роллапів вважаються еквівалентними EVM, вони зазвичай мають невеликі зміни в EVM. Тому перехід до моделі нативного роллапу може становити додаткове завдання для розробки роллапів з власною реалізацією EVM.
Незважаючи на це, власні роллапи надають привабливий шлях, що поєднує безпеку та гнучкість Ethereum з дизайном rollup. Сприяючи вирівнюванню з L1, вони стимулюють інновації, одночасно зменшуючи фрагментацію, зроблять екосистему Ethereum майбутнього ще щільнішою та стійкою.