Пересилання оригінального заголовка: Розпакування наступного покоління Ethereum L2s (III): Нативні роллапи

Протягом останніх двох років Ethereum повністю зосередився на шляховій карті, спрямованій на роллапи. Ця стратегія передбачає блокування ETH у місті міста, виконання транзакцій поза ланцюгом та використання доведень - або докази шахрайства, або докази знань нульової інформації (ZKP) - для перевірки стану рівня 2 (L2) та обробки виведення.

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

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

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

Засновані, підсилювач, вбудовані... Яка різниця?

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

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

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

Місцеві роллапи використовують власну функцію переходу стану (STF) рівня L1 на рівні застосування як перевірник для переходів стану. Однак, хоча Optimism, Arbitrum та інші роллапи працюють в середовищах, еквівалентних EVM, вони часто включають спеціальні модифікації, які можуть бути складними - або навіть неможливими - для безпосередньої реалізації на Ethereum.

Native rollups, колись відомі як урочисті роллапи, детально обговорювалися в різних матеріалах. Також, тимчасово використовувалось термін "канонічний роллап"@apolynya. Однак, "укоренили" врешті-решт було замінено на "рідний", щоб показати, що існуючі роллапи ЕВМ могли потенційно оновитися до цієї моделі. Термін "рідний" був запропонований @danrobinsonі анонімний учасник від Lido.

Як працюють власні роллапи?

Пропозиція щодо власного роллапу вводить попередню компіляцію EXECUTE, призначену діяти як перевірка для переходів стану роллапу. Ця попередня компіляція дозволить командам роллапу використовувати її в межах своїх контрактів верифікаторів, надаючи основу для систем доказів та дозволяючи роллапам успадковувати валідацію власної Ethereum.

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

Функції попередньої компіляції EXECUTE виступають як перевірка для переходів стану EVM, що дозволяє роллапам використовувати природну інфраструктуру Ethereum на рівні додатків. Вони перевіряють переходи за допомогою введених даних, таких як pre_state_root, post_state_root, trace та gas_used, використовуючи механізм ціноутворення газу, схожий на EIP-1559.

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

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

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

Вибір схожого на EVM верифікатора перед zk-верифікаторами випливає з поточної незрілості технології ZK. Навіть широко використовувані zkVM показали вразливості, а швидкий розвиток ZKPs робить небезпечним і негнучким жорсткодування конкретних zk-верифікаторів на ланцюжку. Ethereum, замість цього, надає перевагу різноманітності та нейтралітету, дозволяючи експериментувати з різними zk-клієнтами без блокування в одному верифікаторі.

Однак це не означає, що передкомпіляція не допомагає в масштабованості Ethereum. В той час як Ethereum забезпечує свою безпеку, тримаючи перевіряльники zk-proof поза ланцюгом, воно використовує цю передкомпіляцію для перевірки zk-proof, що надсилаються роллапами. Це дозволяє валідаторам Ethereum уникнути повного емулювання всіх транзакцій роллапу з початку до кінця. Замість цього, покладаючись на off-chain zk-proof, мережа зберігає свої гарантії безпеки, прагнучи досягти масштабованості з точки зору виконання.

Які основні переваги власних роллапів?

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

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

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

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

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

Чи буде кожен роллап корінним?

Всі поточні стеки роллапів, такі як OP Stack та Arbitrum Orbit Stack, мають потенціал перетворитися на «власні роллапи», безпосередньо успадковуючи захисні функції Ethereum. Це оновлення зробило б користувачів щасливішими завдяки покращеній безпеці, а команди роллапів були б більш задоволені відсутністю потреби у радах з безпеки. Тим часом команди роллапів можуть продовжувати конкурувати, пропонуючи ефективний загальний шар послідовності, все ще захоплюючи плату за послідовність та максимізуючи MEV.

Проте не кожен роллап перейде до становлення власним. Деякі функції L2 несумісні з власними роллапами, включаючи унікальні типи транзакцій, відмінні методи обліку газу та попередні компіляції, які не знайдені на головному блокчейні L1. Різноманіття віртуальних машин серед L2 роллапів, які мають спільний фундамент забезпечення безпеки, є однією з переваг сьогоднішньої L2 екосистеми, як @EclipseFNDбути роллапом SVM,@movementlabsxyzявляючись роллапом MoveVM, або@Starknetбути роллапом CairoVM.

Як відзначено @doganeth_enу майбутньому роллапи поділяться на три категорії: корпоративні роллапи, роллапи, спрямовані на покращення продуктивності, та «вирівняні» власні роллапи.

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

Роллапи, спрямовані на покращення продуктивності, будуть використовувати розрахунок Ethereum, але для досягнення найвищої продуктивності будуть покладатися на альтернативну доступність даних, подібну до gate @megaeth_labsвикористання @eigen_daдля доступності даних. Менш децентралізовані, ці роллапи підсилюють $ETHкорисна, ал компроміс на деяких функціях Ethereum.

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

Висновок

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

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

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

Якщо ви ще не переглянули, обов'язково перевіртечастина Iічастина II нашої серії Rollups 2.0, які зосереджені на зведеннях на основі та бустерних зведеннях відповідно. У нашій наступній публікації ми глибше зануримося в концепцію гігагазових ролапів і дослідимо, як цей інноваційний підхід до дизайну ролапів може розширити межі масштабованості Ethereum і ще більше покращити екосистему зведення.

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

1. Цю статтю перепечатано з [2077 Дослідження]. Переслати оригінальну назву: Розпакування наступного покоління Ethereum L2s (III): Native Rollups. Усі авторські права належать оригінальному автору [2077 Дослідження]. Якщо є зауваження до цього перепублікування, будь ласка, зв'яжіться з Ворота Навчаннякоманда і вони оперативно вирішать це.
2. Відмова від відповідальності: Погляди та думки, висловлені у цій статті, належать виключно автору і не становлять жодного інвестиційного поради.
3. Переклади статті на інші мови здійснює команда навчання Gate. Копіювання, поширення або плагіат перекладених статей заборонено, якщо не зазначено інше.