• Пересылаю оригинальное название: Исследователь Celestia анализирует 6 вариантов Rollup: Секвенсор=агрегатор+генератор заголовков

Примечание: Для того чтобы модель Rollup было легче понять и проанализировать, исследователь NashQ из Celestia разделил Rollup Sequencer на две логические сущности - Aggregator и Header Producer. В то же время, он разделил процесс заказа сделки на три логических этапа: включение, заказ и исполнение.

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

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

Что такое сворачивание?

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

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

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

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

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

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

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

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

Чтобы облегчить обсуждение, мы разделили секвенсор на две логические сущности: агрегатор и производитель заголовков. Один объект должен знать состояние (т.е. должен выполнить состояние, чтобы вычислить заголовок), но агрегатору не нужно понимать состояние, чтобы уметь его агрегировать.

Секвенирование - это процесс объединения и производства заголовков.

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

Производство заголовков - это процесс создания заголовка рулона.

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

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

Пессимистичный Rollup - это вариант Rollup, который делегирует шаг агрегирования DA-уровню. В нем нет секвенсора. Иногда этот тип сворачивания называют "сворачиванием на основе".

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

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

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

"Чтобы разблокировать web2-эквивалентный UX, общие секвенсоры [...] могут обеспечить быстрые мягкие обязательства (примечание: не очень надежная гарантия). Эти мягкие обязательства обеспечивают некоторое произвольное обещание окончательного упорядочивания транзакций (то есть, они обещают, что порядок транзакций не изменится), и могут использоваться для создания преждевременно обновленных версий состояния (но финализация еще не завершена в это время).

Как только будет подтверждено, что блокдата размещена на базовом слое (s/b относится к DAlayer), состояние можно считать окончательным."

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

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

В этом варианте пользователям Rollup необходимо выполнить, по крайней мере, следующие действия в состоянии минимизации доверия:

Легкий узел DA-Layer + легкий узел общей сети агрегаторов + полный узел Rollup.

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

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

(Поскольку содержание, приведенное выше, относительно неясно, Вы можете прочитать схему еще раз)

Включение - это процесс, в ходе которого транзакция принимается в блокчейн.

Упорядочивание - это процесс расположения транзакций в определенной последовательности в блокчейне.

Исполнение - это процесс, в ходе которого транзакции в блокчейне обрабатываются, а их последствия применяются к состоянию блокчейна.

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

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

Для простоты я буду использовать liveness как булевую величину. Если общий агрегатор не работает, мы не сможем продолжить сворачивание. Если DA-уровень выходит из строя, мы можем продолжить работу с мягкими обязательствами общего агрегатора. Тем не менее, мы будем полагаться на консенсус и доступность данных от общего агрегатора, что будет хуже, чем в оригинальном DA-Layer.

Давайте продолжим исследовать устойчивость к цензуре вышеописанного решения Rollup:

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

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

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

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

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

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

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

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

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

В настоящее время появились некоторые конструктивные решения, снижающие способность узлов сети DA-Layer выполнять такие MEV-транзакции, например, функция "период окна реорганизации", которая задерживает транзакции, подаваемые непосредственно пользователями сети Rollup на DA-Layer. Компания Sovereign Labs подробно описала это в своем проектном предложении под названием Based Sequencing with Soft Confirmations, где предлагается концепция "предпочтительного секвенсора".

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

Что касается быстродействия, то эта конструкция рулонов имеет преимущество перед просто общим агрегатором. Если у общего агрегатора произошел сбой, пользователь все равно может отправлять транзакции на DA-Layer.

Наконец, давайте поговорим о самой маленькой настройке с минимальным уровнем доверия: легкий узел DA-Layer + легкий узел общего агрегатора + полный узел рулонирования.

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

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

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

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

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

Мы используем DA-Layer в качестве агрегатора, унаследовав его устойчивость к цензуре. Он выполняет включение и упорядочивание. Централизованный производитель заголовков будет считывать канонический порядок из DA-Layer и сможет построить на его основе правильный заголовок. Централизованный производитель заголовков отправляет корни заголовков и состояния на DA-Layer. Эти государственные корни необходимы для того, чтобы создать защиту от мошенничества. Агрегатор выполняет включение и упорядочивание, а производитель заголовков - выполнение.

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

Если у производителя заголовков произошел сбой, то у сворачивания также произойдет сбой. Легкий узел не сможет следовать за цепочкой, в то время как полные узлы все еще могут следовать за цепочкой, если это желательно, возвращаясь к пессимистичному свертыванию, как описано в варианте 1. Очевидно, что минимальная конфигурация для минимизации доверия, описанная в варианте 4, такова:

Узел освещения DA-Layer + узел освещения Rollup.

Вариант 5: Основанный ZK-Rollup с децентрализованным рынком доказательств

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

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

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

Наш производитель заголовков в этом дизайне - децентрализованный рынок проверов.

Узлы Prover (полноценные узлы, работающие внутри ZKVM) выполняют примерно тот же процесс, что и полноценные узлы - сканируют блок DA и обрабатывают все партии по порядку - производят доказательства и размещают их в цепочке. (Доказательства должны быть опубликованы в цепочке, если роллап хочет стимулировать проверяющих - в противном случае невозможно определить, какой проверяющий первым обработал ту или иную партию). Как только доказательство для данной партии было размещено в цепочке, партия становится субъективно окончательной для всех узлов, включая легкие узлы.

(Поскольку здесь задействовано много понятий, Вы можете посмотреть на схему еще раз)

Вариант 5 обладает такой же устойчивостью к цензуре, как и DA-Layer. Децентрализованный рынок докатчиков не может цензурировать транзакции, потому что DA-Layer определяет каноническое упорядочивание. Мы децентрализовали производителя заголовков только для повышения оперативности и создания рынка стимулов. Здесь L = L_da && L_pm (рынок проверов). Если стимулы на рынке проверяющих неправильно распределены, или у него произошел сбой, легкие узлы не смогут следовать цепочке, но полные узлы все равно смогут следовать цепочке, если это необходимо, возвращаясь к основанному пессимистическому свертыванию. Наименьшая настройка с минимизацией доверия здесь, как и в оптимистичном случае, состоит из светового узла DA-Layer + светового узла rollup.

Вариант 6: Гибридное свертывание с централизованным производителем оптимистичных заголовков и децентрализованным доказательством

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

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

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

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

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

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

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

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

Наименьшая установка с минимальным уровнем доверия - это узел DA-Layer + узел rollup.

Резюме:

1. Мы разделили секвенсор на две логические единицы: агрегатор и производитель заголовков.

2. Мы разделили секвенсор на три логических процесса: включение, упорядочивание и выполнение.

3. Пессимистичные сворачивания и основанные сворачивания - это вещь.

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

5. Каждый вариант Rollup в этой статье соответствует этому шаблону дизайна:
   

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

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

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

1. Эта статья перепечатана с сайта[Geek Web3], Forward the Original Title'Исследователь Celestia анализирует 6 вариантов Rollup: Sequencer = aggregator + Header generator',Все авторские права принадлежат оригинальному автору[NashQ, Celestia Researcher]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.