Вступ: відколи Rollup став популярним, децентралізація Sequencer завжди була в центрі уваги спільноти Ethereum/Celestia, і це також непереборна гора в дослідженнях і розробці Layer2. У цьому відношенні різні схеми зведення пропонують ідеї щодо децентралізації вузлів, надаючи надзвичайно широкий простір для уяви для цієї теми.
Автор цієї статті бере за приклад відомий проект ZKRollup Aztec і використовує дві пропозиції під назвою B52 і Fernet, нещодавно запропоновані Aztec Labs, як відправну точку для аналізу того, як ZKR реалізує децентралізацію вузлів секвенсора для читачів.
Пропозиція B52: Схема секвенсора без дозволу
Пропозиція B52 спрямована на досягнення наступного (в ідеалі):
Децентралізована мережа секвенсора, вузли L2 самі обирають кожного раунду пропонентів
Децентралізована мережа прувера, низькі вимоги до обладнання для вузлів прувера
Rollup має хорошу стійкість до цензури в цілому.
Значення MEV, створене L2, отримується вузлами L2
Коли блок L2 надсилається на рівень DA, можна отримати більш ефективну остаточність, а незворотна остаточність повинна чекати на надсилання ValidityProof (підтвердження дійсності).
Токен L2 може мати хорошу економічну модель
І блоки L2, і дані транзакцій поширюються в мережі L2 p2p
L2 успадковує безпеку L1
Ця схема поділяє весь процес виробництва блоку L2 на три часові етапи:
Блокувати вікно пропозицій (BPW)
Вікно BlockAcceptance (BAW)
Державні аванси
Серед них стадія BPW (пропозиція блоку) — це процес, у якому кілька секвенсорів Seuqnecer пропонують різні блоки та змагаються, а Prover вибирає блок-кандидат, щоб дати голос.
BAW (Block Acceptance) — це процес, у якому Prover створює підтвердження дійсності для блоку та надсилає його.
BPW можна розділити на три етапи: Блокова пропозиція, Блокове голосування, Агрегація.
Будь-хто на етапі Block Proposal (BP) може збирати транзакції та транслювати власний вміст BP. Контент BP складатиметься з трьох частин: хеш замовлення txs, відсоток винагороди перевірника, кількість спаленого токена
хеш замовлення txs: Proposer вибирає та сортує найцінніший пакет транзакцій із пулу транзакцій L2 (мемпулу), а потім поміщає хеш-значення цього пакета транзакцій у створений ним блок.
відсоток винагороди за перевірку: відсоток винагороди за блок, який розподіляється між секвенсором і перевірячем
сума маркера запису: кількість оригінальних маркерів L2, запропонованих Пропонентом для знищення, а потім він надсилає запропонований BP до мережі L2 p2p
Етап блокового голосування:
Після того, як Провер отримає BP, запропонований різними Пропозерами в мережі p2p, він проголосує за BP, який може принести йому найбільшу винагороду. Однак склад голосів дуже особливий:
Голосування={BlockHash, індекс дерева доказів}
BlockHash — це хеш пропозиції, за яку голосуватиме перевіряючий, а індекс дерева доказів — це значення листового індексу дерева доказів, у побудові якого братиме участь перевіряючий (пояснено пізніше).
Агрегація агрегації: Пропонент збирає голоси перевіряючих для BP у p2p-мережі L2, агрегує їх і поміщає в BP, а потім надсилає до L1 (кожен BP зазвичай містить лише записи голосування, пов’язані з ним).
Тут необхідно підкреслити передумови для того, щоб BP було обрано та включено до журналу Rollp:
Мати найвищий бал:
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) — це кількість голосів, отриманих BP, а BURN_BID — кількість токенів L2, які пропонує знищити BP. Оскільки що вищий BURN_BID, то меншу винагороду врешті-решт отримає пропонент BP, тому це значення слід правильно встановити.
У той же час BP потрібно надіслати в L1 до завершення вікна блокових пропозицій, а відповідне підтвердження дійсності має бути завантажено в L1 до завершення вікна прийняття блоків.
Примітка. Під час розрахунку балів BP кількість голосів становить найбільшу частку, а потім кількість спалених жетонів. У той же час схема B52 дозволяє декільком пропонентам (фактично секвенсерам) конкурувати за ефективну квоту BP
Схема B52 вимагає лише від Пропонента (секвенсора) вказати кількість маркерів запису у своєму власному BP (подібно до методу EIP1559) без маркерів ставок заздалегідь, що може зробити мережу більш бездозволною (без дозволу доступу), і є також корисно для L2 Native Token створює дефляцію.
Крім того, BP містить не повні дані транзакцій, а лише хеш послідовності транзакцій.Причина подібна до схеми Ethereum PBS, яка спрямована на те, щоб запобігти шпигуванню за MEV іншими пропозерами.
Докладне пояснення вікна прийняття блоку (стадія прийняття блоку):
Після завершення вікна пропозиції блоку Prover повинен відкрити повні дані транзакції, що відповідають його BP. Якщо вибрано BP, за який проголосував перевіряючий (найвищий бал можна запитати через контракт L1), їм потрібно побудувати допоміжне дерево доказів, яке відповідає дереву індексу доказів, наданому під час голосування.
Якщо припустити, що блок Aztec містить 2^13=16384 транзакцій і є 2048 пристроїв перевірки, то кожен перевірник створює допоміжне дерево доказів, що складається з 2^3=8 транзакцій. Потім перевіряльник транслює створене ним піддерево до In L2 p2p мережі. Після того як пропонент отримає його, він об’єднає всі піддерева доказів у блок доказів.
Потім Propsoer надсилає зведене підтвердження до контракту L1 Rollup, і контракт перевірить правильність підтвердження та відповідних результатів переходу стану. Тут слід зазначити, що якщо Проверяючий навмисно не надає докази, він не тільки не зможе отримати дивіденд від винагороди за блок, обіцяний Пропонентом, але його також буде скорочено, оскільки, щоб стати Проверяючим, йому потрібно токен застави заздалегідь. Таким чином, на відміну від Proposer (Sequencer), Prover не має дозволу.
State Advances (State advancement stage) детальне пояснення:
Після завершення вікна прийняття блоків контракт зведення вибере блок із найвищим балом, який буде включено до журналу зведення, і надішле винагороду за блок Пропоненту та Довірителю відповідно відповідно до пропорції, оголошеної Пропонентом (Секвенсором) у заздалегідь.
**Вище наведено рішення Aztec B52. Однак автор цієї статті вважає, що є деякі потенційні проблеми з пропозицією B52: **
Запитання 1: Якщо доказ дійсності блоку з найвищим балом є неповним. Рішення, надане в пропозиції, полягає в тому, що якщо Запропонент надає лише 50% доказів, то він може отримати лише 50% винагороди за блок, щоб гарантувати, що Запропонатор не має мотивації навмисно не подавати повний доказ. У той же час Prover також може надати підтвердження безпосередньо до контракту.
Згідно з описом пропозиції, прийнятно прийняти блок без підтвердження дійсності завершених транзакцій. Насправді це нерозумно: тому що: zkrollup лише оголошує, що новий стан, який відповідає цьому блоку, є дійсним, коли надається доказ дійсності.
Якщо в сукупному доказі, поданому пропонентом до L1, відсутній доказ певної транзакції, очевидно, що докази переходу стану всіх транзакцій, які відбуваються після цієї транзакції, є недійсними (оскільки транзакції виконуються послідовно та мають залежності від стану), ми Також неможливо підтвердити, що новий стан, який відповідає цьому блоку, є дійсним.
Таким чином, наразі розумним способом має бути увійти у вікно прийняття блоку, яке нескінченно чекає, доки не будуть подані всі докази транзакцій.
Запитання 2: **Якщо блок з найвищим балом є незаконним блоком (це не пояснюється в схемі B52). **BP містить лише хеш послідовності транзакцій, тому зловмисник може фактично навмисно створювати проблемні транзакції, такі як транзакції подвійного витрачання. Тож на даний момент фактично необхідно додати функцію в контракт L1, щоб будь-хто міг подати незаконне підтвердження.Це незаконне підтвердження використовується для підтвердження того, що BP з найвищим балом є незаконним блоком.
І цей вид звіту має бути винагороджений, ми можемо винагородити токен запису, надісланий пропонентом контракту вузлу звіту, який надав незаконне підтвердження.
**Цікава думка:**Про блоки дядька та надлишкову роботу перевірки: схема B52 фактично використовуватиме інших BP (які подали повні докази), які з’являться в цьому раунді як дядьки після того, як з’явиться BP з найвищим балом у кожному раунді. призначити певну винагороду за блокування дядька.
Це фактично відповідає підходу консенсусного механізму ETH POW. Щоб уникнути надмірної концентрації обчислювальної потужності, необхідно виділити частину винагороди за блоки неприйнятним пропонентам блоків (майнерам), щоб захистити інтереси невеликих майнінг-пулів/окремих майнерів. і уникайте. Обчислювальна потужність монополізована великими майнінг-пулами. Тому також дуже розумним вибором буде прийняти механізм блокування дядька, який Ethereum працює добре.
Значення пропозиції B52 з точки зору децентралізації Rollup: Пропонент децентралізований і не потребує застави, а поріг входу низький; але тому, що вам потрібно самостійно створити найцінніші блоки, і вам потрібно збирати голоси від інших Пропонентів і об’єднати всі Докази. Насправді, поріг апаратного забезпечення Пропонента не такий низький, як зазначено в пропозиції (наприклад, пропускна здатність може бути не дуже низькою).
Тому згодом це стане відносно централізованою мережею, подібною до Mev-Boost Builder, тому що пропонент, який нарешті може генерувати блоки, часто є Block Builder, який найкраще вловлює MEV.
У той же час перевіряльник у схемі B52 має заставити активи, але оскільки потрібно створити лише доказ піддерева, у порівнянні з тими схемами, які потребують повністю створити доказ блоку, **ступінь децентралізації перевірятиме краще (вимоги до обладнання можна знизити). **
Активна активність: Загальна активність мережі хороша, тому що L2 має власну p2p-мережу для трансляції транзакцій і голосувань/BP, а Sequencer і Prover відносно децентралізовані. Але нам потрібно вирішити дві проблеми, які ми згадували вище: одна полягає в тому, що блок з найвищим балом має бути легальним блоком, а друга полягає в тому, що йому потрібно дочекатися, поки повне підтвердження блоку буде надіслано в L1, перш ніж вводити новий стан. Тому потрібен більш ефективний механізм стимулювання, щоб запобігти несправності (простою) усієї мережі Rollup через відсутність певної частини доказу передачі.
**Стійкість до цензури: **Якщо ми можемо гарантувати, що будь-хто може опублікувати пропозицію блокування BP, і переконатися, що не лише Пропонент може надати доказ блокування, тоді мережа матиме гарний опір цензурі.
**Завершеність: **Завершеність L2 тісно пов’язана з активністю мережі, тому що остаточна підтверджена остаточність все ще повинна чекати подання Block Proof, але насправді ви також можете довіряти вмісту блоку, що відповідає BP з найвищим балом (якщо він не містить зловмисних транзакцій).
Цей блок буде показано на початку вікна прийняття блоку, а це означає, що вам, як користувачу, потрібно лише дочекатися вікна пропозиції блоку, і блок, у якому подана вами транзакція може бути прийнята.
Успадкувати безпеку L1: Як L2, який оновлює свій статус, надаючи підтвердження дійсності, він може успадкувати безпеку L1.
Пропозиція Fernet: введіть VDF, щоб вибрати законного Пропонента
Представлення схеми Fernet: Через VDF у кожному раунді циклу генерації блоку встановлюється приблизний бал для різних вузлів у Комітеті (тобто набору вузлів секвенсора), а блок, запропонований секвенсором, з найвищий підсумковий бал стане дійсним.
**По-перше, як приєднатися до комітету? Насправді вам потрібно пообіцяти 16 ETH в L1, **і зачекати 4 блоки L1 після завершення операції застави, а потім приєднатися до Комітету секвенсорів. Що стосується виходу з Комітету секвенсорів, вам потрібно викликати функцію Unstake у контракті L1, і тоді ви зможете повернути решту суми своєї застави ще через 3 дні.
Тоді що таке VDF? Verifiable Delay Function – це перевірена функція затримки. Ця математична функція задовольняє строгі характеристики послідовного виконання. Вона виконуватиме деякі кроки обчислення та потребуватиме принаймні передбачуваний період часу. Ми записуємо значення, розраховане VDF, як оцінку, яка задовольняє рівномірний нормальний розподіл. Тому після того, як Sequencer обчислить оцінку VDF, він може оцінити ймовірність бути обраним як юридичний пропонент. **
VDF секвенсора обчислюється наступним чином:
Оцінка = VDF (приватний ключ, публічні входи)
public inputs = { номер поточного блоку, randao }
randao — це випадкове число, яке використовується для того, щоб Sequencer не обчислював власну оцінку VDF на всіх майбутніх висотах блоків заздалегідь
Весь процес Fernet в основному поділяється на 3 етапи:
Етап пропозиції 2. Етап підтвердження 3. Завершення
На початку цього етапу кожен секвенсор використовуватиме VDF для обчислення відповідної оцінки VDF на поточній висоті блоку. Якщо Секвенсер вважає, що його Оцінка VDF, швидше за все, виграє право створювати блок цього разу (припускаючи, що Оцінка задовольняє нормальний розподіл), тоді він надішле Зведений контракт від Пропозиції до L1. Пропозиція містить: хеш послідовності транзакцій, який вказує на попередній блок L2.
unproven block: подається лише вміст блоку пропозиції до контракту Rollup. Далі **Sequencer має надіслати вміст блоку, що відповідає непідтвердженому блоку, і підтвердження VDF до мережі L2 p2p. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 блоків L1 (ця фаза підтримуватиме 50 блоків L1, приблизно 10 хвилин)
Prover отримує всі відповідні транзакції у Block Contents з мережі L2 p2p і створить Proof для блоків з вищим показником VDF. Конструкція Proof також застосовує метод паралельної взаємодії кількох перевірників (подібно до схеми B52).
Таким чином, Sequencer має наприкінці агрегувати докази, що відповідають багатьом різним транзакціям, у доказ блоку (включно з доказом VDF) і надіслати його до контракту зведення L1. Будь-хто може подати Block Contents, який подав Block Proof, до контракту Rollup.
Фіналізація: необхідно подати транзакцію L1, щоб завершити блок. Блок, який можна завершити, має бути виконано: вміст блоку та підтвердження блоку надсилаються, а попередній блок, на який вказується, має бути завершено. На основі відповідності вищезазначеним умовам ви також повинні мати найвищий бал.
Механізм виробництва конвеєрного блоку: Слід зазначити, що Fernet приймає механізм виробництва конвеєрного блоку.Коли завершується фаза пропозиції N-го блоку, починається пропозиція N+1-го блоку (Aptos та інші публічні мережі також мають подібну практику). Але для N+1-го блоку йому потрібно дочекатися фіналізації N-го блоку, перш ніж він зможе подати транзакцію L1 Final Block і пройти перевірку, щоб стати Остаточним блоком.
Потенційні розміри атаки: Якщо секвенсор із найвищим показником VDF навмисно не транслює вміст блоку в L2 p2p, це може призвести до реорганізації блоку.
Розрахунок кількості блоків L2 в reorg: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 блоків
Рішення: збільште механізм блокування дядька, щоб уникнути наявності лише одного повного блоку-кандидата для кожного слота L2 (часового інтервалу створення блоку).
Значення Fernet з точки зору децентралізації: Sequencer приєднується до Комітету Sequencer, обіцяючи 16 ETH, і поріг входу не високий (але не низький). Провер не вимагає жодної застави, але немає штрафу, якщо Провер не генерує докази. Це в основному протилежність схемі B52.
**Активна живучість: **Можна гарантувати живучість усієї мережі, оскільки механізм блокування VDF+uncle може гарантувати наявність більше ніж одного виробника блоків у кожному раунді.
**MEV: **Меркування MEV є найбільш особливими. У плані планується впровадження PBS, щоб після обчислення високого показника VDF як секвенсора ви могли безпосередньо знайти конструктор блоків для створення більш цінного блоку.
**Стійкість до цензури: **Fernet також використовуватиме той самий механізм PBS, що й Ethereum, тому, по суті, проблема антицензури Fernet еквівалентна проблемі PBS Ethereum.
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Розбір пропозиції B52 від Aztec Labs: як ZK-Rollup реалізує децентралізацію вузлів секвенсора?
Автор: 0xhhh, EthStorage
Редактор: Faust, Geek web3
Вступ: відколи Rollup став популярним, децентралізація Sequencer завжди була в центрі уваги спільноти Ethereum/Celestia, і це також непереборна гора в дослідженнях і розробці Layer2. У цьому відношенні різні схеми зведення пропонують ідеї щодо децентралізації вузлів, надаючи надзвичайно широкий простір для уяви для цієї теми.
Автор цієї статті бере за приклад відомий проект ZKRollup Aztec і використовує дві пропозиції під назвою B52 і Fernet, нещодавно запропоновані Aztec Labs, як відправну точку для аналізу того, як ZKR реалізує децентралізацію вузлів секвенсора для читачів.
Пропозиція B52: Схема секвенсора без дозволу
Пропозиція B52 спрямована на досягнення наступного (в ідеалі):
Децентралізована мережа секвенсора, вузли L2 самі обирають кожного раунду пропонентів
Децентралізована мережа прувера, низькі вимоги до обладнання для вузлів прувера
Rollup має хорошу стійкість до цензури в цілому.
Значення MEV, створене L2, отримується вузлами L2
Коли блок L2 надсилається на рівень DA, можна отримати більш ефективну остаточність, а незворотна остаточність повинна чекати на надсилання ValidityProof (підтвердження дійсності).
Токен L2 може мати хорошу економічну модель
І блоки L2, і дані транзакцій поширюються в мережі L2 p2p
L2 успадковує безпеку L1
Ця схема поділяє весь процес виробництва блоку L2 на три часові етапи:
Серед них стадія BPW (пропозиція блоку) — це процес, у якому кілька секвенсорів Seuqnecer пропонують різні блоки та змагаються, а Prover вибирає блок-кандидат, щоб дати голос.
BAW (Block Acceptance) — це процес, у якому Prover створює підтвердження дійсності для блоку та надсилає його.
Вікно блокування пропозиції (стадія блокування пропозиції):
BPW можна розділити на три етапи: Блокова пропозиція, Блокове голосування, Агрегація.
Будь-хто на етапі Block Proposal (BP) може збирати транзакції та транслювати власний вміст BP. Контент BP складатиметься з трьох частин: хеш замовлення txs, відсоток винагороди перевірника, кількість спаленого токена
хеш замовлення txs: Proposer вибирає та сортує найцінніший пакет транзакцій із пулу транзакцій L2 (мемпулу), а потім поміщає хеш-значення цього пакета транзакцій у створений ним блок.
відсоток винагороди за перевірку: відсоток винагороди за блок, який розподіляється між секвенсором і перевірячем
сума маркера запису: кількість оригінальних маркерів L2, запропонованих Пропонентом для знищення, а потім він надсилає запропонований BP до мережі L2 p2p
Етап блокового голосування:
Після того, як Провер отримає BP, запропонований різними Пропозерами в мережі p2p, він проголосує за BP, який може принести йому найбільшу винагороду. Однак склад голосів дуже особливий:
Голосування={BlockHash, індекс дерева доказів}
BlockHash — це хеш пропозиції, за яку голосуватиме перевіряючий, а індекс дерева доказів — це значення листового індексу дерева доказів, у побудові якого братиме участь перевіряючий (пояснено пізніше).
Агрегація агрегації: Пропонент збирає голоси перевіряючих для BP у p2p-мережі L2, агрегує їх і поміщає в BP, а потім надсилає до L1 (кожен BP зазвичай містить лише записи голосування, пов’язані з ним).
Тут необхідно підкреслити передумови для того, щоб BP було обрано та включено до журналу Rollp:
Мати найвищий бал:
SCORE(y) = NUM_PROVERS (x)^3 * BURN_BID(z)^2
NUM_PROVERS (x) — це кількість голосів, отриманих BP, а BURN_BID — кількість токенів L2, які пропонує знищити BP. Оскільки що вищий BURN_BID, то меншу винагороду врешті-решт отримає пропонент BP, тому це значення слід правильно встановити.
У той же час BP потрібно надіслати в L1 до завершення вікна блокових пропозицій, а відповідне підтвердження дійсності має бути завантажено в L1 до завершення вікна прийняття блоків.
Примітка. Під час розрахунку балів BP кількість голосів становить найбільшу частку, а потім кількість спалених жетонів. У той же час схема B52 дозволяє декільком пропонентам (фактично секвенсерам) конкурувати за ефективну квоту BP
Схема B52 вимагає лише від Пропонента (секвенсора) вказати кількість маркерів запису у своєму власному BP (подібно до методу EIP1559) без маркерів ставок заздалегідь, що може зробити мережу більш бездозволною (без дозволу доступу), і є також корисно для L2 Native Token створює дефляцію.
Крім того, BP містить не повні дані транзакцій, а лише хеш послідовності транзакцій.Причина подібна до схеми Ethereum PBS, яка спрямована на те, щоб запобігти шпигуванню за MEV іншими пропозерами.
Докладне пояснення вікна прийняття блоку (стадія прийняття блоку):
Після завершення вікна пропозиції блоку Prover повинен відкрити повні дані транзакції, що відповідають його BP. Якщо вибрано BP, за який проголосував перевіряючий (найвищий бал можна запитати через контракт L1), їм потрібно побудувати допоміжне дерево доказів, яке відповідає дереву індексу доказів, наданому під час голосування.
Якщо припустити, що блок Aztec містить 2^13=16384 транзакцій і є 2048 пристроїв перевірки, то кожен перевірник створює допоміжне дерево доказів, що складається з 2^3=8 транзакцій. Потім перевіряльник транслює створене ним піддерево до In L2 p2p мережі. Після того як пропонент отримає його, він об’єднає всі піддерева доказів у блок доказів.
Потім Propsoer надсилає зведене підтвердження до контракту L1 Rollup, і контракт перевірить правильність підтвердження та відповідних результатів переходу стану. Тут слід зазначити, що якщо Проверяючий навмисно не надає докази, він не тільки не зможе отримати дивіденд від винагороди за блок, обіцяний Пропонентом, але його також буде скорочено, оскільки, щоб стати Проверяючим, йому потрібно токен застави заздалегідь. Таким чином, на відміну від Proposer (Sequencer), Prover не має дозволу.
State Advances (State advancement stage) детальне пояснення:
Після завершення вікна прийняття блоків контракт зведення вибере блок із найвищим балом, який буде включено до журналу зведення, і надішле винагороду за блок Пропоненту та Довірителю відповідно відповідно до пропорції, оголошеної Пропонентом (Секвенсором) у заздалегідь.
**Вище наведено рішення Aztec B52. Однак автор цієї статті вважає, що є деякі потенційні проблеми з пропозицією B52: **
Запитання 1: Якщо доказ дійсності блоку з найвищим балом є неповним. Рішення, надане в пропозиції, полягає в тому, що якщо Запропонент надає лише 50% доказів, то він може отримати лише 50% винагороди за блок, щоб гарантувати, що Запропонатор не має мотивації навмисно не подавати повний доказ. У той же час Prover також може надати підтвердження безпосередньо до контракту.
Згідно з описом пропозиції, прийнятно прийняти блок без підтвердження дійсності завершених транзакцій. Насправді це нерозумно: тому що: zkrollup лише оголошує, що новий стан, який відповідає цьому блоку, є дійсним, коли надається доказ дійсності.
Якщо в сукупному доказі, поданому пропонентом до L1, відсутній доказ певної транзакції, очевидно, що докази переходу стану всіх транзакцій, які відбуваються після цієї транзакції, є недійсними (оскільки транзакції виконуються послідовно та мають залежності від стану), ми Також неможливо підтвердити, що новий стан, який відповідає цьому блоку, є дійсним.
Таким чином, наразі розумним способом має бути увійти у вікно прийняття блоку, яке нескінченно чекає, доки не будуть подані всі докази транзакцій.
Запитання 2: **Якщо блок з найвищим балом є незаконним блоком (це не пояснюється в схемі B52). **BP містить лише хеш послідовності транзакцій, тому зловмисник може фактично навмисно створювати проблемні транзакції, такі як транзакції подвійного витрачання. Тож на даний момент фактично необхідно додати функцію в контракт L1, щоб будь-хто міг подати незаконне підтвердження.Це незаконне підтвердження використовується для підтвердження того, що BP з найвищим балом є незаконним блоком.
І цей вид звіту має бути винагороджений, ми можемо винагородити токен запису, надісланий пропонентом контракту вузлу звіту, який надав незаконне підтвердження.
**Цікава думка:**Про блоки дядька та надлишкову роботу перевірки: схема B52 фактично використовуватиме інших BP (які подали повні докази), які з’являться в цьому раунді як дядьки після того, як з’явиться BP з найвищим балом у кожному раунді. призначити певну винагороду за блокування дядька.
Це фактично відповідає підходу консенсусного механізму ETH POW. Щоб уникнути надмірної концентрації обчислювальної потужності, необхідно виділити частину винагороди за блоки неприйнятним пропонентам блоків (майнерам), щоб захистити інтереси невеликих майнінг-пулів/окремих майнерів. і уникайте. Обчислювальна потужність монополізована великими майнінг-пулами. Тому також дуже розумним вибором буде прийняти механізм блокування дядька, який Ethereum працює добре.
Значення пропозиції B52 з точки зору децентралізації Rollup: Пропонент децентралізований і не потребує застави, а поріг входу низький; але тому, що вам потрібно самостійно створити найцінніші блоки, і вам потрібно збирати голоси від інших Пропонентів і об’єднати всі Докази. Насправді, поріг апаратного забезпечення Пропонента не такий низький, як зазначено в пропозиції (наприклад, пропускна здатність може бути не дуже низькою).
Тому згодом це стане відносно централізованою мережею, подібною до Mev-Boost Builder, тому що пропонент, який нарешті може генерувати блоки, часто є Block Builder, який найкраще вловлює MEV.
У той же час перевіряльник у схемі B52 має заставити активи, але оскільки потрібно створити лише доказ піддерева, у порівнянні з тими схемами, які потребують повністю створити доказ блоку, **ступінь децентралізації перевірятиме краще (вимоги до обладнання можна знизити). **
Активна активність: Загальна активність мережі хороша, тому що L2 має власну p2p-мережу для трансляції транзакцій і голосувань/BP, а Sequencer і Prover відносно децентралізовані. Але нам потрібно вирішити дві проблеми, які ми згадували вище: одна полягає в тому, що блок з найвищим балом має бути легальним блоком, а друга полягає в тому, що йому потрібно дочекатися, поки повне підтвердження блоку буде надіслано в L1, перш ніж вводити новий стан. Тому потрібен більш ефективний механізм стимулювання, щоб запобігти несправності (простою) усієї мережі Rollup через відсутність певної частини доказу передачі.
**Стійкість до цензури: **Якщо ми можемо гарантувати, що будь-хто може опублікувати пропозицію блокування BP, і переконатися, що не лише Пропонент може надати доказ блокування, тоді мережа матиме гарний опір цензурі.
**Завершеність: **Завершеність L2 тісно пов’язана з активністю мережі, тому що остаточна підтверджена остаточність все ще повинна чекати подання Block Proof, але насправді ви також можете довіряти вмісту блоку, що відповідає BP з найвищим балом (якщо він не містить зловмисних транзакцій).
Цей блок буде показано на початку вікна прийняття блоку, а це означає, що вам, як користувачу, потрібно лише дочекатися вікна пропозиції блоку, і блок, у якому подана вами транзакція може бути прийнята.
Успадкувати безпеку L1: Як L2, який оновлює свій статус, надаючи підтвердження дійсності, він може успадкувати безпеку L1.
Пропозиція Fernet: введіть VDF, щоб вибрати законного Пропонента
Представлення схеми Fernet: Через VDF у кожному раунді циклу генерації блоку встановлюється приблизний бал для різних вузлів у Комітеті (тобто набору вузлів секвенсора), а блок, запропонований секвенсором, з найвищий підсумковий бал стане дійсним.
**По-перше, як приєднатися до комітету? Насправді вам потрібно пообіцяти 16 ETH в L1, **і зачекати 4 блоки L1 після завершення операції застави, а потім приєднатися до Комітету секвенсорів. Що стосується виходу з Комітету секвенсорів, вам потрібно викликати функцію Unstake у контракті L1, і тоді ви зможете повернути решту суми своєї застави ще через 3 дні.
Тоді що таке VDF? Verifiable Delay Function – це перевірена функція затримки. Ця математична функція задовольняє строгі характеристики послідовного виконання. Вона виконуватиме деякі кроки обчислення та потребуватиме принаймні передбачуваний період часу. Ми записуємо значення, розраховане VDF, як оцінку, яка задовольняє рівномірний нормальний розподіл. Тому після того, як Sequencer обчислить оцінку VDF, він може оцінити ймовірність бути обраним як юридичний пропонент. **
VDF секвенсора обчислюється наступним чином:
Оцінка = VDF (приватний ключ, публічні входи)
public inputs = { номер поточного блоку, randao }
randao — це випадкове число, яке використовується для того, щоб Sequencer не обчислював власну оцінку VDF на всіх майбутніх висотах блоків заздалегідь
Весь процес Fernet в основному поділяється на 3 етапи:
**Етап пропозиції:**PROPOSAL_PHASE_L1_BLOCKS = 2 блоки Ethereum (ця фаза триватиме 2 блоки L1)
На початку цього етапу кожен секвенсор використовуватиме VDF для обчислення відповідної оцінки VDF на поточній висоті блоку. Якщо Секвенсер вважає, що його Оцінка VDF, швидше за все, виграє право створювати блок цього разу (припускаючи, що Оцінка задовольняє нормальний розподіл), тоді він надішле Зведений контракт від Пропозиції до L1. Пропозиція містить: хеш послідовності транзакцій, який вказує на попередній блок L2.
unproven block: подається лише вміст блоку пропозиції до контракту Rollup. Далі **Sequencer має надіслати вміст блоку, що відповідає непідтвердженому блоку, і підтвердження VDF до мережі L2 p2p. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 блоків L1 (ця фаза підтримуватиме 50 блоків L1, приблизно 10 хвилин)
Prover отримує всі відповідні транзакції у Block Contents з мережі L2 p2p і створить Proof для блоків з вищим показником VDF. Конструкція Proof також застосовує метод паралельної взаємодії кількох перевірників (подібно до схеми B52).
Таким чином, Sequencer має наприкінці агрегувати докази, що відповідають багатьом різним транзакціям, у доказ блоку (включно з доказом VDF) і надіслати його до контракту зведення L1. Будь-хто може подати Block Contents, який подав Block Proof, до контракту Rollup.
Фіналізація: необхідно подати транзакцію L1, щоб завершити блок. Блок, який можна завершити, має бути виконано: вміст блоку та підтвердження блоку надсилаються, а попередній блок, на який вказується, має бути завершено. На основі відповідності вищезазначеним умовам ви також повинні мати найвищий бал.
Механізм виробництва конвеєрного блоку: Слід зазначити, що Fernet приймає механізм виробництва конвеєрного блоку.Коли завершується фаза пропозиції N-го блоку, починається пропозиція N+1-го блоку (Aptos та інші публічні мережі також мають подібну практику). Але для N+1-го блоку йому потрібно дочекатися фіналізації N-го блоку, перш ніж він зможе подати транзакцію L1 Final Block і пройти перевірку, щоб стати Остаточним блоком.
Потенційні розміри атаки: Якщо секвенсор із найвищим показником VDF навмисно не транслює вміст блоку в L2 p2p, це може призвести до реорганізації блоку.
Розрахунок кількості блоків L2 в reorg: 1+PROVING_PHASE_L1_BLOCKS / PROPOSAL_PHASE_L1_BLOCKS =1+50/2=26 блоків
Рішення: збільште механізм блокування дядька, щоб уникнути наявності лише одного повного блоку-кандидата для кожного слота L2 (часового інтервалу створення блоку).
Значення Fernet з точки зору децентралізації: Sequencer приєднується до Комітету Sequencer, обіцяючи 16 ETH, і поріг входу не високий (але не низький). Провер не вимагає жодної застави, але немає штрафу, якщо Провер не генерує докази. Це в основному протилежність схемі B52.
**Активна живучість: **Можна гарантувати живучість усієї мережі, оскільки механізм блокування VDF+uncle може гарантувати наявність більше ніж одного виробника блоків у кожному раунді.
**MEV: **Меркування MEV є найбільш особливими. У плані планується впровадження PBS, щоб після обчислення високого показника VDF як секвенсора ви могли безпосередньо знайти конструктор блоків для створення більш цінного блоку.
**Стійкість до цензури: **Fernet також використовуватиме той самий механізм PBS, що й Ethereum, тому, по суті, проблема антицензури Fernet еквівалентна проблемі PBS Ethereum.