Автор: NashQ, дослідник Celestia; компілятор: Faust, Geek Web3

Примітка перекладача: щоб полегшити розуміння та аналіз моделі Rollup, дослідник Celestia NashQ розділив секвенсор Rollup (Sequencer) на дві логічні сутності — агрегатор і генератор заголовків. У той же час він розділив процес замовлення транзакції на три логічні кроки: включення, замовлення та виконання.

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

Хоча ця стаття аналізує Rollup з точки зору Celestia, яка відрізняється від того, як спільнота Ethereum аналізує модель Rollup, враховуючи багато взаємозв’язків між Ethereum Rollup і Celestia sovereign Rollup, а також зростаючий вплив останнього, це важливо для For Ентузіастам Ethereum також варто прочитати цю статтю.

Що таке Rollup?

Rollup — це блокчейн, який публікує свої «дані транзакцій» в інший блокчейн і успадковує його консенсус і доступність даних.

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

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

Варіант 1: Песимістичний зведений / Базований зведений

Найпростіший спосіб створити Rollup — це дозволити користувачам публікувати транзакції в іншому блокчейні, який ми називатимемо рівнем консенсусу та доступності даних (DA-Layer), а я буду називати його просто DA-layer у наступному (Примітка перекладача: Він схожий на рівень 1, про який часто говорять у спільноті Ethereum).

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

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

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

Для зручності обговорення ми можемо розділити секвенсор на дві логічні сутності: Aggregator Aggregator і Header Generator. Щоб створити заголовок зведення, ви повинні спочатку виконати транзакцію, завершити перехід стану, а потім обчислити відповідний заголовок. Але для агрегатора йому не потрібно завершувати перехід стану, щоб продовжити крок агрегації.

Послідовність сортування — це процес «агрегації + створення заголовка зведення».

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

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

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

Таким чином, pesimistic Rollup — це варіант Rollup, який делегує крок агрегації на рівень DA, який не має секвенсора Sequencer. Іноді цей тип зведення називають «зведеним».

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

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

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

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

Після того, як дані блоку зведення підтверджені та передані на базовий рівень базового рівня (тут це має стосуватися рівня DA), оновлення статусу книги зведення завершується. "

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

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

У цьому варіанті користувачам Rollup потрібно принаймні запустити легкі вузли рівня DA + легкі вузли спільної мережі агрегатора + повні вузли Rollup у мінімізованому стані довіри.

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

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

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

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

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

Для простоти я розглядатиму живучість як логічне значення. Якщо спільний агрегатор виходить з ладу, Rollup не може продовжувати роботу. Якщо мережа рівня DA виходить з ладу, спільний агрегатор може продовжувати надавати Soft Commitment для блоків Rollup. Але наразі атрибути Rollup повністю залежатимуть від спільної мережі агрегатора, а атрибути останньої часто набагато поступаються оригінальному рівню DA.

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

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

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

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

Варіант 3: песимістичний зведення на основі базового зведення та спільного агрегатора

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

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

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

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

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

Наразі з’явилися деякі схеми проектування, щоб зменшити здатність мережевих вузлів рівня DA виконувати такі транзакції MEV, як-от функція «період вікна реорганізації», яка затримує виконання транзакцій, надісланих безпосередньо на рівень DA користувачами мережі Rollup. . Sovereign Labs детально описує це у своїй проектній пропозиції під назвою Based Sequencing with Soft Confirmations, яка вводить концепцію «бажаного секвенсора».

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

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

Нарешті, давайте поговоримо про мінімальну конфігурацію користувачів Rollup під час мінімізації довіри:

Принаймні запустіть вузол світла шару DA + вузол світла спільного агрегатора + повний вузол зведення.

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

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

Давайте обговоримо варіант під назвою Based Optimistic Rollup і централізований генератор заголовків. Це рішення використовує рівень DA для агрегування транзакцій зведення, але вводить централізований генератор заголовків для генерації заголовків зведення, щоб увімкнути легкі вузли зведення.

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

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

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

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

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

Світловий вузол шару DA + світловий вузол Rollup.

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

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

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

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

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

Робочий процес перевірочного вузла Prover (повного вузла, який працює в ZKVM) подібний до звичайного повного вузла Rollup — сканування блокчейну рівня DA та обробка всіх пакетів транзакцій Rollup для створення відповідного Proof з нульовим знанням і публікації. це на ланцюжку рівня DA. (Якщо система Rollup хоче мотивувати підтвердження, останній повинен надіслати згенероване підтвердження ZK до ланцюжка рівня DA, інакше буде неможливо визначити, який довідник надав підтвердження ZK першим). Після того, як ZK-доказ, що відповідає певній партії транзакцій, випущено в ланцюжок, пакет транзакцій завершується в очах усіх вузлів Rolup (включаючи легкі вузли).

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

Діяльність тут L = L_da && L_pm (діяльність Провера). Якщо стимули Prover Market несумісні або є активний збій, вузол Rollup Light не зможе синхронізувати прогрес блокчейну, але повний вузол Rollup може. Для повного вузла це лише резервний варіант. до Базового зведення/Песимістичного зведення. Мінімальна конфігурація для мінімізації довіри тут така ж, як і у випадку оптимістичного зведення, а саме

Світловий вузол шару DA + світловий вузол Rollup.

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

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

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

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

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

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

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

Тепер ми маємо швидке м’яке зобов’язання та швидке завершення.

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

У цьому варіанті мінімальна конфігурація для мінімізації довіри користувачів:

Один світловий вузол рівня DA + один світловий вузол Rollup.

Резюме:

1. Ми розділили ключову роль Rollup - Sequencer на два логічні компоненти:

Агрегатори та генератори заголовків.

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

3. Песимістичний і базовий зведення — це одне.

4. Відповідно до ваших потреб ви можете вибрати різні рішення агрегатора та генератора заголовків.

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

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

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