Дослідник Celestia: Інтерпретація 4 нових схем зведення

Автор оригіналу: NashQ, Celestia

Компіляція: посилання, "Geek web3"

Вступ. Ця стаття складається з розрізнених виступів дослідника Celestia NashQ щодо аналізу моделі Rollup, включаючи 4 нові варіанти Rollup. Раніше, у статті «Аналіз зведення з точки зору Celestia: опір цензурі та активність 6 варіацій», він перерахував 6 різних моделей зведення, і ця стаття є його нещодавно абстрагованими 4 категоріями, заснованими на цій моделі зведення.

Раніше NashQ поділив Sequencer на два модулі: агрегатор + Header Producer. Починаючи з життєвого циклу інструкцій транзакцій, він пояснював принцип роботи суверенного зведення Celestia, обговорював антицензуру та активність різних варіантів зведення, а також взаємодію з користувачем. Мінімальна конфігурація за умови мінімізації довіри (тобто, щоб досягти Trustless, які типи вузлів зведених користувачів повинні запускати принаймні).

Варіант 7: зведення на основі + кілька виробників заголовків + "найвищий MEV протоколу"

У цьому варіанті Rollup користувачі мережі Rollup безпосередньо публікують дані транзакцій у блоках рівня DA, а потім Header Producer відповідає за сортування транзакцій, а MEV витягується ним. Очевидно, що процес агрегування/включення транзакцій у варіанті зведення 7 такий самий, як і в раніше введеному зведеному пакеті, за який відповідає рівень DA (користувачі безпосередньо надсилають транзакції на рівень DA), але порядок транзакцій відрізняється від упорядкування на основі. Rollup і вузли рівня DA не несуть відповідальності За сортування відповідає HP (Header Producer).

Далі припускається, що є три HP, які конкурують між собою та дотримуються протоколу розподілу MEV під назвою «найвищий протокол MEV». Цей протокол був запропонований Skip Protocol екосистеми Cosmos. На відміну від схеми Ethereum PBS, Block Builder повинен платити додаткові «чайові» Validator мережі блокчейну, і блок, створений Builder з найбільшою кількістю чайових, буде прийнято валідаторами.. У той же час SKIP Protocol запропонував концепцію «суверенного MEV», маючи намір дозволити всім валідаторам і спільнотам у публічній ланцюжковій мережі мати автономію для розподілу MEV, а також вирішити проблему, що конструктори в Ethereum PBS стають все більш і більш централізований через ефект маховика (але це не суть цієї статті).

У варіанті Rollup, представленому в цій статті, різні виробники заголовків повинні декларувати суму чайових у заголовку Batch Header, створеному ними самими, а заголовок Batch Header, виданий HP, який сплачує найбільше чайових, автоматично приймається вузлами Rollup (через реєстр записаний у коді вузла. Алгоритм вибору форка виконується автоматично).

Крім того, заголовок пакета, виданий HP, повинен відповідати повному пакету транзакцій на рівні DA.

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

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

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

**Діяльність:**L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

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

Варіант 8: ZK Rollup спільного агрегатора + децентралізованого перевірника

Варіант 8 використовує спільний агрегатор Shared Aggregator (SA) для включення транзакцій + сортування. SA публікує послідовність транзакцій Batch на рівні DA. Після того, як послідовність транзакцій надсилається на рівень DA, порядок транзакцій теоретично не зміниться.

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

Слід зазначити, що заголовок, виданий спільним агрегатором SA, не збігається з заголовком пакета, виданим HP. Заголовок SA містить криптографічні докази, які гарантують, що пакет, зчитаний вузлом зведення з рівня DA, дійсно створений SA, а не підроблений іншими.

Prover зчитує пакетний пакет транзакцій із рівня DA (його також можна безпосередньо синхронізувати зі спільним агрегатором), генерує ZK Proof+Batch Header і публікує його на рівні DA. Очевидно, що Провер грав роль HP.

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

• **Стійкість до цензури: **У варіанті 8 рівень DA не може проводити атаки цензури на певні конкретні транзакції, але може проводити атаки перегляду лише на всю партію транзакцій, надісланих спільним агрегатором. У той же час спільні агрегатори можуть відмовитися від пакетування певних транзакцій користувачів.
• **Діяльність: **L = L_da && L_sa && L_pm. У цьому варіанті, якщо будь-яка частина має збій живучості, Rollup матиме збій живучості. Якщо перевірка виходить з ладу, світлові вузли не зможуть ефективно синхронізувати хід зведеної книги. Однак, оскільки повний вузол синхронізує всі пакети послідовності транзакцій, він може не відставати від прогресу реєстру. Наразі це не вплине на всі вузли, а всі легкі вузли вийде з ладу, що еквівалентно ситуації зведення на основі використання спільного агрегатора, представленого раніше.
• **Мінімальна конфігурація для мінімізації довіри: **світловий вузол рівня DA + спільний мережевий світловий вузол агрегатора + світловий вузол зведення

Варіант 9: Спільний агрегатор + децентралізований Prover + ZK-зведення з кількома DA

Варіант 9 фактично базується на вищезгаданому варіанті 8, але він має більше одного рівня DA, що може ефективно покращити активність Rollup. У Варіанті 9 спільний агрегатор SA може публікувати послідовність транзакцій Batch на будь-якому рівні DA, і він може вибирати різні рівні DA для публікації даних відповідно до власних потреб, щоб він міг динамічно оптимізувати відповідні параметри Rollup, наприклад: вартість даних, безпека, динамічність, затримка транзакцій і остаточність.

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

Тут ми вибираємо той самий децентралізований ринок Prover, що й варіант 8, де Prover діє як виробник заголовків і випускає Batch Header і ZKProof. На цьому етапі Prover повинен конкурувати через механізм аукціону підказок, згаданий у варіанті 7 (запропонований протоколом SKIP).

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

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

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

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

Мінімальна конфігурація для мінімізації довіри: світлові вузли різних рівнів DA + спільні світлові вузли мережі агрегатора + світлові вузли зведення.

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

Варіант 10: Два ZK-Rollups+децентралізований прувер, кожен із легким вузлом у ланцюжку (може бути з’єднаний мостом)

Варіант 10 є розширенням варіанту 5 для створення 2 ZK-зведених пакетів, які можуть поєднувати один одного. Порівняно з Варіантом 5 (Based Rollup+ZKP+Decentralized Prover), Варіант 10 має додаткову роль ретранслятора, яка загортає пакетний заголовок+ZK-Proof у транзакцію. Поки ця транзакція надсилається світловому вузлу Rollup1, що працює на Rollup2, це може підтвердити, що певна висота Batch дійсна. Звичайно, для Rollup2 також потрібні легкі вузли, на яких працює рівень DA.

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

Коли Relayer надсилає міжланцюгову транзакцію, вона буде оброблена агрегатором 2 Rollup2 і HP2. Ми додаємо обидва до графіка, щоб зрозуміти, як вузли Rollup2 обробляють транзакції між Rollups.

Ретранслятор Rollup2 отримає пакетний заголовок і ZKP Rollup 2 і надішле їх назад до Rollup1. Rollup 1 також має світловий вузол Rollup 2 і світловий вузол рівня DA.

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

У цьому випадку Relayer можна забанити безпосередньо. Оскільки пакетний заголовок і ZK Proof були опубліковані HP на тому самому рівні DA, такі дані, як заголовок і ZKP іншого зведеного пакету, можна зчитувати безпосередньо на рівні DA, і їх більше не потрібно передавати спільному агрегатору через Ретранслятор.

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

Наразі **мінімальна конфігурація мінімізації довіри: **світлий вузол рівня DA + світловий вузол зведення.