Автор: NashQ, исследователь Celestia; компилятор: Faust, Geek Web3

Примечание переводчика: чтобы упростить понимание и анализ модели Rollup, исследователь Celestia NashQ разделил секвенсор Rollup (Sequencer) на две логические сущности — агрегатор и генератор заголовков. При этом он разделил процесс упорядочения транзакций на три логических этапа: включение, упорядочение и выполнение.

Благодаря этому аналитическому мышлению шесть важных вариантов суверенного свертывания становятся более четкими и понятными. NashQ подробно обсудил устойчивость к цензуре и активность различных вариантов Rollup, а также обсудил минимальную конфигурацию узла каждого варианта Rollup в состоянии с минимальным доверием (то есть для достижения состояния Trustless какие типы пользователей Rollup должны запускать как минимум узел).

Хотя в этой статье Rollup анализируется с точки зрения Celestia, что отличается от того, как сообщество Ethereum анализирует модель Rollup, учитывая множество взаимосвязей между Ethereum Rollup и суверенным Rollup Celestia, а также растущее влияние последнего, это важно для Энтузиастам Ethereum, эту статью также стоит прочитать.

Что такое накопительный пакет?

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

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

Блок Rollup — это структура данных, представляющая реестр блокчейна на определенной высоте блока. Блок свертки состоит из данных сводки и заголовка свертки. Среди них данные Rollup могут представлять собой пакет транзакций или изменения состояния между пакетами транзакций.

Вариант 1: Пессимистическое сведение/сведение на основе

Самый простой способ создать накопительный пакет — позволить пользователям публиковать транзакции в другом блокчейне, который мы будем называть уровнем консенсуса и доступности данных (DA-Layer), а далее я буду называть его просто DA-уровнем (Примечание переводчика: Это похоже на уровень 1, о котором часто говорят в сообществе Ethereum).

В первом варианте Rollup, который я собираюсь представить, узлы сети Rollup должны повторно выполнить транзакции Rollup, содержащиеся на уровне DA, чтобы проверить окончательное состояние реестра. Это пессимистичный Rollup!

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

Но в этом случае кто выступает в роли секвенсора накопительного пакета? На самом деле, за исключением полных узлов Rollup, ни одна организация никогда не выполняла транзакции, содержащиеся в реестре Rollup. Вообще говоря, секвенсор агрегирует данные транзакции и генерирует заголовок Rollup. Но упомянутый выше пессимистичный Rollup не имеет заголовка Rollup!

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

Последовательность сортировки — это процесс «объединения + создания сводного заголовка».

Агрегация — это этап объединения данных транзакции в пакет. Пакет обычно содержит много транзакций (Примечание переводчика: пакет — это часть данных в блоке свертки, отличная от заголовка).

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

С этой точки зрения видно, кто отвечает за каждую часть Rollup. Сначала посмотрите на часть агрегатора Aggregator. Вышеупомянутый пессимистичный Rollup не имеет процесса генерации заголовков, и пользователи публикуют транзакции непосредственно на уровне DA, что означает, что сеть уровня DA по существу действует как агрегатор.

Следовательно, пессимистичный Rollup — это вариант Rollup, который делегирует этап агрегации уровню DA, у которого нет секвенсора Sequencer. Иногда этот тип объединения называется «на основе объединения».

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

Вариант 2: Пессимистичная агрегация с использованием общего агрегатора

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

«Чтобы добиться взаимодействия с пользователем, эквивалентного Web2, общий секвенсор может обеспечить быстрое создание Soft Commitments (не очень надежные гарантии). Эти Soft Commitments предоставляют некоторые гарантии в отношении окончательного порядка транзакции (то есть порядок транзакции обязательств не Изменить), а шаг обновления статуса сводной книги может быть выполнен заранее (но на данный момент завершение еще не завершено).

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

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

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

В этом варианте пользователям Rollup необходимо как минимум запустить легкие узлы уровня DA + легкие узлы общей сети агрегатора + полные узлы Rollup в состоянии с минимальным доверием.

На этом этапе опубликованный заголовок агрегатора (а не заголовок сведения здесь) должен быть проверен легкими узлами, совместно использующими сеть агрегатора. Как упоминалось выше, общий агрегатор берет на себя работу по сортировке транзакций.Он содержит криптографическое обязательство в опубликованном заголовке агрегатора, соответствующее пакету, который он выпустил на уровне DA.

Таким образом, оператор узла объединения может подтвердить, что пакетный пакет, полученный от уровня DA, был создан общим агрегатором, а не другими.

• Включение — это процесс включения транзакций в блокчейн.
• Сортировка Упорядочивание относится к процессу упорядочивания транзакций в блокчейне в определенном порядке.
• Исполнение относится к процессу обработки транзакций в блокчейне и завершению обновлений статуса.

Поскольку общий агрегатор заботится о включении и сортировке, от него зависит устойчивость Rollup к цензуре.

Если предполагается, что L_ss — это активность общего агрегатора, а L_da — это активность уровня DA, тогда активность модели свертки L = L_da && L_ss. Другими словами, если какая-либо из двух частей имеет сбой живучести, накопительный пакет также имеет сбой живучести.

Для простоты я буду рассматривать живучесть как логическое значение. Если общий агрегатор выйдет из строя, Rollup не сможет продолжать работу. Если сеть уровня DA выходит из строя, общий агрегатор может продолжать предоставлять Soft Commitment для блоков Rollup. Но в это время атрибуты Rollup будут полностью зависеть от общей сети агрегатора, а атрибуты последнего часто намного уступают исходному уровню DA.

Давайте перейдем к изучению цензуроустойчивости приведенной выше схемы Rollup:

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

Однако, согласно рабочему процессу свертки, когда общий агрегатор отправляет пакет транзакций на уровень DA, он уже завершил сортировку транзакций, а также был определен порядок между различными пакетами. Таким образом, такой просмотр транзакций на уровне DA не имеет никакого другого эффекта, кроме задержки окончательного подтверждения реестра Rollup.

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

Вариант 3: Пессимистическая сводка на основе сводки на основе и общего агрегатора

Хотя общий агрегатор приносит пользу пользователям и сообществу, мы должны избегать чрезмерной зависимости от него и позволять пользователям выходить из общего агрегатора на уровень DA. Мы можем объединить два варианта Rollup, представленных ранее, позволяя пользователям отправлять транзакции непосредственно на уровень DA при использовании общего агрегатора.

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

Агрегация здесь разделена на два этапа. Во-первых, в игру вступает общий агрегатор, агрегирующий некоторые транзакции. Затем уровень DA может агрегировать пакет, отправленный общим агрегатором, и транзакции, отправленные непосредственно пользователем.

Анализ устойчивости к цензуре на этом этапе немного сложнее. Сетевые узлы уровня DA могут просмотреть пакет, представленный общим агрегатором, до того, как будет создан следующий блок уровня DA.После того, как будут известны данные транзакции в пакете, узлы уровня DA могут извлечь значение MEV и сначала использовать себя в сводном пакете. network Учетная запись инициирует предварительную транзакцию и сначала включает ее в блок уровня DA, а затем включает пакет, отправленный общим агрегатором Rollup.

Очевидно, что окончательность порядка транзакции, гарантированная мягким обязательством третьего типа варианта Rollup, является более хрупкой, чем вышеупомянутый второй тип варианта Rollup. В этом случае общий агрегатор передал значение MEV узлам уровня DA. В связи с этим рекомендую читателям посмотреть научную лекцию об эксплуатации прибыльных цензурированных MEV.

В настоящее время появились некоторые схемы проектирования, чтобы уменьшить способность сетевых узлов уровня DA выполнять такие транзакции MEV, такие как функция «периода окна реорганизации», которая задерживает выполнение транзакций, отправленных непосредственно на уровень DA пользователями сети Rollup. . Sovereign Labs подробно описывает это в своем предложении по проектированию под названием «Основное секвенирование с программными подтверждениями», которое вводит концепцию «предпочтительного секвенсора».

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

Что касается живучести, эта схема объединения имеет преимущества по сравнению со схемами, которые позволяют только общим агрегаторам отправлять транзакции на уровень DA. В случае сбоя работоспособности на общем агрегаторе пользователи по-прежнему могут отправлять транзакции на уровень DA.

Наконец, давайте поговорим о минимальной конфигурации пользователей Rollup при минимизации доверия:

По крайней мере, запустите легкий узел уровня DA + легкий узел общего агрегатора + полный узел Rollup.

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

Вариант 4: Объединение на основе оптимизма и централизованный генератор заголовков

Давайте обсудим вариант под названием «Основное оптимистическое сведение» и централизованный генератор заголовков. Это решение использует уровень DA для агрегирования транзакций Rollup, но вводит централизованный генератор заголовков для создания заголовков Rollup для включения легких узлов Rollup.

Упрощенные узлы Rollup могут косвенно проверять действительность транзакций Rollup с помощью одного раунда доказательства мошенничества. Легкий узел будет с оптимизмом смотреть на генератор сводного заголовка и сделает окончательное подтверждение после окончания периода окна защиты от мошенничества. Другая возможность заключается в том, что он получает доказательство мошенничества от честного полного узла о том, что генератор заголовков отправил ошибочные данные.

Я не буду вдаваться в подробности того, как работает однораундовое доказательство мошенничества, так как это выходит за рамки данной статьи. Преимущество одного раунда доказательства мошенничества заключается в том, что он может в определенной степени сократить период окна доказательства мошенничества с дней 7. Конкретное значение еще предстоит определить, но порядок величины меньше, чем при традиционном оптимистическом свертывании. Легкие узлы могут получать доказательства мошенничества через сеть P2P, состоящую из полных узлов Rollup, не дожидаясь последующего процесса оспаривания, поскольку все критерии полностью представлены в одном доказательстве мошенничества.

Вышеупомянутая модель Rollup использует уровень DA в качестве агрегатора и наследует его устойчивость к цензуре. На этом этапе уровень DA отвечает за содержание и упорядочивание транзакций. Централизованный генератор заголовков будет считывать последовательность транзакций свертки с уровня DA и соответствующим образом строить соответствующий заголовок сводки. Генератор заголовков опубликует заголовок и Stateroot на уровне DA. Эти Stateroots необходимы при создании доказательств мошенничества. Короче говоря, агрегатор отвечает за включение и сортировку транзакций, а генератор заголовков выполнит транзакцию для обновления состояния для получения Stateroot.

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

Если генератор заголовков перестанет работать, свертывание также не подведет. Легкие узлы не смогут следить за ходом сводного реестра, но полные узлы могут. В этот момент накопительный пакет, описанный в варианте 4, вырождается в базовый накопительный пакет, описанный в варианте 1. По-видимому, минимальная конфигурация с минимизированным доверием, описанная в Варианте 4, такова:

Световой узел слоя DA + световой узел Rollup.

Вариант 5: ZK-Rollup и децентрализованный пруверный рынок

Мы обсудили пессимистический накопитель (основной накопительный пакет) и оптимистичный накопительный пакет, теперь пришло время рассмотреть ZK-накопительный пакет. Недавно Тогрул выступил с речью о разделении агрегатора (Sequencer) и генератора заголовков (Prover) (разделение Sequencer-Prover в накопительных пакетах с нулевым разглашением). В этой модели проще обрабатывать транзакции публикации как данные Rollup, а не State Diff, поэтому я сосредоточусь на первом. Вариант 5 — децентрализованный Prover Market на основе zk-rollup.

К настоящему времени вы должны быть знакомы с тем, как работает Rollup. Вариант 5 делегирует роль агрегатора узлам уровня DA, которые выполняют работу по включению и сортировке транзакций. Я процитирую документацию Sovereign-Labs, в которой хорошо объясняется жизненный цикл транзакции в варианте 5:

Пользователь публикует новый блок данных в цепочке L1 (уровень DA). Как только эти блоки данных будут завершены в цепочке L1, они станут логически окончательными (неизменяемыми). После того, как блоки L1-цепочки перейдут в стадию финализации (то есть их нельзя будет откатить), полные узлы Rollup просканируют эти блоки, обработают по порядку все блоки данных, относящиеся к Rollup, и сгенерируют последний корень состояния Rollup Stateroot . На данный момент, с точки зрения полных узлов Rollup, эти блоки данных завершены.

В этой модели генератором заголовков выступает децентрализованный рынок пруверов.

Рабочий процесс узла Prover Prover (полный узел, работающий в ZKVM) аналогичен рабочему процессу обычного полного узла Rollup — сканирование блокчейна уровня DA и обработка всех пакетов транзакций Rollup для создания соответствующего доказательства с нулевым разглашением и публикации. это в цепочке слоев DA. (Если система Rollup хочет мотивировать доказывающего, последний должен отправить сгенерированное доказательство ZK в цепочку уровней DA, иначе будет невозможно определить, какой доказывающий представил доказательство ZK первым). Как только доказательство ZK, соответствующее определенному пакету транзакций, выпускается в цепочку, пакет транзакций завершается в глазах всех узлов объединения (включая легкие узлы).

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

Активность здесь L = L_da && L_pm (активность доказывающего). Если стимулы Prover Market несовместимы или есть активный сбой, легкий узел Rollup не сможет синхронизировать ход блокчейна, а полный узел Rollup может.Для полного узла это просто запасной вариант. к базовому свертыванию/пессимистичному свертыванию. Минимальная конфигурация для минимизации доверия здесь такая же, как и в случае с оптимистичным Rollup, а именно

Световой узел слоя DA + световой узел Rollup.

Вариант 6: Объединение на гибридной основе + Централизованный генератор оптимистичных заголовков + Децентрализованный прувер

Мы по-прежнему позволяем узлам уровня DA действовать как агрегаторы Rollup и делегируем им работу по включению и упорядочению транзакций.

Как видно из рисунка ниже, и ZK Rollup, и Optimistic Rollup используют один и тот же упорядоченный пакет транзакций на уровне DA в качестве источника реестра Rollup. По этой причине мы можем использовать обе системы подтверждения одновременно: упорядоченный пакет транзакций на уровне DA сам по себе не зависит от системы подтверждения.

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

Как и в предыдущем варианте 4, легкий узел будет оптимистично доверять генератору заголовков, полагать, что выданный им заголовок верен, и ждать подтверждения мошенничества от сети с полным узлом. Если период окна доказательства мошенничества закончился, а сеть с полным узлом не выдала доказательство мошенничества, с точки зрения легкого узла свертки блок свертки завершается.

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

Когда легкие узлы получают подтверждение ZK для пакета транзакций Rollup, пакет завершается.

Теперь у нас есть быстрая Soft Commitment и быстрая финализация.

Вариант 6 по-прежнему обладает такой же устойчивостью к цензуре, как и уровень DA, поскольку он основан на слое DA. Для живости у нас будет L = L_da && (L_op || L_pm), а значит добавляем гарантии живучести. Если централизованный генератор заголовков или децентрализованный Prover Market терпит неудачу, мы можем перейти к другому из двух.

В этом варианте минимальная конфигурация для минимизации доверия пользователей:

Один световой узел слоя DA + один световой узел Rollup.

Краткое содержание:

1. Разделяем ключевую роль Rollup - Sequencer на две логические составляющие:

Агрегаторы и генераторы заголовков.

2. Делим работу Sequencer на три логических процесса: сдерживание, сортировка и исполнение.

3. Пессимистическое сведение и сведение на основе — это одно и то же.

4. В соответствии с вашими потребностями вы можете выбрать различные агрегаторы и генераторы заголовков.

5. Каждый вариант накопительного пакета, представленный в этом посте, следует одному и тому же шаблону проектирования:

Наконец, у меня есть некоторые мысли. Пожалуйста, подумайте о:

• Как классический накопительный пакет (имеющий в виду Ethereum накопительный пакет) классифицируется по вышеперечисленным вариантам?
• Во всех вариантах мы позволяем агрегатору отвечать только за включение + сортировку, а генератор заголовков выполнять транзакцию. Что, если агрегатор отвечает только за включение транзакций, а генератор заголовков отвечает за упорядочивание и выполнение транзакций? Учитывая введение этапа ончейн-аукциона, можем ли мы полностью разделить эти три этапа?
• Что такое общий производитель заголовков/рынок производителей заголовков?
• Кто фиксирует значение MEV? Может ли пользователь вернуть его?