Celestia Researcher: интерпретация 4 новых схем объединения

Автор: NashQ, Celestia; Компилятор: Ссылка, "Geek web3"

Введение: Эта статья состоит из разрозненных выступлений исследователя Celestia NashQ об анализе модели Rollup, включая 4 новых варианта Rollup. Ранее, в статье «Анализ Rollup с точки зрения Celestia: устойчивость к цензуре и активность 6 вариаций», он перечислил 6 различных моделей Rollup, а эта статья — его новые абстрагированные 4 категории, основанные на этой модели Rollup.

Ранее NashQ разделил Sequencer на два модуля: агрегатор + производитель заголовков, Начав с жизненного цикла инструкций по транзакциям, он объяснил принцип работы суверенного Rollup Celestia, обсудил антицензуру и активность различных вариантов Rollup, а также пользовательский опыт. , Минимальная конфигурация с учетом минимизации доверия (то есть для достижения Trustless, какие типы узлов пользователи Rollup должны запускать по крайней мере).

Вариант 7: Объединение на основе + несколько производителей заголовков + «максимальный протокол MEV»

В этом варианте Rollup пользователи сети Rollup напрямую публикуют данные транзакций в блоки уровня DA, а затем Header Producer отвечает за сортировку транзакций, и MEV извлекается им. Очевидно, что процесс агрегации/включения транзакций в варианте сводки 7 такой же, как ранее представленный процесс объединения на основе, за который отвечает уровень DA (пользователи напрямую отправляют транзакции на уровень DA), но порядок транзакций отличается от порядка транзакций на основе. Объединение и узлы уровня DA не несут ответственности. За сортировку отвечает компания HP (производитель заголовков).

Далее предполагается, что есть три HP, которые конкурируют друг с другом и соблюдают протокол распределения MEV, называемый «максимальным протоколом MEV». Этот протокол был предложен Skip Protocol экосистемы Cosmos.В отличие от схемы Ethereum PBS, Block Builder должен платить дополнительную «чаевые» валидатору сети блокчейна, и блок, построенный Builder с наибольшим количеством чаевых, будет принят. от валидаторов. В то же время протокол SKIP предложил концепцию «суверенного MEV», намереваясь позволить всем валидаторам и сообществам в публичной сети иметь автономию для распределения MEV и решить проблему, с которой Builders в Ethereum PBS становится все больше и больше. более централизованным из-за эффекта маховика (но это не основная тема данной статьи).

В варианте сводки, представленном в этой статье, разные производители заголовков должны объявить сумму чаевых в заголовке партии, созданном ими самими, а заголовок партии, выпущенный HP, который платит больше всего чаевых, автоматически принимается узлами сводки (через реестр). прописан в коде узла. Алгоритм выбора форка выполняется автоматически).

Кроме того, заголовок пакета, выпущенный HP, должен соответствовать полному пакету транзакции на уровне DA.

Если в Заголовке, выдаваемом HP, есть ошибка, например, результат выполнения транзакции Stateroot неверный, или транзакция в пакете не включена (потерянная транзакция), честный полный узел Rollup будет транслировать Fraud proof на легкий узел . Но обычно (оптимистично) легкие узлы могут принять Заголовок, выданный HP, и считать, что с ним нет проблем.

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

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

**Активность:**L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

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

Вариант 8: ZK Rollup общего агрегатора + децентрализованный прувер

Вариант 8 использует общий агрегатор Shared Aggregator (SA) для включения и сортировки транзакций.SA публикует последовательность транзакций Batch на уровне DA.После отправки последовательности транзакций на уровень DA порядок транзакций теоретически не изменится.

Прежде чем пакет будет отправлен на уровень DA, SA-агрегатор общего доступа может сначала передать заголовок SA Batch+ SA полному узлу и доказывающему устройству, а затем передать заголовок SA легкому узлу, но пакет, который не находится на уровне DA, в настоящее время все еще нестабилен и может быть заблокирован в любое время.

Следует отметить, что заголовок, выдаваемый SA-агрегатором общего доступа, не совпадает с заголовком пакета, выдаваемым HP. Заголовок SA содержит криптографические доказательства, гарантирующие, что Пакет, считанный узлом Rollup с уровня DA, действительно сгенерирован SA, а не подделан кем-то другим.

Prover считывает пакет транзакций с уровня DA (он также может быть напрямую синхронизирован с общим агрегатором), генерирует ZK Proof+Batch Header и публикует его на уровне DA. Очевидно, Prover играл роль HP.

Для легких узлов Rollup после получения ZKProof последовательность транзакций, содержащаяся в этом пакете, окончательно подтверждается. Конечно, Prover также может транслировать ZKP через p2p-сеть Rollup под цепочкой уровня DA, чтобы его можно было быстрее получить легкими узлами, но в настоящее время ZKP не отправлен на уровень DA, и у него нет " окончательность».

• **Устойчивость к цензуре: **В варианте 8 уровень DA не может проводить цензурные атаки на определенные конкретные транзакции, но может проводить атаки с обзором всего пакета транзакций, представленных общим агрегатором. В то же время общие агрегаторы могут отказать в пакетировании транзакций определенных пользователей.
• **Активность: **L = L_da && L_sa && L_pm. В этом варианте, если какая-либо часть имеет сбой живучести, накопительный пакет будет иметь сбой живучести. Если Prover выйдет из строя, легкие узлы не смогут эффективно синхронизировать ход сводной книги. Однако, поскольку полный узел синхронизирует все пакеты последовательности транзакций, он может идти в ногу с прогрессом реестра. В это время все узлы не будут затронуты, и все легкие узлы выйдут из строя, что эквивалентно ситуации с базовым сведением с использованием общего агрегатора, представленного ранее.
• ** Минимальная конфигурация для минимизации доверия: ** Легкий узел уровня DA + Легкий узел общей сети агрегатора + Легкий узел объединения

Вариант 9: Общий агрегатор + децентрализованный Prover + ZK-Rollup с несколькими DA

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

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

Здесь мы выбираем тот же децентрализованный Prover Market, что и вариант 8, где Prover выступает в роли производителя заголовков и выпускает пакетный заголовок и ZKProof. На этом этапе доказывающему необходимо конкурировать через механизм аукциона чаевых, упомянутый в Варианте 7 (предложенный протоколом SKIP).

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

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

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

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

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

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

Вариант 10: два ZK-роллапа+децентрализованный прувер с легким узлом в цепочке (с возможностью моста) между собой

Вариант 10 является расширением Варианта 5 для создания 2 ZK-роллапов, которые могут соединяться друг с другом. По сравнению с Вариантом 5 (Сведение на основе + ZKP + Децентрализованная проверка), Вариант 10 имеет дополнительную роль ретранслятора, которая включает пакетный заголовок + ZK-Proof в транзакцию. Пока эта транзакция отправляется на легкий узел Rollup1, работающий на Rollup2, она может подтвердить, что определенная высота пакета действительна. Конечно, для Rollup2 также требуются легкие узлы, на которых работает уровень DA.

Это обязательное условие для того, чтобы свести к минимуму доверие между цепными мостами. Но если это кроссчейн от Ethereum Rollup (на основе смарт-контрактов SC Rollup) до Ethereum, нет необходимости запускать легкий узел уровня DA Rollup, потому что уровень DA — это сам Ethereum. Это очень отличается от суверенного Rollup Celestia, чьи Rollup охватывают друг друга и должны запускать легкие узлы уровня DA другой стороны.

Когда Relayer отправляет транзакцию между цепочками, она будет обработана агрегатором 2 Rollup2 и HP2. Мы добавляем оба на график, чтобы понять, как узлы Rollup2 обрабатывают транзакции между Rollup.

Relayer из Rollup2 получит заголовок пакета и ZKP из Rollup 2 и отправит их обратно в Rollup1. Сводка 1 также имеет световой узел Свертки 2 и световой узел слоя DA.

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

В этом случае Relayer может быть забанен напрямую. Поскольку заголовки пакетов и ZK Proof были опубликованы HP на одном и том же уровне DA, такие данные, как заголовок и ZKP другого сводного пакета, можно считывать непосредственно на уровне DA, и их больше не нужно передавать на общий агрегатор через ретранслятор.

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

В настоящее время ** минимальная конфигурация минимизации доверия: ** легкий узел уровня DA + легкий узел свертки.