• Переслати оригінальну назву: Децентралізація згортання: Аналіз децентралізованого рішення для секвенування від Aztec

Вступ: З тих пір, як Rollup став відомим, децентралізація секвенсора завжди була в центрі уваги спільноти Ethereum/Celestia, і це також є важкою горою, яку потрібно подолати в роботі над Layer2. У зв'язку з цим, різні плани Rollup пропонують ідеї щодо децентралізації вузлів, надаючи надзвичайно широкий простір для фантазії на цю тему.

Автор цієї статті бере за приклад відомий проект ZKRollup Aztec, і використовує дві пропозиції B52 та Fernet, нещодавно запропоновані Aztec Labs, як відправну точку, щоб проаналізувати для читачів, як ZKR реалізує децентралізацію вузлів секвенсора.

Пропозиція B52: Схема бездозвільного секвенсора

Пропозиція B52 спрямована на досягнення наступних цілей (в ідеалі):

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

2. Децентралізована мережа верифікаторів, з низькими вимогами до апаратного забезпечення вузлів верифікаторів.

3. Загалом, ролик має відмінну стійкість до цензури.

4. Значення MEV, згенероване на L2, отримується вузлами L2.

5. Коли блоки L2 подаються на шар DA, можна отримати відносно ефективну скінченність. Невідворотна фінальність вимагає завершення подачі Доказу дійсності.

6. L2 Токени можуть мати гідну токеномічну модель.

7. Як блок L2, так і дані транзакції поширюються в p2p-мережі L2.

8. L2 успадковує безпеку L1.

(Пропозиція B52 передбачає структуру Rollup, Пропонент по суті є Секвенсором)

Цей план розділяє весь процес виробництва блоків L2 на три часові етапи:

Вікно пропозиції блоку (BPW) Вікно акцепту блоку (BAW) Державні аванси

Зокрема, етап BPW (Block Proposal) - це процес, коли кілька секвенсорів пропонують різні блоки і змагаються між собою, а верифікатор обирає блок-кандидат для голосування. BAW (Block Acceptance) - це процес, під час якого верифікатор створює доказ валідності блоку і відправляє його. Вікно блокової пропозиції (фаза блокової пропозиції): BPW можна поділити на три етапи - Пропозиція блоку, Голосування блоку, Агрегація.

(Діаграма процесу у вікні Block Proposal Window)

Етап Block Proposal (BP): будь-хто на етапі може збирати транзакції і транслювати власний контент BP. Вміст БП складатиметься з трьох частин: хеш замовлення txs, відсоток винагороди за перевірку, кількість токенів, що спалюються.

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

Етап блокового голосування:

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

Vote={BlockHash, Index of Proof Tree}

BlockHash - це хеш пропозиції, за яку хоче проголосувати верифікатор, а Index of Proof Tree - це значення індексу листа дерева доказів, в побудові якого хоче взяти участь верифікатор (буде пояснено пізніше).

Агрегація: Пропонент збирає голоси від провайдерів на БП в p2p-мережі L2, агрегує їх, поміщає в БП і надсилає в L1 (кожен БП, як правило, містить лише записи голосувань, що стосуються його самого).

Тут необхідно підкреслити передумову для того, щоб БП був відібраний і включений до реєстру Rollp:

Має найвищий бал:

SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2`

NUM_PROVERS (x) - це кількість голосів Prover, які отримав цей БП, а BURN_BID - це кількість L2-токенів, запропонованих для спалення цим БП. Оскільки чим вища BURN_BID, тим менше винагороди отримає учасник, який запропонував БП, тому це значення має бути встановлене належним чином.

У той же час, цей БП повинен бути поданий до L1 до закінчення Вікна подання Блоків, а відповідне підтвердження дійсності (Proof of validity) повинно бути завантажене до L1 до закінчення Вікна прийняття Блоку (Block Acceptance Window).

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

Схема B52 вимагає від пропонента (секвенсера) лише вказати кількість токенів для запису у власному БП (подібно до методу EIP1559) без необхідності заздалегідь робити ставки, що може зробити мережу більш бездозвільною (без дозволу на допуск), а також сприяє дефляції власних токенів L2.

Крім того, BP не містить повних даних про транзакцію, а лише хеш послідовності транзакцій, що схоже на схему PBS в Ethereum, щоб уникнути підглядання та витіснення MEV іншими пропонентами.

Детальне пояснення Вікна прийняття блоків:

(Схематичне зображення вікна Прийняття блоку, записаного як Proof Acceptance на малюнку)

Після того, як вікно Block Proposal Window закриється, Перевірювач повинен розкрити повні дані про транзакцію, що відповідають його БП. Якщо БП, за який проголосував Перевіряючий, обрано (з найвищою оцінкою, яку можна отримати через контракт L1), він повинен побудувати піддерево доказів, що відповідає індексу дерева доказів, заданому при голосуванні.

Припустимо, що ацтекський блок містить 2^13=16384 транзакцій, і є 2048 доведень, тоді кожне доведення будує піддерево, що складається з 2^3=8 транзакцій. Потім перевірювач транслює побудоване піддерево доказу в L2 p2p мережу. Отримавши його, автор об'єднає всі дерева піддоказів у блоковий доказ.

Далі Propsoer передасть агрегований доказ контракту L1 Rollup, який перевірить правильність цього доказу і відповідні результати переходу станів. Слід зазначити, що якщо Prover навмисно не надасть докази, він не тільки не отримає дивіденди від винагороди за блок, обіцяні Proposer'ом, але й буде знищений, оскільки для того, щоб стати Prover'ом, необхідно заздалегідь розмістити токени в стейк. Тому, на відміну від пропонуючого (секвенсора), перевірювач не є бездозвільним.

Детальне пояснення державних авансів:

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

Вище наведено схему B52 ацтеків. Однак автор цієї статті вважає, що пропозиція B52 має деякі потенційні проблеми:

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

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

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

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

Проблема 2: Припустимо, що блок з найбільшою кількістю балів є незаконним (цей момент не пояснюється в плані B52). БП містить лише хеш послідовності транзакцій, тому зловмисник може навмисно створювати проблемні транзакції, наприклад, транзакції з подвійним витрачанням коштів. Наразі фактично необхідно додати до контракту L1 функцію, яка дозволяє будь-кому подати нелегальний доказ. Цей незаконний доказ використовується для того, щоб довести, що БП з найбільшою кількістю балів є незаконним блоком.

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

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

Це фактично відповідає практиці консенсусного механізму ETH POW. Щоб уникнути надмірної концентрації обчислювальних потужностей, необхідно виділяти частину винагороди за блок авторам блоків, які не були прийняті (майнерам), захищати інтереси невеликих майнінгових пулів/окремих майнерів і не допускати монополізації потужності майнінгу великими майнінговими пулами. Тому прийняття добре працюючого механізму блокування дядька Ethereum також є дуже розумним вибором.

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

Тому з часом вона стане більш централізованою мережею, схожою на Mev-Boost Builder, оскільки оферентом, який в кінцевому підсумку може випустити блок, часто є блокчейн-будівельник, який найкраще вміє захоплювати MEV.

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

Liveness: Загальна мережа Liveness є хорошою, оскільки L2 має власну p2p-мережу для трансляції транзакцій і голосування/BP, а Sequencer і Prover є відносно децентралізованими. Але нам потрібно вирішити дві проблеми, згадані вище, одна з яких полягає в тому, що блок з найвищою оцінкою повинен бути легальним, а друга - в тому, що нам потрібно дочекатися повного підтвердження блоку, яке буде надіслано в L1, перш ніж входити в новий штат. Тому потрібен більш ефективний механізм стимулювання, щоб уникнути виходу з ладу (зупинки) всієї мережі Rollup через відсутність певного доказу передачі даних.

Стійкість до цензури: Якщо ми зможемо зробити так, щоб будь-хто міг публікувати блок-пропозиції на ВР, і щоб не тільки пропонент міг подавати докази блоків, тоді мережа матиме хорошу стійкість до цензури.

Фінальність: Фінальність L2 тісно пов'язана з життєздатністю мережі, оскільки для остаточної перевірки фінальності все ще потрібно дочекатися подання Block Proof, але фактично ви також можете довіряти вмісту блоку, що відповідає найвищому балу BP (якщо він не містить зловмисних транзакцій).

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

Успадкувати безпеку L1: Як L2, який оновлює стан, надсилаючи докази валідності, він може успадкувати безпеку L1.

Пропозиція Fernet: Впровадження VDF для відбору пропонентів

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

По-перше, як приєднатися до Комітету? По суті, для цього потрібно стейкнути 16 ETH на L1, а потім, після завершення процесу стейкінгу, дочекатися 4 блоків L1, перш ніж приєднатися до комітету секвенсорів. Щоб вийти з Секвенсорного комітету, потрібно викликати функцію Unstake в контракті L1, після чого протягом 3 днів ви отримаєте залишок стейка, що залишився.

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

Розрахунок VDF для Sequencer відбувається наступним чином:

Score = VDF( privatekey , public input )

public inputs = { current block number , randao }

randao - випадкове число, яке використовується для того, щоб запобігти передчасному розрахунку VDF Score для всіх майбутніх висот блоків у секвенсорах

Весь процес Fernet в основному поділяється на три етапи:

1. Фаза пропозиції 2. Фаза доказу 3. Фіналізація

Фаза пропозиції: PROPOSAL_PHASE_L1_BLOCKS = 2 блоки Ethereum (ця фаза триватиме 2 блоки L1)

На початку цієї фази кожен секвенсор обчислює власну оцінку VDF для поточної висоти блоку. Якщо Секвенсор вважає, що його оцінка VDF, ймовірно, виграє право на виробництво цього блоку (за умови, що оцінка задовольняє нормальному розподілу), він подає Пропозицію до контракту L1 Rollup. Пропозиція включає: хеш послідовності транзакцій, що вказує на попередній блок L2.

непідтверджений блок: Блок, який подав лише Пропозицію на вміст блоку контракту Rollup. Потім секвенсор повинен відправити вміст блоку, що відповідає недоведеному блоку, і доказ VDF в p2p-мережу L2.

Фаза тестування: PROVING_PHASE_L1_BLOCKS= 50 L1 блоків (Ця фаза триватиме 50 L1 блоків, приблизно 10 хвилин)

Перевірювач отримує всі транзакції, що відповідають вмісту блоку, з мережі L2 p2p, і будує доказ для блоку з вищою оцінкою VDF. Для побудови доказу також використовується метод паралельної роботи декількох провайдерів (подібно до схеми B52).

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

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

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

Механізм генерації блоків: Варто зазначити, що Fernet використовує механізм генерації блоків. Коли фаза пропозиції блоку N закінчується, починається фаза пропозиції блоку N+1 (подібно до того, як це роблять Aptos та інші публічні ланцюжки). Однак, для блоку N+1 він повинен дочекатися завершення роботи блоку N, перш ніж він зможе відправити транзакцію фінального блоку L1 і отримати валідацію, щоб стати фінальним блоком.

Потенційні вектори атаки: Якщо секвенсор з найвищим показником VDF навмисно не транслює вміст блоку в L2 p2p, це може призвести до реорганізації блоку (reorg).

Розрахунок кількості блоків L2 для реорганізації: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 блоків

Рішення: Запровадити механізм блоків-дядьків, щоб уникнути наявності лише одного повного блоку-кандидата для кожного слоту L2 (часового інтервалу генерації блоків).

Значення децентралізації у Fernet: Секвенсори приєднуються до Комітету секвенсорів, зробивши ставку в 16 ETH, а поріг вступу не є високим (але й не низьким). Провайдерам не потрібно ніякого стейкінгу, але якщо провайдери не генерують доказ, то штраф не накладається. Це, по суті, протилежність схемі B52.

Життєздатність: Життєздатність мережі в цілому може бути гарантована, оскільки механізм VDF + дядько блоку може гарантувати, що в кожному раунді буде більше одного виробника блоків.

MEV: Розгляд MEV є особливо унікальним. У цій схемі планується запровадити PBS, тому після того, як секвенсор обчислить високу оцінку VDF Score, він може безпосередньо звернутися до Конструктора блоків, щоб створити більш цінний блок.

Стійкість до цензури: Fernet також прийме механізм PBS, який відповідає Ethereum, тому, по суті, проблема стійкості до цензури в Fernet еквівалентна проблемі стійкості до цензури PBS в Ethereum.

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

1. Ця стаття передрукована з[Geek Web3], Переслати оригінальну назву 'ollup Decentralization: Analysis of Aztec's Decentralized Sequencer Solution', всі авторські права належать оригінальному автору[xhhhh，EthStorage]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.