Послідовності = Агрегатор + Виробник заголовків

• Переслано оригінальну назву: Дослідник Celestia аналізує 6 варіантів Rollup: Секвенсор=агрегатор+генератор заголовків

Примітка: Щоб полегшити розуміння та аналіз моделі Rollup, дослідник Celestia NashQ розділив секвенсор Rollup Sequencer на дві логічні сутності - Агрегатор (Aggregator) і Виробник заголовків (Header Producer). При цьому він розділив процес замовлення транзакції на три логічні етапи: включення, замовлення та виконання.

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

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

Що таке ролловер?

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

Чому я змінюю слово "блок" на "дані про транзакцію"? Дозвольте мені пояснити вам різницю між блоком згортання і даними згортання, а також показати, що для мінімального згортання потрібні лише дані згортання в нашому першому варіанті.

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

Варіант 1: Песимістичний сценарій розвитку подій

Найпростіший спосіб створення роллапу починається з того, що користувач публікує транзакції в іншому блокчейні. Ми будемо називати цей блокчейн рівнем консенсусу і доступності даних, але на всіх наступних схемах я буду скорочувати його до DA-Layer. (Примітка: подібно до Layer1, який часто згадується в спільноті Ethereum).

У нашому першому варіанті кожен вузол згортання повинен відтворити всі транзакції в блокчейні, щоб перевірити найновіший стан. Ми щойно створили песимістичний рол-ап!

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

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

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

Секвенування - це процес агрегації та створення заголовків.

Агрегація - це процес об'єднання транзакцій в один пакет. Пакет транзакцій складається з однієї або більше транзакцій. (Примітка: Пакет - це частина даних у блоці Rollup, за винятком заголовка).

Виробництво заголовків - це процес створення заголовка рулону.

Rollup Header - це метадані про блок, які, як мінімум, включають зобов'язання щодо транзакцій в цьому блоці. (Примітка: Під зобов'язанням тут мається на увазі зобов'язання щодо коректності результатів обробки транзакцій).

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

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

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

Варіант 2: Песимістичне згортання з використанням спільного агрегатора

Давайте обговоримо песимістичну агрегацію за допомогою спільних агрегаторів. Цю ідею запропонував Еван Форбс у своєму дописі на форумі, присвяченому спільному використанню секвенсорів. Ключовим припущенням є те, що спільний секвенсор є єдиним формальним способом впорядкування транзакцій. Еван пояснює переваги спільних секвенсорів таким чином:

"Для розблокування веб-еквівалента UX спільні секвенсори [...] можуть надавати швидкі м'які зобов'язання (примітка: не дуже надійна гарантія). Ці м'які зобов'язання дають деяку довільну обіцянку остаточного впорядкування транзакцій (тобто вони обіцяють, що порядок транзакцій не зміниться), і можуть бути використані для створення передчасно оновлених версій стану (але на даний момент фіналізація ще не завершена).

Як тільки буде підтверджено, що блокчейн-дані розміщені на базовому рівні (s/b посилаючись на DAlayer), стан можна вважати остаточним".

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

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

У цьому варіанті користувачам Rollup потрібно запустити принаймні наступне в стані з мінімізованою довірою:

Легкий вузол DA-рівня + легкий вузол спільної агрегаторної мережі + повний вузол Rollup.

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

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

(Оскільки зміст, що міститься вище, відносно незрозумілий, ви можете прочитати діаграму ще раз)

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

Впорядкування - це процес розташування транзакцій у певній послідовності в блокчейні.

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

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

Якщо припустити, що L_ss - це життєздатність спільного агрегатора, а L_da - життєздатність DA-шару, то життєздатність цієї схеми дорівнює L = L_da && L_ss. Іншими словами, якщо будь-яка з систем має збій у роботі, збій у роботі має і згортка.

Для простоти, я буду використовувати liveness як булеву функцію. Якщо спільний агрегатор вийде з ладу, ми не зможемо продовжити згортку. Якщо DA-рівень зазнає невдачі, ми можемо продовжити роботу з м'якими зобов'язаннями спільного агрегатора. Проте, ми будемо покладатися на консенсус і доступність даних загального агрегатора, що буде гірше, ніж початковий DA-Layer.

Давайте продовжимо досліджувати стійкість до цензури вищезгаданого рішення Rollup:

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

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

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

Варіант 3: Песимістичне згортання з базовою та спільною агрегацією

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

Ми припускаємо, що остаточне впорядкування буде інтерпретуватися як всі транзакції, замовлені спільним агрегатором, а потім всі засновані транзакції після цього на блок DA-рівня. Ми називаємо це правилом вибору вилки rollups.

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

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

Очевидно, що остаточність замовлення транзакції, гарантована м'яким зобов'язанням третього типу Rollup-варіанту, є більш крихкою, ніж другий тип Rollup-варіанту, про який йшлося вище. У цьому випадку спільний агрегатор передає значення MEV вузлу DA-рівня. З цього приводу пропоную читачам переглянути лекцію про вигідну цензуру МЕВ.

В даний час з'явилися деякі проектні рішення, які зменшують здатність мережевих вузлів DA-рівня виконувати такі MEV-транзакції, наприклад, функція "період вікна реорганізації", яка затримує транзакції, що надсилаються безпосередньо користувачами Rollup-мережі на DA-рівень. Sovereign Labs детально описала це в своїй проектній пропозиції під назвою "Секвенування на основі м'яких підтверджень", де запропоновано концепцію "бажаного секвенатора".

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

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

Нарешті, давайте поговоримо про найменшу схему з мінімізацією довіри: легкий вузол DA-рівня + легкий вузол агрегатора + повний вузол згортання.

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

Варіант 4: Оптимістичне згортання з централізованим виробником заголовків

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

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

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

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

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

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

Світловий вузол DA-Layer + світловий вузол Rollup.

Варіант 5: На основі ZK-розгортання з децентралізованим ринком доведення

Ми обговорили песимістичний (заснований) і оптимістичний розворот, тепер настав час розглянути ZK-розворот. Нещодавно Тогрул зробив презентацію про розділення агрегатора (Sequencer) і виробника заголовків (Prover) (Sequencer-Prover Separation in Zero-Knowledge Rollups). У цій моделі простіше публікувати транзакції як дані Rollup, а не State Diff, тому я зосереджуся на першому варіанті. Варіант 5 - заснований на zk-розгортанні з децентралізованим ринком підтверджувачів.

На даний момент ви вже повинні бути знайомі з тим, що робить базоване згортання. Варіант 5 делегує роль агрегатора вузлам DA-шару, які виконують роботу включення і впорядкування. Я процитую документ Sovereign-Labs, який чудово пояснює життєвий цикл їхнього дизайну. Я трохи адаптую його, щоб він підходив до варіанту 5.

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

Нашим виробником заголовків у цьому дизайні є децентралізований ринок провізорів.

Вузли верифікації (повноцінні вузли, що працюють всередині ZKVM) виконують приблизно той самий процес, що й повноцінні вузли - сканують блок DA і обробляють усі пакети по порядку, створюючи верифікацію і відправляючи її далі по ланцюжку. (Доведення мають бути розміщені в ланцюжку, якщо ролловер хоче стимулювати перевіряючих - інакше неможливо визначити, який саме перевіряючий першим обробив певну партію). Після того, як доказ для даної партії було розміщено в ланцюжку, партія є суб'єктивно остаточною для всіх вузлів, включаючи легкі вузли.

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

Варіант 5 має таку саму цензурну стійкість, як і DA-шар. Децентралізований ринок провізорів не може цензурувати транзакції, оскільки DA-рівень визначає канонічний порядок. Ми децентралізували виробника заголовків лише для того, щоб покращити його життєдіяльність та створити ринок стимулів. Жвавість тут L = L_da && L_pm (ринок прислівників). Якщо стимули на ринку підтвердження не збігаються, або він не працює, легкі вузли не зможуть слідувати за ланцюжком, але повні вузли все ще можуть слідувати за ланцюжком, якщо захочуть, повертаючись до песимістичного сценарію розвитку подій. Найменша довіра мінімізується тут, як і в оптимістичному випадку з легким вузлом DA-шару + згорнутим легким вузлом.

Варіант 6: Гібридний згорток на основі централізованого оптимістичного виробника заголовків та децентралізованого верифікатора

Ми все ще дозволяємо вузлам DA-рівня виступати в ролі агрегаторів для Rollup і делегуємо їм обробку включення і сортування транзакцій.

Як видно з рисунка нижче, і ZK Rollup, і Optimistic Rollup використовують ті ж самі впорядковані пакети транзакцій на DA-рівні як джерело журналу Rollup. Ось чому ми можемо використовувати дві системи доказу одночасно: впорядковані пакети транзакцій на DA-рівні не залежать від самої системи доказу.

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

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

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

Коли легка нода отримає сертифікат ZK, що відповідає певному пакету транзакцій Rollup, пакет буде завершено.

Тепер у нас є швидке м'яке зобов'язання і швидке завершення.

Варіант 6 все ще користується такою ж цензурною стійкістю, як і DA-шар, на якому він базується. Для тривалості життя ми матимемо L = L_da && (L_op || L_pm ), що означає, що ми збільшили нашу гарантію тривалості життя. Якщо або централізований виробник заголовків, або ринок верифікаторів зазнають невдачі, ми можемо повернутися до іншої схеми.

Найменший набір з мінімізацією довіри - це світловий вузол DA-шару + світловий вузол, що згортається.

Підсумок:

1. Ми розділили секвенсор на дві логічні сутності: агрегатор і виробник заголовків

2. Ми розділили секвенсор на три логічні процеси: включення, впорядкування та виконання.

3. Песимістичні рулони та засновані рулони - це річ

4. Залежно від ваших потреб, ви можете підключати агрегатори та виробники заголовків.

5. Кожен варіант згортання в цій статті відповідає цьому шаблону дизайну:
   

Нарешті, у мене є кілька думок. Подумайте, будь ласка:

• Як класичні рулони вписуються в це? (мається на увазі Ethereum Rollup)
• У всіх варіантах ми змушували агрегатор робити тільки включення + замовлення і виконання хедерингового продюсера. Що робити, якщо агрегатор лише додає дані, а виробник заголовків замовляє та виконує їх? Подумайте про онлайн-аукціони. Чи можемо ми розділити всі три?
• Що таке спільний ринок виробників заголовків / виробників заголовків?
• Хто отримує MEV? І чи можемо ми його повернути?

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

1. Ця стаття передрукована з[Geek Web3], Forward the Original Title'Дослідник Celestia проаналізував 6 варіантів згортання: Sequencer = агрегатор + генератор заголовків', Всі авторські права належать оригінальному автору[NashQ, Celestia Researcher]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.