• Переслать оригинал названия：Децентрализация сворачивания: Анализ децентрализованного решения 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 Tokens может быть достойная токеномическая модель.

7. Как блок L2, так и данные транзакций распространяются в p2p-сети L2.

8. L2 наследует безопасность L1.

(Предложение B52 предполагает структуру Rollup, а предлагающий - это, по сути, Sequencer)

В этом плане весь процесс производства блоков L2 разделен на три временных этапа:

Окно предложения блока (BPW) Окно принятия блока (BAW) Государственные авансы

Среди них этап BPW (Block Proposal) - это процесс, на котором несколько Sequencers предлагают различные блоки и соревнуются, а Prover выбирает блок-кандидат для голосования. BAW (Block Acceptance) - это процесс, в котором Prover строит доказательство валидности для блока и отправляет его. Окно блочного предложения (фаза блочного предложения): BPW можно разделить на три этапа - предложение блока, голосование за блок, агрегирование.

(Блок-схема процесса окна предложения)

Стадия блокчейн-предложений (BP): любой участник стадии может собирать транзакции и транслировать свой собственный контент BP. Содержимое BP будет включать три части: хэш заказа txs, процент вознаграждения провера, количество сгорающих токенов.

хэш порядка txs: Предлагающий выбирает наиболее ценную партию транзакций из пула транзакций L2 (mempool), сортирует их, а затем помещает хэш-значение этих транзакций в создаваемый блок. prover reward percentage: Процент вознаграждения за блок, которым Секвенсор делится с Проверяющим. количество сжигаемых токенов: Количество L2 Native Tokens, которое предлагает сжечь предлагающий, после чего он отправит свои BP в p2p-сеть L2.

Этап блочного голосования:

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

Vote={BlockHash, Index of Proof Tree}

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

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

Здесь необходимо подчеркнуть обязательное условие для того, чтобы ВР были выбраны и включены в бухгалтерскую книгу Rollp:

Набрав наибольшее количество очков:

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

NUM_PROVERS (x) - это количество голосов Prover, которые получил данный BP, а BURN_BID - это количество жетонов L2, которые предлагается сжечь этим BP. Чем выше BURN_BID, тем меньшее вознаграждение в итоге получит участник BP, поэтому это значение должно быть установлено соответствующим образом.

В то же время, этот БП должен быть подан в L1 до окончания Окна предложения блока, а соответствующее доказательство действительности Proof должно быть загружено в L1 до окончания Окна принятия блока.

Примечание: При подсчете очков ВР наибольший вес имеет количество голосов, за которым следует количество жетонов ожогов. В то же время, схема B52 позволяет нескольким пропперам (фактически, секвенсорам) конкурировать за действительную квоту BP.

Схема B52 требует от предлагающего (секвенсора) только указать количество сгораемых токенов в своем ВР (аналогично методу EIP1559), без необходимости заранее ставить токены на кон, что может сделать сеть более свободной от разрешений (без разрешения на вход), а также способствует "родной" дефляции токенов в L2.

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

Подробное объяснение Окна принятия блока:

(Схема окна приемки блока, на рисунке написано как Proof Acceptance)

После того, как окно предложения блока закончится, Prover должен раскрыть все данные транзакции, соответствующие его BP. Если выбран ВР, за который проголосовал Доказатель (имеющий наивысший балл, который можно запросить через контракт L1), ему необходимо построить Поддерево Доказательств, соответствующее Индексу Дерева Доказательств, указанному при голосовании.

Предположим, что блок Aztec содержит 2^13=16384 транзакций, и существует 2048 проверяющих, тогда каждый проверяющий строит дерево поддоказательств, состоящее из 2^3=8 транзакций. Затем доказывающий передает построенное им дерево поддоказательств в сеть L2 p2p. Получив его, автор предложения объединит все поддеревья доказательств в блочное доказательство.

Затем Propsoer отправит агрегированное доказательство контракту L1 Rollup, который проверит правильность этого доказательства и соответствующие результаты перехода состояний. Здесь следует отметить, что если Prover намеренно не предоставит доказательство, он не только не получит дивиденды в виде вознаграждения за блок, обещанные Proposer'ом, но и будет урезан, поскольку для того, чтобы стать Prover'ом, необходимо заранее поставить токены на кон. Поэтому, в отличие от предлагающего (Sequencer), доказывающий не является безразрешительным.

Подробное объяснение государственных авансов:

После окончания окна приема блоков контракт Rollup выберет блок с наивысшей оценкой, который будет включен в бухгалтерскую книгу Rollup, а вознаграждение за блок будет отправлено Предложившему (Sequencer) и Проверяющему в пропорции, ранее объявленной Предложившим.

Выше показана схема B52 от Aztec. Однако автор этой статьи считает, что у предложения B52 есть несколько потенциальных проблем:

Задача 1: Предположим, что доказательство истинности блока с наивысшим баллом неполное. Решение, предложенное в предложении, заключается в том, что если предлагающий предоставляет только 50% доказательства, то он может получить только 50% вознаграждения за блок, тем самым гарантируя, что у предлагающего не будет стимула намеренно не предоставлять полное доказательство. В то же время, Доказатель также может напрямую передать доказательство в контракт.

Согласно описанию предложения, допустимо, чтобы блок не имел полного доказательства действительности транзакции. На самом деле это неразумно, потому что: zkrollup объявляет новое состояние, соответствующее этому блоку, действительным только тогда, когда дано доказательство действительности.

Если в совокупном доказательстве, которое предлагающий в конечном итоге отправляет в L1, отсутствует доказательство определенной транзакции, очевидно, что доказательство перехода состояния всех транзакций, которые происходят после этой транзакции, недействительно (поскольку транзакции выполняются последовательно и имеют зависимости от состояния), и мы не можем подтвердить, что новое состояние, соответствующее этому блоку, действительно.

Поэтому на данный момент разумным решением будет войти в окно бесконечного ожидания принятия блока до тех пор, пока не будут представлены все доказательства транзакций.

Задача 2: Предположим, что блок, набравший наибольшее количество очков, является нелегальным блоком (этот момент не объясняется в плане B52). ВР содержит только хэш последовательности транзакций, поэтому злоумышленник может намеренно создавать проблемные транзакции, например, транзакции с двойным расходом. На данный момент действительно необходимо добавить в контракт L1 функцию, позволяющую любому человеку представить незаконное доказательство. Это незаконное доказательство используется для того, чтобы доказать, что ВР, набравший наибольшее количество очков, является незаконным блоком.

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

Интересная мысль: О "дядиных блоках" и избыточной работе доказателей: План B52 на самом деле будет после каждого раунда, когда появляется самый высокий и валидный ВР, рассматривать другие ВР (которые представили полные доказательства) в этом раунде как дядины блоки и распределять определённое количество вознаграждений за дядины блоки.

Это фактически соответствует практике механизма консенсуса ETH POW. Чтобы избежать чрезмерной концентрации вычислительных мощностей, необходимо выделять часть вознаграждения за блок тем, кто предлагает блоки, которые не были приняты (майнерам), чтобы защитить интересы небольших майнинговых пулов/индивидуальных майнеров и предотвратить монополизацию майнинговых мощностей крупными майнинговыми пулами. Поэтому принятие хорошо зарекомендовавшего себя механизма дяди-блока в Ethereum - это также очень разумный выбор.

Значение предложения B52 с точки зрения децентрализации Rollup: Предложение децентрализовано и не требует залога, а входной барьер низок. Однако, поскольку для этого требуется самостоятельно создать самый ценный блок, а также собрать голоса других Провокаторов и агрегировать все Доказательства, аппаратный порог Провокатора не так низок, как описано в предложении (например, пропускная способность может быть не очень низкой).

Поэтому, в конечном счете, эта сеть станет более централизованной, подобно Mev-Boost Builder, поскольку тот, кто предлагает блок, в конечном счете, часто является тем блокчейн-строителем, который лучше всех умеет собирать MEV.

В то же время, Prover в схеме B52 должен закладывать активы, но поскольку ему нужно генерировать только доказательство поддерева, по сравнению с теми решениями, где нужно полностью генерировать доказательство всего блока, степень децентрализации Prover будет лучше (требования к аппаратному обеспечению могут быть снижены).

Liveness: Общая Liveness сети хорошая, потому что у L2 есть своя p2p-сеть для трансляции транзакций и голосования/BP, а Sequencer и Prover относительно децентрализованы. Но нам нужно решить две проблемы, упомянутые выше: первая заключается в том, что блок, набравший наибольшее количество очков, должен быть легальным блоком, а вторая - в том, что перед входом в новое состояние нам нужно дождаться полного доказательства блока, которое будет передано в L1. Поэтому необходим более эффективный механизм стимулирования, чтобы вся сеть Rollup не перестала нормально работать (остановилась) из-за отсутствия некоторых доказательств tx.

Устойчивость к цензуре: Если мы сможем гарантировать, что любой человек может публиковать блокчейн-предложения BP, и гарантировать, что не только предлагающий может представить блокчейн-доказательство, то сеть будет обладать хорошей устойчивостью к цензуре.

Окончательность: Окончательность L2 тесно связана с быстродействием сети, поскольку для окончательной проверки окончательности еще нужно дождаться представления Block Proof, но на самом деле Вы можете доверять и содержимому блока, соответствующего наибольшему количеству BP (при условии, что он не содержит вредоносных транзакций).

Этот блок будет раскрыт в начале окна принятия блока, а это значит, что Вам, как пользователю, нужно только дождаться времени окна предложения блока, и блок, в котором находится Ваша транзакция, может быть принят.

Наследуйте безопасность L1: Как L2, который обновляет состояние, предоставляя доказательства действительности, он может унаследовать безопасность L1.

Предложение Fernet: Внедрение VDF для отбора предложений

Обзор схемы Ферне: Используя VDF в каждом цикле генерации блоков, прогнозируемая оценка присваивается различным узлам в Комитете (совокупность узлов Секвенсора), и блок, предложенный Секвенсором с наибольшей итоговой оценкой, становится действительным блоком.

Во-первых, как стать членом Комитета? По сути, для этого необходимо сделать ставку в 16 ETH на L1, а затем, после завершения процесса стакинга, подождать 4 блока L1, прежде чем присоединиться к Комитету секвенсоров. Что касается выхода из комитета Sequencer, то необходимо вызвать функцию Unstake в контракте L1, после чего потребуется 3 дня, чтобы получить оставшуюся сумму ставки.

Далее, что такое VDF? Verifiable Delay Function - это математическая функция, которая придерживается строгих характеристик последовательного выполнения. Он выполняет определенные вычислительные шаги и затрачивает предсказуемое количество времени. Мы обозначаем значение, рассчитанное с помощью VDF, как Score, которое соответствует равномерному нормальному распределению. Таким образом, как только Последователь вычислит VDF Score, он сможет определить вероятность того, что его выберут в качестве легитимного Предложения.

Расчет VDF для Sequencer производится следующим образом:

Score = VDF( privatekey , public inputs )

public inputs = { current block number , randao }

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

Весь процесс изготовления Фернета в основном делится на три этапа:

1. Фаза предложения 2. Фаза доказательства 3. Завершение

Фаза предложения: PROPOSAL_PHASE_L1_BLOCKS = 2 блока Ethereum (Эта фаза будет длиться в течение 2 блоков L1)

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

непроверенный блок: Блок, который только подал предложение на содержание блока контракта Rollup. Затем секвенсор должен отправить содержимое блока, соответствующее недоказанному блоку, и доказательство VDF в сеть L2 p2p.

Фаза доказательства: PROVING_PHASE_L1_BLOCKS= 50 блоков L1 (Эта фаза будет длиться 50 блоков L1, около 10 минут)

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

Поэтому секвенсору необходимо окончательно объединить доказательства множества различных транзакций в блочное доказательство (включая VDF-доказательство) и отправить его контракту L1 Rollup. Любой человек может представить содержимое блока, который уже представил доказательство блока в контракте Rollup.

Финализация: Для финализации блока необходимо отправить транзакцию L1, блок, который может быть окончательно финализирован, должен соответствовать: представленному содержимому блока и доказательству блока, предыдущий блок, на который он указывает, должен быть финализирован. Исходя из этого, он также должен иметь наивысший балл.

(В процессе блокировки в стиле конвейера, как только заканчивается этап предложения предыдущего блока, начинается этап предложения следующего блока, не дожидаясь окончания этапа доказательства предыдущего блока).

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

Потенциальные векторы атаки: Если секвенсор с наивысшим VDF Score намеренно не передает содержимое блока в L2 p2p, это может привести к реорганизации блока (reorg).

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

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

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

Liveness: Liveness сети в целом может быть гарантирована, поскольку механизм VDF + нечеткий блокчейн может гарантировать, что в каждом раунде будет более одного производителя блоков.

MEV: Рассмотрение MEV является особенно уникальным. В этой схеме планируется внедрить PBS, так что после того, как Секвенсор вычислит высокий балл VDF Score, он сможет напрямую обратиться к Конструктору блоков, чтобы построить более ценный блок.

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

Отказ от ответственности：

1. Эта статья перепечатана с сайта[Geek Web3], Forward the Original Title 'ollup Decentralization: Анализ децентрализованного секвенсорного решения Aztec',Все авторские права принадлежат оригинальному автору[xhhh，EthStorage]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.