Введение: С тех пор, как Rollup стал популярным, децентрализация Sequencer всегда была в центре внимания сообщества Ethereum/Celestia, и это также непреодолимая гора в исследованиях и разработках Layer2. В связи с этим в различных схемах Rollup предлагались идеи о децентрализации узлов, предоставляя чрезвычайно широкое пространство для воображения по этой теме.
Автор этой статьи берет в качестве примера известный проект ZKRollup Aztec и использует два предложения под названием B52 и Fernet, недавно предложенные Aztec Labs, в качестве отправной точки для анализа того, как ZKR реализует децентрализацию узлов секвенсора для читателей.
Предложение B52: Схема секвенсора без прав доступа
Предложение B52 направлено на достижение следующего (в идеале):
Децентрализованная сеть секвенсоров, узлы L2 сами выбирают каждый раунд предлагающих
Децентрализованная сеть прувера, низкие требования к оборудованию для узлов прувера
Роллап в целом имеет хорошую устойчивость к цензуре.
Значение MEV, сгенерированное L2, приобретается узлами L2.
Когда блок L2 отправляется на уровень DA, может быть получена более эффективная завершенность, а необратимая завершенность должна ждать отправки ValidityProof (доказательства достоверности).
Токен L2 может иметь хорошую экономическую модель
И блоки L2, и данные транзакций распространяются в сети L2 p2p.
L2 наследует безопасность L1
Эта схема делит весь процесс производства блока L2 на три временных этапа:
Окно предложения блокировки (BPW)
Окно принятия блокировки (BAW)
Государственные авансы
Среди них этап BPW (предложение блока) — это процесс, в котором несколько секвенаторов Seuqnecer предлагают разные блоки и соревнуются, а Prover выбирает блок-кандидат для голосования.
BAW (принятие блоков) — это процесс, в котором доказывающий создает доказательство валидности для блока и отправляет его.
Окно предложения блокировки (стадия предложения блокировки):
BPW можно разделить на три этапа: Предложение блока, Голосование за блок, Агрегация.
Любой, кто находится на этапе предложения блокировки (BP), может собирать транзакции и транслировать свой собственный контент BP. Контент BP будет состоять из трех частей: хэш заказа txs, процент вознаграждения за проверку, количество токенов сжигания.
хэш заказа txs: предлагающий выбирает и сортирует наиболее ценный пакет транзакций из пула транзакций L2 (мемпул), а затем помещает хеш-значение этого пакета транзакций в блок, который он создает.
Процент вознаграждения доказывающего: Процент вознаграждения за блок, разделяемый секвенсором и доказывающим.
количество токенов сжигания: Количество Native Token L2, предложенное предлагающим для уничтожения, а затем он отправляет предложенный BP в p2p-сеть L2.
Этап голосования за блокировку:
После того, как Доказывающий получит BP, предложенный разными Предлагающими в сети p2p, он проголосует за BP, который может принести ему наибольшую награду. Однако состав голосования весьма особенный:
Vote={BlockHash, индекс дерева доказательств}
BlockHash — это хэш Предложения, за которое будет голосовать Доказывающий, а Индекс Дерева Доказательств — это значение конечного индекса Дерева Доказательств, в построении которого будет участвовать Доказывающий (поясняется позже).
Агрегация агрегации: Предлагающий собирает голоса доказывающих за BP в p2p-сети L2, объединяет их и помещает в BP, а затем отправляет их в L1 (каждый BP обычно содержит только записи голосования, связанные с ним самим).
Здесь необходимо подчеркнуть предпосылки для выбора и включения BP в регистр Rollp:
NUM_PROVERS (x) — это количество голосов Prover, полученных BP, а BURN_BID — это количество токенов L2, предложенных для уничтожения BP. Поскольку чем выше BURN_BID, тем меньше вознаграждение в итоге получит предлагающий BP, поэтому это значение должно быть установлено правильно.
В то же время, BP должен быть отправлен на L1 до окончания окна предложения блокировки, а соответствующее подтверждение действительности должно быть загружено на L1 до окончания окна принятия блокировки.
Примечание. При подсчете баллов BP наибольшая доля приходится на количество голосов, за которым следует количество сожженных токенов. В то же время схема B52 позволяет нескольким предлагающим (фактически секвенаторам) конкурировать за эффективную квоту BP.
Схема B52 требует только, чтобы предлагающий (секвенсор) указал количество токенов записи в своем собственном BP (аналогично методу EIP1559) без токенов доли заранее, что может сделать сеть более неразрешенной (отсутствие разрешения на доступ), и Также выгодно, чтобы L2 Native Token производил дефляцию.
Кроме того, BP не содержит полных данных о транзакциях, а только хэш последовательности транзакций по той же причине, что и схема Ethereum PBS, цель которой — предотвратить слежку за MEV другими предлагающими.
Окно принятия блока (этап принятия блока) подробное объяснение:
После того, как окно предложения блокировки закончится, доказывающий должен раскрыть полные данные транзакции, соответствующие его BP. Если выбран BP, за который проголосовал доказывающий (наибольшая оценка может быть запрошена через контракт L1), им необходимо построить вспомогательное дерево доказательств, соответствующее индексу дерева доказательств, указанному во время голосования.
Если предположить, что блок Aztec содержит 2^13=16384 транзакций, а доказывающих 2048, то каждый доказывающий строит дерево вспомогательных доказательств, состоящее из 2^3=8 транзакций, и передает построенное им дерево вспомогательных доказательств в L2 p2p. сеть. После того, как предлагающий его получит, он объединит все вложенные деревья доказательств в блочное доказательство.
Затем Propsoer отправляет агрегированное доказательство в контракт L1 Rollup, и контракт проверяет правильность доказательства и соответствующие результаты перехода состояния. Здесь следует отметить, что если Доказывающий умышленно не представит доказательство, он не только не сможет получить обещанный Предлагающим дивиденд вознаграждения за блок, но и будет урезан, потому что, чтобы стать Доказывающим, ему нужно залог Token заранее. Следовательно, в отличие от Proposer (Sequencer), Prover не является неограниченным.
Государственные авансы (этап государственного продвижения) подробное объяснение:
После того, как окно принятия блока завершится, контракт объединения выберет блок с наибольшим количеством баллов, который будет включен в реестр объединения, и отправит вознаграждение за блок предлагающему и доказывающему соответственно в соответствии с пропорцией, объявленной предлагающим (секвенсором) в продвигать.
Выше приведено решение Aztec B52. Однако автор этой статьи считает, что в предложении B52 есть некоторые потенциальные проблемы:
Вопрос 1: Если подтверждение достоверности блока с наивысшим баллом неполное. Решение, данное в предложении, заключается в том, что если предлагающий предоставляет только 50% доказательства, то он может получить только 50% вознаграждения за блок, чтобы гарантировать, что у предлагающего нет мотивации намеренно не предоставлять полное доказательство. В то же время доказывающий также может представить доказательство непосредственно в договоре.
Согласно описанию предложения, допустимо принимать блок без подтверждения достоверности завершенных транзакций. Это на самом деле неразумно: потому что: zkrollup только объявляет, что новое состояние, соответствующее этому блоку, действительно, когда дается доказательство достоверности.
Если в совокупном доказательстве, представленном предлагающим в L1, отсутствует доказательство определенной транзакции, очевидно, что доказательства перехода состояния всех транзакций, которые происходят после этой транзакции, недействительны (поскольку транзакции выполняются последовательно и имеют зависимости состояния), мы Также невозможно подтвердить, что новое состояние, соответствующее этому блоку, действительно.
Поэтому в настоящее время разумным способом должен быть вход в окно принятия блока, которое бесконечно ждет, пока не будут отправлены все подтверждения транзакций.
Вопрос 2: **Если блок с наибольшим количеством очков является недопустимым блоком (это не объясняется в схеме B52). **BP содержит только хэш последовательности транзакций, поэтому злоумышленник может намеренно создавать проблемные транзакции, например транзакции с двойным расходом. Таким образом, в настоящее время необходимо добавить в контракт L1 функцию, позволяющую любому представить нелегальное доказательство, которое используется для доказательства того, что BP с наибольшим количеством очков является незаконным блоком.
И такой отчет должен быть вознагражден, мы можем вознаградить токен сжигания, отправленный предлагающим контракт узлу-репортеру, который представил незаконное доказательство.
**Интересное размышление:**О дядиных блоках и избыточной доказывающей работе: схема B52 фактически будет использовать других БП (предоставивших полные доказательства), которые появляются в этом раунде в качестве дядей после появления БП с наивысшим баллом в каждом раунде. назначить определенную награду за блок дяди.
Это фактически соответствует подходу механизма консенсуса ETH POW: во избежание чрезмерной концентрации вычислительных мощностей необходимо выделять часть вознаграждения за блок непринятым инициаторам блока (майнерам) для защиты интересов небольших майнинговых пулов/отдельных майнеров. и избегайте. Вычислительная мощность монополизирована крупными пулами майнинга. Таким образом, это также очень разумный выбор — использовать механизм дяди-блока, который хорошо работает в Ethereum.
Значимость предложения B52 с точки зрения децентрализации Rollup: Предлагающий децентрализован и не требует залога, а порог входа низкий, а потому, что вам нужно построить самые ценные блоки самостоятельно, и вам нужно собрать голоса от других Proposers и агрегировать все Proofs.На самом деле аппаратный порог Proposer не так низок, как указано в предложении (например, пропускная способность может быть не очень низкой).
Таким образом, в конечном итоге она станет относительно централизованной сетью, похожей на Mev-Boost Builder, потому что предлагающий, который, наконец, может генерировать блоки, часто является Block Builder, который лучше всего захватывает MEV.
В то же время доказывающий в схеме B52 должен закладывать активы, но, поскольку необходимо генерировать только доказательство поддерева, по сравнению с теми схемами, которые должны полностью генерировать доказательство всего блока, ** степень децентрализации доказывающего будет лучше (требования к оборудованию могут быть снижены). **
Активная живучесть: Общая живучесть сети хорошая, потому что L2 имеет собственную p2p-сеть для трансляции транзакций и голосов/BP, а Sequencer и Prover относительно децентрализованы. Но нам нужно решить две проблемы, о которых мы упоминали выше: во-первых, блок с наибольшим количеством очков должен быть допустимым блоком, а во-вторых, необходимо дождаться отправки полного доказательства блока в L1, прежде чем вводить новый блок. состояние. Поэтому необходим более эффективный механизм поощрения, чтобы предотвратить сбои (даунтаймы) всей сети Rollup из-за отсутствия определенной части tx proof.
** Сопротивление цензуре: ** Если мы сможем гарантировать, что любой может опубликовать предложение о блокировке BP, и удостоверимся, что не только предлагающий может представить доказательство блокировки, тогда в сети будет хорошая антицензура.
** Окончательность: ** Окончательность L2 тесно связана с жизнеспособностью сети, потому что для окончательной проверки окончательности все еще нужно дождаться отправки доказательства блока, но на самом деле вы также можете доверять содержимому блока, соответствующему BP. с наивысшим баллом (при условии, что он не содержит вредоносных транзакций).
Этот блок будет показан в начале окна принятия блока, что означает, что как пользователю вам нужно только дождаться окна предложения блока и блока, в котором отправленная вами транзакция может быть принята.
Наследовать безопасность L1: Как L2, который обновляет свой статус, отправляя подтверждение достоверности, он может наследовать безопасность L1.
Предложение Fernet: представить VDF для выбора законного Предложившего
Введение схемы Фернета: Через VDF в каждом раунде цикла генерации блоков оценочная оценка устанавливается для различных узлов в комитете (то есть набор узлов секвенсора), а блок, предложенный секвенсором с самая высокая итоговая оценка станет действительной частью.
**Во-первых, как вступить в Комитет? На самом деле вам нужно заложить 16 ETH в L1, ** и дождаться 4 блоков L1 после завершения операции залога, а затем присоединиться к Комитету секвенсора. Что касается выхода из Sequencer Committee, то вам необходимо вызвать функцию Unstake в L1-контракте, после чего вы сможете вернуть оставшуюся сумму вашего залога еще через 3 дня.
Тогда что такое VDF? Поддающаяся проверке функция задержки — поддающаяся проверке функция задержки.Эта математическая функция удовлетворяет строгим характеристикам последовательного выполнения.Она будет выполнять некоторые этапы расчета и потреблять как минимум предсказуемый период времени. Мы записываем значение, рассчитанное VDF, как Score, которое удовлетворяет равномерному нормальному распределению.Поэтому после того, как Sequencer рассчитает VDF Score, он может судить о вероятности быть выбранным в качестве законного предлагающего. **
randao — это случайное число, используемое для предотвращения вычисления Sequencer собственной оценки VDF на всех будущих высотах блоков заранее.
Весь процесс Fernet в основном делится на 3 этапа:
Этап предложения 2. Этап проверки 3. Завершение
**Фаза предложения:**PROPOSAL_PHASE_L1_BLOCKS = 2 блока Ethereum (эта фаза будет длиться 2 блока L1)
В начале этого этапа каждый секвенсор будет использовать VDF для расчета соответствующей оценки VDF на текущей высоте блока. Если секвенсер считает, что его оценка VDF, скорее всего, выиграет право на создание блока на этот раз (при условии, что оценка удовлетворяет нормальному распределению), тогда он отправит накопительный контракт из предложения в L1. Предложение содержит: хэш последовательности транзакций, указывающий на какой предыдущий блок L2.
неподтвержденный блок: передается только содержимое блока предложения к накопительному контракту. Затем **Sequencer должен отправить содержимое блока, соответствующее недоказанному блоку, и подтверждение VDF в сеть p2p L2. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 блоков L1 (эта фаза будет поддерживать 50 блоков L1, около 10 минут)
Доказывающий получает все соответствующие транзакции в содержимом блока из сети L2 p2p и создает доказательство для блоков с более высоким показателем VDF. При построении доказательства также используется метод параллельного сотрудничества нескольких доказывающих (аналогично схеме B52).
Следовательно, Sequencer должен в конце агрегировать Proofs, соответствующие нескольким различным транзакциям, в Block Proof (включая VDF Proof) и отправить его в контракт Rollup L1. Любой желающий может отправить содержимое блока, которое представило доказательство блокировки, в контракт на объединение.
Завершение: необходимо отправить транзакцию L1 для завершения блока. Блок, который может быть завершен, должен быть удовлетворен: содержимое блока и подтверждение блока отправлены, а предыдущий блок, на который указывает ссылка, должен быть завершен. На основании выполнения вышеперечисленных условий вы также должны иметь наивысший балл.
Механизм производства блоков конвейера: следует отметить, что Fernet использует механизм производства блоков конвейера: когда фаза предложения N-го блока заканчивается, начинается предложение блока N+1 (Aptos и другие публичные сети также имеют аналогичную практику). Но для N+1-го блока необходимо дождаться финализации N-го блока, прежде чем он сможет отправить транзакцию финального блока L1 и пройти проверку, чтобы стать финальным блоком.
Возможные размеры атаки: Если секвенсор с наивысшим показателем 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.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Анализ предложения Aztec Labs B52: как ZK-Rollup реализует децентрализацию узлов секвенсора?
Автор: 0xhhh, EthStorage
Редактор: Faust, Geek web3
Введение: С тех пор, как Rollup стал популярным, децентрализация Sequencer всегда была в центре внимания сообщества Ethereum/Celestia, и это также непреодолимая гора в исследованиях и разработках Layer2. В связи с этим в различных схемах Rollup предлагались идеи о децентрализации узлов, предоставляя чрезвычайно широкое пространство для воображения по этой теме.
Автор этой статьи берет в качестве примера известный проект ZKRollup Aztec и использует два предложения под названием B52 и Fernet, недавно предложенные Aztec Labs, в качестве отправной точки для анализа того, как ZKR реализует децентрализацию узлов секвенсора для читателей.
Предложение B52: Схема секвенсора без прав доступа
Предложение B52 направлено на достижение следующего (в идеале):
Децентрализованная сеть секвенсоров, узлы L2 сами выбирают каждый раунд предлагающих
Децентрализованная сеть прувера, низкие требования к оборудованию для узлов прувера
Роллап в целом имеет хорошую устойчивость к цензуре.
Значение MEV, сгенерированное L2, приобретается узлами L2.
Когда блок L2 отправляется на уровень DA, может быть получена более эффективная завершенность, а необратимая завершенность должна ждать отправки ValidityProof (доказательства достоверности).
Токен L2 может иметь хорошую экономическую модель
И блоки L2, и данные транзакций распространяются в сети L2 p2p.
L2 наследует безопасность L1
Эта схема делит весь процесс производства блока L2 на три временных этапа:
Среди них этап BPW (предложение блока) — это процесс, в котором несколько секвенаторов Seuqnecer предлагают разные блоки и соревнуются, а Prover выбирает блок-кандидат для голосования.
BAW (принятие блоков) — это процесс, в котором доказывающий создает доказательство валидности для блока и отправляет его.
Окно предложения блокировки (стадия предложения блокировки):
BPW можно разделить на три этапа: Предложение блока, Голосование за блок, Агрегация.
Любой, кто находится на этапе предложения блокировки (BP), может собирать транзакции и транслировать свой собственный контент BP. Контент BP будет состоять из трех частей: хэш заказа txs, процент вознаграждения за проверку, количество токенов сжигания.
хэш заказа txs: предлагающий выбирает и сортирует наиболее ценный пакет транзакций из пула транзакций L2 (мемпул), а затем помещает хеш-значение этого пакета транзакций в блок, который он создает.
Процент вознаграждения доказывающего: Процент вознаграждения за блок, разделяемый секвенсором и доказывающим.
количество токенов сжигания: Количество Native Token L2, предложенное предлагающим для уничтожения, а затем он отправляет предложенный BP в p2p-сеть L2.
Этап голосования за блокировку:
После того, как Доказывающий получит BP, предложенный разными Предлагающими в сети p2p, он проголосует за BP, который может принести ему наибольшую награду. Однако состав голосования весьма особенный:
Vote={BlockHash, индекс дерева доказательств}
BlockHash — это хэш Предложения, за которое будет голосовать Доказывающий, а Индекс Дерева Доказательств — это значение конечного индекса Дерева Доказательств, в построении которого будет участвовать Доказывающий (поясняется позже).
Агрегация агрегации: Предлагающий собирает голоса доказывающих за BP в p2p-сети L2, объединяет их и помещает в BP, а затем отправляет их в L1 (каждый BP обычно содержит только записи голосования, связанные с ним самим).
Здесь необходимо подчеркнуть предпосылки для выбора и включения BP в регистр Rollp:
Набрать наивысший балл:
ОЦЕНКА(y) = ЧИСЛО_ДОКАЗАТЕЛЬСТВ (x)^3 * СЖИГАНИЕ_BID(z)^2
NUM_PROVERS (x) — это количество голосов Prover, полученных BP, а BURN_BID — это количество токенов L2, предложенных для уничтожения BP. Поскольку чем выше BURN_BID, тем меньше вознаграждение в итоге получит предлагающий BP, поэтому это значение должно быть установлено правильно.
В то же время, BP должен быть отправлен на L1 до окончания окна предложения блокировки, а соответствующее подтверждение действительности должно быть загружено на L1 до окончания окна принятия блокировки.
Примечание. При подсчете баллов BP наибольшая доля приходится на количество голосов, за которым следует количество сожженных токенов. В то же время схема B52 позволяет нескольким предлагающим (фактически секвенаторам) конкурировать за эффективную квоту BP.
Схема B52 требует только, чтобы предлагающий (секвенсор) указал количество токенов записи в своем собственном BP (аналогично методу EIP1559) без токенов доли заранее, что может сделать сеть более неразрешенной (отсутствие разрешения на доступ), и Также выгодно, чтобы L2 Native Token производил дефляцию.
Кроме того, BP не содержит полных данных о транзакциях, а только хэш последовательности транзакций по той же причине, что и схема Ethereum PBS, цель которой — предотвратить слежку за MEV другими предлагающими.
Окно принятия блока (этап принятия блока) подробное объяснение:
После того, как окно предложения блокировки закончится, доказывающий должен раскрыть полные данные транзакции, соответствующие его BP. Если выбран BP, за который проголосовал доказывающий (наибольшая оценка может быть запрошена через контракт L1), им необходимо построить вспомогательное дерево доказательств, соответствующее индексу дерева доказательств, указанному во время голосования.
Если предположить, что блок Aztec содержит 2^13=16384 транзакций, а доказывающих 2048, то каждый доказывающий строит дерево вспомогательных доказательств, состоящее из 2^3=8 транзакций, и передает построенное им дерево вспомогательных доказательств в L2 p2p. сеть. После того, как предлагающий его получит, он объединит все вложенные деревья доказательств в блочное доказательство.
Затем Propsoer отправляет агрегированное доказательство в контракт L1 Rollup, и контракт проверяет правильность доказательства и соответствующие результаты перехода состояния. Здесь следует отметить, что если Доказывающий умышленно не представит доказательство, он не только не сможет получить обещанный Предлагающим дивиденд вознаграждения за блок, но и будет урезан, потому что, чтобы стать Доказывающим, ему нужно залог Token заранее. Следовательно, в отличие от Proposer (Sequencer), Prover не является неограниченным.
Государственные авансы (этап государственного продвижения) подробное объяснение:
После того, как окно принятия блока завершится, контракт объединения выберет блок с наибольшим количеством баллов, который будет включен в реестр объединения, и отправит вознаграждение за блок предлагающему и доказывающему соответственно в соответствии с пропорцией, объявленной предлагающим (секвенсором) в продвигать.
Выше приведено решение Aztec B52. Однако автор этой статьи считает, что в предложении B52 есть некоторые потенциальные проблемы:
Вопрос 1: Если подтверждение достоверности блока с наивысшим баллом неполное. Решение, данное в предложении, заключается в том, что если предлагающий предоставляет только 50% доказательства, то он может получить только 50% вознаграждения за блок, чтобы гарантировать, что у предлагающего нет мотивации намеренно не предоставлять полное доказательство. В то же время доказывающий также может представить доказательство непосредственно в договоре.
Согласно описанию предложения, допустимо принимать блок без подтверждения достоверности завершенных транзакций. Это на самом деле неразумно: потому что: zkrollup только объявляет, что новое состояние, соответствующее этому блоку, действительно, когда дается доказательство достоверности.
Если в совокупном доказательстве, представленном предлагающим в L1, отсутствует доказательство определенной транзакции, очевидно, что доказательства перехода состояния всех транзакций, которые происходят после этой транзакции, недействительны (поскольку транзакции выполняются последовательно и имеют зависимости состояния), мы Также невозможно подтвердить, что новое состояние, соответствующее этому блоку, действительно.
Поэтому в настоящее время разумным способом должен быть вход в окно принятия блока, которое бесконечно ждет, пока не будут отправлены все подтверждения транзакций.
Вопрос 2: **Если блок с наибольшим количеством очков является недопустимым блоком (это не объясняется в схеме B52). **BP содержит только хэш последовательности транзакций, поэтому злоумышленник может намеренно создавать проблемные транзакции, например транзакции с двойным расходом. Таким образом, в настоящее время необходимо добавить в контракт L1 функцию, позволяющую любому представить нелегальное доказательство, которое используется для доказательства того, что BP с наибольшим количеством очков является незаконным блоком.
И такой отчет должен быть вознагражден, мы можем вознаградить токен сжигания, отправленный предлагающим контракт узлу-репортеру, который представил незаконное доказательство.
**Интересное размышление:**О дядиных блоках и избыточной доказывающей работе: схема B52 фактически будет использовать других БП (предоставивших полные доказательства), которые появляются в этом раунде в качестве дядей после появления БП с наивысшим баллом в каждом раунде. назначить определенную награду за блок дяди.
Это фактически соответствует подходу механизма консенсуса ETH POW: во избежание чрезмерной концентрации вычислительных мощностей необходимо выделять часть вознаграждения за блок непринятым инициаторам блока (майнерам) для защиты интересов небольших майнинговых пулов/отдельных майнеров. и избегайте. Вычислительная мощность монополизирована крупными пулами майнинга. Таким образом, это также очень разумный выбор — использовать механизм дяди-блока, который хорошо работает в Ethereum.
Значимость предложения B52 с точки зрения децентрализации Rollup: Предлагающий децентрализован и не требует залога, а порог входа низкий, а потому, что вам нужно построить самые ценные блоки самостоятельно, и вам нужно собрать голоса от других Proposers и агрегировать все Proofs.На самом деле аппаратный порог Proposer не так низок, как указано в предложении (например, пропускная способность может быть не очень низкой).
Таким образом, в конечном итоге она станет относительно централизованной сетью, похожей на Mev-Boost Builder, потому что предлагающий, который, наконец, может генерировать блоки, часто является Block Builder, который лучше всего захватывает MEV.
В то же время доказывающий в схеме B52 должен закладывать активы, но, поскольку необходимо генерировать только доказательство поддерева, по сравнению с теми схемами, которые должны полностью генерировать доказательство всего блока, ** степень децентрализации доказывающего будет лучше (требования к оборудованию могут быть снижены). **
Активная живучесть: Общая живучесть сети хорошая, потому что L2 имеет собственную p2p-сеть для трансляции транзакций и голосов/BP, а Sequencer и Prover относительно децентрализованы. Но нам нужно решить две проблемы, о которых мы упоминали выше: во-первых, блок с наибольшим количеством очков должен быть допустимым блоком, а во-вторых, необходимо дождаться отправки полного доказательства блока в L1, прежде чем вводить новый блок. состояние. Поэтому необходим более эффективный механизм поощрения, чтобы предотвратить сбои (даунтаймы) всей сети Rollup из-за отсутствия определенной части tx proof.
** Сопротивление цензуре: ** Если мы сможем гарантировать, что любой может опубликовать предложение о блокировке BP, и удостоверимся, что не только предлагающий может представить доказательство блокировки, тогда в сети будет хорошая антицензура.
** Окончательность: ** Окончательность L2 тесно связана с жизнеспособностью сети, потому что для окончательной проверки окончательности все еще нужно дождаться отправки доказательства блока, но на самом деле вы также можете доверять содержимому блока, соответствующему BP. с наивысшим баллом (при условии, что он не содержит вредоносных транзакций).
Этот блок будет показан в начале окна принятия блока, что означает, что как пользователю вам нужно только дождаться окна предложения блока и блока, в котором отправленная вами транзакция может быть принята.
Наследовать безопасность L1: Как L2, который обновляет свой статус, отправляя подтверждение достоверности, он может наследовать безопасность L1.
Предложение Fernet: представить VDF для выбора законного Предложившего
Введение схемы Фернета: Через VDF в каждом раунде цикла генерации блоков оценочная оценка устанавливается для различных узлов в комитете (то есть набор узлов секвенсора), а блок, предложенный секвенсором с самая высокая итоговая оценка станет действительной частью.
**Во-первых, как вступить в Комитет? На самом деле вам нужно заложить 16 ETH в L1, ** и дождаться 4 блоков L1 после завершения операции залога, а затем присоединиться к Комитету секвенсора. Что касается выхода из Sequencer Committee, то вам необходимо вызвать функцию Unstake в L1-контракте, после чего вы сможете вернуть оставшуюся сумму вашего залога еще через 3 дня.
Тогда что такое VDF? Поддающаяся проверке функция задержки — поддающаяся проверке функция задержки.Эта математическая функция удовлетворяет строгим характеристикам последовательного выполнения.Она будет выполнять некоторые этапы расчета и потреблять как минимум предсказуемый период времени. Мы записываем значение, рассчитанное VDF, как Score, которое удовлетворяет равномерному нормальному распределению.Поэтому после того, как Sequencer рассчитает VDF Score, он может судить о вероятности быть выбранным в качестве законного предлагающего. **
VDF секвенсора рассчитывается следующим образом:
Оценка = VDF (закрытый ключ, общедоступные входные данные)
public inputs = {текущий номер блока, randao}
randao — это случайное число, используемое для предотвращения вычисления Sequencer собственной оценки VDF на всех будущих высотах блоков заранее.
Весь процесс Fernet в основном делится на 3 этапа:
**Фаза предложения:**PROPOSAL_PHASE_L1_BLOCKS = 2 блока Ethereum (эта фаза будет длиться 2 блока L1)
В начале этого этапа каждый секвенсор будет использовать VDF для расчета соответствующей оценки VDF на текущей высоте блока. Если секвенсер считает, что его оценка VDF, скорее всего, выиграет право на создание блока на этот раз (при условии, что оценка удовлетворяет нормальному распределению), тогда он отправит накопительный контракт из предложения в L1. Предложение содержит: хэш последовательности транзакций, указывающий на какой предыдущий блок L2.
неподтвержденный блок: передается только содержимое блока предложения к накопительному контракту. Затем **Sequencer должен отправить содержимое блока, соответствующее недоказанному блоку, и подтверждение VDF в сеть p2p L2. **
ProvingPhase: PROVING_PHASE_L1_BLOCKS= 50 блоков L1 (эта фаза будет поддерживать 50 блоков L1, около 10 минут)
Доказывающий получает все соответствующие транзакции в содержимом блока из сети L2 p2p и создает доказательство для блоков с более высоким показателем VDF. При построении доказательства также используется метод параллельного сотрудничества нескольких доказывающих (аналогично схеме B52).
Следовательно, Sequencer должен в конце агрегировать Proofs, соответствующие нескольким различным транзакциям, в Block Proof (включая VDF Proof) и отправить его в контракт Rollup L1. Любой желающий может отправить содержимое блока, которое представило доказательство блокировки, в контракт на объединение.
Завершение: необходимо отправить транзакцию L1 для завершения блока. Блок, который может быть завершен, должен быть удовлетворен: содержимое блока и подтверждение блока отправлены, а предыдущий блок, на который указывает ссылка, должен быть завершен. На основании выполнения вышеперечисленных условий вы также должны иметь наивысший балл.
Механизм производства блоков конвейера: следует отметить, что Fernet использует механизм производства блоков конвейера: когда фаза предложения N-го блока заканчивается, начинается предложение блока N+1 (Aptos и другие публичные сети также имеют аналогичную практику). Но для N+1-го блока необходимо дождаться финализации N-го блока, прежде чем он сможет отправить транзакцию финального блока L1 и пройти проверку, чтобы стать финальным блоком.
Возможные размеры атаки: Если секвенсор с наивысшим показателем 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.