Введение: Эта статья объединяет рассыпанные заявления исследователя Celestia NashQ о анализе модели Rollup, включая 4 новых варианта Rollup. Ранее, в статье " Исследователь Celestia анализирует 6 вариантов Rollup: Sequencer=Aggregator+Header GeneratorОн перечислил 6 различных моделей Rollup, и эту статью можно рассматривать как новую абстракцию 4 типов моделей Rollup на основе этой статьи.

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

Вариант 7: Основанная на Rollup + Несколько производителей заголовков + “наивысший протокол MEV”

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

Предположим, что существуют три HP, которые конкурируют друг с другом и следуют протоколу распределения MEV под названием "highest Protocol MEV". Этот протокол был предложен экосистемой Cosmos Skip Protocol, который отличается от схемы Ether PBS тем, что Строители блоков платят дополнительную "чаевые" Валидаторам сети блокчейна, и блоки, построенные самыми щедрыми Строителями, принимаются Валидаторами. Блоки, построенные самыми щедрыми Строителями, будут приняты Валидаторами. В то же время протокол SKIP выдвигает концепцию "Sovereign MEV", которая направлена на то, чтобы позволить всем Валидаторам и сообществу общественной сети блокчейнов иметь автономию распределения MEV и решить проблему увеличения централизации строителей из-за эффекта маховика в Ethernet PBS (но это не является ядром этой статьи).

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

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

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

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

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

Действие: L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

Если уровень DA имеет активный сбой, то уровень Rollup также будет иметь активный сбой. На этой основе уровень Rollup будет иметь активный сбой только в том случае, если у всех HP будет активный сбой.

Вариант 8: ZK Rollup с общим агрегатором + децентрализованным доказателем

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

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

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

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

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

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

Активно: L = L_da && L_sa && L_pm. Если какая-либо часть этой варианта не сработает активно, тогда Rollup не сможет сработать активно. Если доказательство не сработает, то легкий узел не сможет эффективно синхронизировать прогресс журнала Rollup. Но поскольку полный узел синхронизирует все последовательности транзакций Batch, он может держать шаг с прогрессом книги. В это время полный узел не затронут, а все легкие узлы сбоят, что эквивалентно ранее описанному случаю Based Rollup с общим агрегатором.

Минимальная конфигурация для минимизации доверия: узлы DA tier light + узлы Shared Aggregator Network light + узлы Rollup light

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

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

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

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

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

Сопротивление цензуре: общие агрегаторы могут совершать цензурные атаки, но количество опциональных слоев DA становится больше, и вероятность цензурных атак, связанных со слоями DA, уменьшается.

Activity: L = ( L_da1 || L_da2) && L_sa && L_pm.

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

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

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

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

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

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

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

Ретранслятор Rollup 2 получит Batch Header и ZKP Rollup 2 и отправит их обратно в Rollup 1. В Rollup 1 также есть светлый узел для Rollup 2 и светлый узел для слоя DA.

Мы можем упростить модель. Предположим, что два Rollup используют один и тот же Shared Aggregator и Header Producer, другими словами, они используют перекрывающие DA-уровни.

В этом случае Релеер может быть запрещен непосредственно. Поскольку Заголовок пакета и ZK Proof были опубликованы HP в том же слое DA, данные, такие как Заголовок и ZKP другого Rollup, могут быть прочитаны непосредственно на слое DA, и больше не нужно передавать через Релеер к Общему Агрегатору.

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

На данный момент минимальная конфигурация для минимизации доверия: легкий узел DA-уровня + легкий узел Rollup.

Утверждение:

1. Эта статья перепечатана из [[Geek Web3](https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw) ], авторское право принадлежит оригинальному автору[NashQ, Celestia], если у вас есть возражения по поводу перепечатки, пожалуйста, свяжитеськоманда Gate Learn, команда будет рассмотрена в соответствии с соответствующим процессом в кратчайшие сроки.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, представляют собой личные взгляды автора и не являются инвестиционными советами.
3. Статьи на других языках переводятся командой Gate Learn и не могут быть воспроизведены, распространены или скопированы без ссылки на Gate.Gate.io.