Rollup Decentralization (UA)
Ми ідентифікуємо Taiko як децентралізований Ethereum-еквівалент ZK-Rollup. Ethereum-еквівалент - псевдонім ZK-EVM типу 1 - це технічне дизайнерське рішення, яке ми описуємо тут.
У цій публікації ми хотіли б поговорити про інший дескриптор у цій заяві: децентралізований. Ми дослідимо:
- Що таке децентралізований роллап?
- Як децентралізувати роллап?
- Які компроміси при децентралізованому роллапі?
- Підхід Taiko: прогресивна ефективність
- Децентралізоване впровадження та децентралізоване управління
- Як децентралізація є частиною Ethereum еквівалентності
Що таке децентралізований роллап?
Ви можете бути здивовані (або ні), дізнавшись, що існують певні розбіжності щодо визначення децентралізованого роллапу. Однак, ми вважаємо, що можемо досить близько підійти до загальноприйнятого визначення:
Децентралізований рулон - це такий, де будь-який користувач може бути впевнений, що його транзакція буде виконана.
Ми повинні замислитися над тим, чому когось взагалі може хвилювати, децентралізований роллап чи ні. З огляду на те, що для гарантій безпеки роллапи покладаються на L1 (в основному на Ethereum в даний час для провідних роллапів), хіба користувачі не захищені, незважаючи ні на що?
Роллапи гарантують, що поки існує L1 (рівень доступності даних), користувачі можуть відновити стан L2 і вийти з роллапу, примусово виконавши транзакцію на L1. Якщо система не задовольняє цьому обмеженню, то ми б сказали, що вона не є роллапом; це інший тип L2 або сайдчейн. Це повинно дати зрозуміти, що вибір сильно децентралізованого (завжди живого, стійкого до цензури) L1 має вирішальне значення. Ще один нюанс полягає в тому, що для роллапа загального призначення, на відміну від роллапа для конкретного додатка, користувачі повинні мати можливість примусово включити будь-яку довільну транзакцію, а не тільки "вихідні" транзакції.
Після того, як ми встановили, що мова йде про роллап, ми вважаємо, що відмінність, яка визначає роллап як децентралізований чи ні, полягає в тому, наскільки складно або реально для користувача мати можливість змусити свою транзакцію бути включеною до нього. Наприклад, чи потрібні йому дуже потужні обчислювальні ресурси для генерації ZK-доказу? Або вони можуть використовувати споживче обладнання або орендувати дешевий сервер на короткий проміжок часу? Чи існує якийсь привілейований суб'єкт, який має можливість вільно панувати протягом тривалого періоду, що призводить до затримки на 30 днів у спробі бути включеним до переліку? Чим менше заборон, тим більше децентралізація.
Насправді, типовий користувач, швидше за все, хотів би уникнути запуску повної rollup ноди, а у випадку ZK-Rollup - надбудови Prover. Вони хотіли б знати, що роллап, в якому вони здійснюють транзакції - або, можливо, навіть роллап, який вони називають домашнім - сприяє широкому і різноманітному набору учасників, які виконують необхідні функції. І що нові учасники можуть приєднуватися до мережі для виконання цих функцій без дозволу - в тому числі і вони самі, якщо захочуть.
Беручи до уваги вищесказане, давайте завершимо цей розділ ще одним визначенням децентралізованого роллапу, яке допоможе нам краще його зрозуміти:
Децентралізований роллап - це той, в якому кілька сторін можуть брати участь в кожній позиції мережі - тобто, в якості пропонентів, провайдерів і операторів нод.
Це підводить нас до наступного розділу.
Як децентралізувати роллап?
Беручи до уваги наведені вище визначення, особливо друге, можна побачити, що ми можемо децентралізувати роллап, забезпечивши виконання всіх ролей кількома сторонами - в ідеалі, широким і географічно різноманітним набором. Ось ці ролі:
Перш ніж ми розглянемо кожну роль, давайте просто розглянемо питання, порушене в попередньому розділі: роллапи, як рішення L2, вирішують, який L1 вони хочуть масштабувати, або, точніше, який L1 вони будуть використовувати для гарантій безпеки. "Гарантії безпеки" тут означають покладання на L1 для досягнення консенсусу і доступності даних (DA). Хоча це не те, що сам роллап може налаштувати в бік децентралізації, вибір досить децентралізованого L1 є критично важливим рішенням, і Taiko вибирає Ethereum для найбільш надійних гарантій безпеки.
Proposers
Пропоненти (Proposers) створюють роллап блоки з транзакцій користувачів L2 і пропонують їх L1. Іноді в інших роллап системах їх називають Sequencers.
Пропоненти вирішують, які транзакції включати в блок і як їх розміщувати. Це потужна позиція, оскільки вони можуть отримувати прибуток від замовлення транзакцій і вирішувати, які транзакції виключити, і, таким чином, можуть цензурувати певні транзакції, додатки або користувачів.
Як ми встановили - децентралізований rollup повинен дозволити користувачам розраховувати на включення всіх своїх дійсних транзакцій.
Provers
Провайдери (Provers) генерують SNARK-докази, що підтверджують дійсність L2-транзакцій і блоків з вищезазначених запропонованих блоків.
Провайдери вирішують, які запропоновані блоки верифікувати в мережі. Ця позиція визначає, коли блок може досягти стану внутрішньо мережевої перевірки, але не визначає, які транзакції входять в блок, або як вони впорядковані. До цього стану верифікації в мережі, верифікатор може залишити в підвішеному стані певні транзакції, які залежать від доказу дійсності, або залишити в підвішеному стані певні потенційні верифіковані блоки, які чекають, поки їх батьківський блок буде верифікований в мережі.
Як ми встановили —> децентралізований роллап повинен дозволити користувачам розраховувати на верифікацію всіх своїх дійсних транзакцій.
Node runners
Оператори нод виконують транзакції з внутрішньоланцюгових (L1) даних, щоб залишатися синхронізованими із rollup рівнем.
Для виконання своїх ролей пропонентам і провайдерам необхідно запускати повні rollup ноди для виконання своїх відповідних ролей. Інші учасники також захочуть запустити ноди, наприклад, ті, хто пропонує послуги, такі як експлорер блоків, провайдери інфраструктури і користувачі, які хочуть залишатися синхронізованими зі станом ланцюжка з інших причин.
Як ми встановили - децентралізоване розгортання повинно дозволити користувачам розраховувати на виконання всіх своїх дійсних транзакцій.
Примітка: в той час як децентралізація пропонентів / провайдерів є явним рішенням rollup протоколу (наприклад, смарт-контракти можуть бути налаштовані на прийом блоків або підтверджень тільки з дозволених адрес), запуск вузла - це в основному питання ресурсів, яке залежить від зростання штату, вимог до апаратного забезпечення і т.д., і не є явним рішенням протоколу. Забезпечення розумного зростання кількості учасників є критично важливим, але не обговорюється в цій статті.
Які компроміси при децентралізованому роллапі?
Рух вздовж спектру від централізації до децентралізації відкриває місце для компромісів.
У цьому розділі плюси і мінуси застосовуються як до пропонентів, так і до провайдерів (яких ми разом називаємо операторами); ми не будемо розглядати операторів нод, як уже згадувалося, але майте на увазі, що запуск rollup ноди є обов'язковою вимогою для обох ролей.
У контексті rollup пропонентів/провайдерів ми бачимо наступне:
Підхід Тайко: прогресивна ефективність
Поточний підхід, обраний більшістю згорнутих систем загального призначення, спочатку полягав у централізації, а з часом - у поступовій децентралізації. Це мало певний сенс, оскільки є кілька рухомих частин, припущень, які потрібно перевірити, і це ще рано. Наявність централізованого розробника і перевіряючого (він же секвенсор і валідатор в більш широкому сенсі) спростило забезпечення належного і ефективного функціонування роллапу. Ми можемо побачити цей популярний підхід у таблиці нижче.
З іншого боку, Тайко має на меті запустити в роботу повністю децентралізовану (і бездозвільну) систему пропонентів і підтверджувачів. Протокол не буде закріплювати або визначати перелік сторін; будь-хто зможе виконувати ці обов'язки. Крім того, Тайко планує мати мінімальну, визначену протоколом, схему координації для тих, хто пропонує/підтверджує. Поточний план полягає в тому, що вона буде безлідерною.
Всі роллапи обиратимуть "золоту середину", яка відповідає потребам їхніх користувачів. Ця точка буде різною для різних роллапів, і шлях до неї також може бути різним. Ви можете почати централізовано і послабити контроль, або ви можете почати децентралізовано і впровадити жорсткі правила координації (або, можливо, навіть призначити контроль). Безумовно, можливо, що деякі недоліки децентралізації є перешкодами для належного функціонування мережі, і тоді Тайко може застосувати такі заходи, як схеми виборів лідера, щоб уникнути зайвої роботи.
У цьому сенсі підхід Taiko можна вважати прогресивною ефективністю, на відміну від прогресивної децентралізації; рухаючись від повністю децентралізованої і неструктурованої крайності, і більше до середини, якщо це необхідно.
Це не означає, що Taiko з самого початку буде повністю "без тренувальних коліс". Певні заходи, такі як можливість оновлення смарт-контрактів, залишатимуться в силі до тих пір, поки все не буде перевірено в бою. Це обумовлено підходом, орієнтованим на безпеку: без можливості оновлення на основі проксі, активи користувачів можуть зіткнутися зі значними ризиками багів. Контрольована можливість оновлення - один з важелів, який в певний момент буде переданий DAO.
Децентралізоване виконання та децентралізоване управління
Нещодавно Віталік писав, що "децентралізована структура управління захищає від зловмисників зсередини, а децентралізована імплементація захищає від потужних зловмисників ззовні". Це було сказано в контексті DAO - тобто і структура управління, і реалізація стосувалися DAO. Зокрема, це було сказано щодо однієї з цілей децентралізації DAO: надійність.
Ми вважаємо, що досить корисно використовувати цей фреймворк для роллапів в цілому і розділити "структуру управління" на значення DAO роллапу, повну зупинку (приймаючи як належне реалізацію управління на основі смарт-контрактів), і "реалізацію" в значенні самої архітектури ролапу.
У цьому світлі ми досі обговорювали, як роллап може захистити себе від зовнішніх загроз (цензура, збої в роботі) при децентралізованому впровадженні. Ми не повинні нехтувати тим, як роллап може захистити себе від внутрішніх загроз - від організації та спільноти, відповідальних за його створення та підтримку. Інструментом, який є в розпорядженні роллапів, є управління, або, спрощено, його DAO.
Що стосується управління, то Taiko використовує підхід, який схожий на інші роллапи, і схожий на більшість протоколів на Ethereum в цілому, починаючи від DeFi і закінчуючи інфраструктурою. Цей підхід дійсно є підходом прогресивної децентралізації: контроль над протоколом буде поступово передаватися спільноті, а саме - Taiko DAO. Описувати деталі роботи DAO і те, які механізми управління ми б запропонували їй прийняти, поки рано, але це буде темою наступних публікацій.
В якості фінальної думки на цю тему: ми вважаємо, що впровадження пропонує аналіз властивостей роллапів в певний момент часу, в той час як управління може описати, як впровадження може змінюватися з часом, і які сторони можуть приймати ці рішення.
Як децентралізація є частиною еквівалентності Ethereum
У своєму прагненні до чистої еквівалентності Ethereum, Taiko високо цінує пріоритетність децентралізації. Здавалося б, дивно мати еквівалентність як мету, що охоплює EVM, хеш-функції, дерева стану і tx-дерева і т.д., не маючи при цьому на увазі еквівалентність в структурі мережі.
Емуляція Ethereum для Taiko означає, що все вирівнюється в бік Ethereum: ZK-EVM, інша архітектура базового рівня Ethereum, філософські міркування, спільнота і ~вайб~. Це поширюється на децентралізацію мережі та основні властивості, які вона надає розробникам та їх користувачам: стійкість до цензури та живучість.
Ознайомтеся з відкритими вакансіями на нашій дошці.
Слідкуйте за останніми новинами від Тайко:
- Website: https://taiko.xyz
- Discord: https://discord.gg/taikoxyz
- GitHub: https://github.com/taikoxyz
- Reddit: https://www.reddit.com/r/taiko_xyz
- Twitter: https://twitter.com/taikoxyz
Внесіть свій вклад в Taiko і отримайте GitPOAP! Ви також будете представлені як учасник на нашому README. Почніть з гайду для контрибюторів.