Інтерпретація важливості децентралізації Rollup з різних точок зору

Автор оригіналу: Шиваншу Мадан

Оригінальний збірник: Luffy, Foresight News

Останнім часом багато дискусій у Crypto Twitter обертаються навколо децентралізації рівня 2. Чи достатньо децентралізовано зведений пакет, який ми створюємо? Вони вже на шляху до децентралізації? Це важливо?

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

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

Отже, чи потрібен нам децентралізований зведений пакет?

Інтуїтивно зрозуміла відповідь: однозначно потрібно! Це дух блокчейну.

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

Філософська перспектива

Давайте почнемо з того, що піднімемо розмову на новий рівень: чому нам потрібна децентралізація?

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

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

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

——Престон Еванс

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

Фактично, це піднімає цікаве та важливе питання:

Якщо Rollup не децентралізований, чи означає це, що Ethereum не децентралізований?

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

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

Отже, що таке правильна реалізація Rollup? давайте подивимось:

Технічна перспектива

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

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

Особливо в Rollup повні вузли та легкі клієнти мають різні правила підтвердження. У традиційному інтелектуальному контракті Rollup (SCR) смарт-контракт (міст перевірки) має власні правила підтвердження. Якщо побічних явищ немає, ці правила підтвердження зрештою збігаються в так званих «областях узгодженості». Як випливає з назви, у зоні консенсусу всі учасники мають однакове уявлення про мережу (і однакову історію в реєстрі).

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

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

Перші 2 властивості визначають «живий» стан системи, тоді як останні 3 властивості визначають «безпечний» стан.

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

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

Повний вузол:

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

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

Легкий клієнт:

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

• Валідатори стану - перевіряють валідність переходів станів
• Data Availability Verifier - Перевірка доступності даних
• Валідатори консенсусу - перевірте підтвердження консенсусу базового рівня
• Повний засіб перевірки - перевіряє все вищезазначене

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

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

Вбудований смарт-контракт (перехідний міст):

У традиційному SCR «правило підтвердження» смарт-контракту полягає в застосуванні всіх 5 властивостей безпеки:

• Зростання книги через протокол заміни секвенсора
• Протистояти цензурі, забезпечуючи включення
• Створює попередній стан для запобігання рекомбінації
• Реалізуйте доступність даних, надаючи DA на базовому рівні *Дійсність підтверджена доказом дійсності/шахрайства

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

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

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

А як щодо зведених суверенних кредитів?

Sovereign Rollups не мають смарт-контрактів (підтверджувальних мостів) для забезпечення дотримання умов дійсності чи живучості. Замість цього вони виявлятимуть «згортання» до нижчих вузлів Rollup. Ці вузли все ще покладаються на доступність даних і стійкість до реорганізації базового рівня.

Як і в SCR, у вузлах Sovereign Rollup потрібен певний механізм для забезпечення властивості живучості. Щоб визначити канонічний ланцюг, вони вибрали незалежні механізми, такі як трансляція доказів p2p.

Яке все це має відношення до децентралізації?

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

• Механізм обов'язкового включення;
• Протокол заміни секвенсора.

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

Але чи достатньо цього?

Навіть якщо користувачі можуть вийти, це може означати, що L2 не матиме особливого стимулу продовжувати роботу, якщо більшість користувачів повертаються до L1. Крім того, механізм обов’язкового включення зазвичай має тривалий час очікування, і його впровадження може бути досить дорогим для середнього користувача. Опір цензурі, який забезпечує цей механізм, не зовсім практичний (або в реальному часі), ми можемо назвати його «слабкою цензурою».

Потім у нас є останній атрибут активності - зростання книги.

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

Щоб вирішити цю проблему, нам потрібен протокол заміни сортувальника.

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

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

це все?

не повністю. З технічної точки зору варто врахувати ще один аспект:

Що, якби самі розумні контракти могли бути оновлені центральним комітетом Rollup? Скажімо, Rollup наразі реалізовано правильно, але завтра комітет погодиться, що нам більше не потрібні смарт-контракти, а натомість транслюватимуть докази стану Rollup у мережу p2p.

Якщо, як користувач Rollup, ви не згодні з таким оновленням, ви повинні мати можливість вийти з Rollup до того, як оновлення буде запроваджено (хоча це не дуже добре для користувачів і може бути поганим для бізнесу). Цього можна досягти за допомогою «відкладених оновлень керування», як-от «період сповіщення», після якого буде реалізовано оновлення. Користувачі, які не погоджуються на оновлення, можуть відмовитися протягом періоду повідомлення.

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

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

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

Відповідно до L2 BEAT, Fuel v1 і DeGate є єдиними двома зведеними пакетами, які досягли всіх умов діяльності та безпеки.

Економічна перспектива

Нарешті, давайте подивимося на економіку Rollup з точки зору користувачів і операторів Rollup:

• Взаємодія з користувачем: користувачі повинні отримувати низькі ціни та не чекати занадто довго на транзакції;
• Зведений прибуток: Секвенсери та власники токенів мають бути прибутковими.

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

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

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

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

Як щодо витрат користувача?

Явна вартість зведеної транзакції зазвичай становить:

Вартість газу L2 = вартість газу L1 + плата за секвенсор. Раціональні централізовані сортувальники завжди хочуть максимізувати свій прибуток, навіть якщо це означає перекладання вищих витрат на користувачів. Однак варто зазначити, що це також не обов’язково можна вирішити за допомогою децентралізованого механізму сортування. Навіть вузли PoS у децентралізованому замовнику хочуть максимізувати власні прибутки.

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

Rollup Profit: крім комісії секвенсора, Rollup також може отримувати прибуток, витягуючи MEV з транзакцій користувачів. Цей MEV часто важко віднести, оскільки важко з’ясувати, чи включає замовник деякі з власних первинних транзакцій у пакет транзакцій.

Якщо Rollup буде замінено зовнішнім консенсусом PoS, вони передадуть цей MEV зовнішньому оператору.

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

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

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

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

У будь-якому випадку, для того, щоб Rollup був економічно ефективним для користувачів, потрібен певний протокол заміни сортувальника.

на закінчення

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

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