По мере увеличения использования накопительных пакетов и размещения приложений экосистемы затраты на миграцию для пользователей будут расти, а централизованные заказчики получат монопольное влияние на ценообразование. Контроллеры централизованных заказчиков имеют право максимизировать извлечение ценности (MEV) из пользователей как напрямую (например, за счет комиссий), так и косвенно (например, за счет опережающих транзакций, сэндвич-атак и т. д.). — Эспрессо
Как отметила команда Espresso, централизованные накопительные пакеты в конечном итоге столкнутся с монопольным ценообразованием и проблемами MEV. Кроме того, централизованные накопительные пакеты по своей сути нарушают возможность компоновки, что приводит к их фрагментации. **
Тем не менее, почти все текущие накопительные пакеты по-прежнему централизованы, потому что создание децентрализованного, не требующего разрешения и масштабируемого накопительного пакета чрезвычайно сложно. Другая причина заключается в том, что запуск централизованных накопительных обновлений в первую очередь может помочь инкубировать экосистему и захватить долю рынка.
И когда мы обсуждаем децентрализованные роллапы, особенно zkRollups, есть два уровня децентрализации. Первое — это децентрализация прувера, а второе — децентрализация заказчика. Для достижения полной децентрализации необходимо также решить проблему координации между заказчиком и прувером.
В соответствии с тенденцией модульности в настоящее время существует три основных типа участников децентрализованного объединения. Первая категория нацелена на создание полностью децентрализованных накопительных пакетов и предлагает комплексное решение. Вторая категория — это протоколы, предназначенные для решения сетей пруверов. Наконец, есть несколько решений, которые работают над децентрализацией сортировщика.
Сводки децентрализованы
В zkRollups Polygon и Starknet придумали решения для децентрализации своих роллапов.
Многоугольник
До введения POE (доказательство эффективности) Polygon zkEVM использовал POD (доказательство пожертвования), позволяя сортировщику делать ставки на возможность создания следующего пакета транзакций. Однако это создает проблему, заключающуюся в том, что одна злоумышленник может контролировать всю сеть, предлагая самую высокую цену.
После принятия POE заказчик и испытатель будут наиболее эффективно участвовать в сети без разрешений в своих собственных аппаратных условиях. Любой может присоединиться к Polygon zkEVM, если это экономически целесообразно.
В Polygon zkEVM для сортировщика требуется 16 ГБ ОЗУ и 4-ядерный процессор, а для прувера — 1 ТБ ОЗУ и 128-ядерный процессор. Кроме того, существует роль, называемая агрегатором, которая отвечает за сбор данных L1, отправку их на доказывающую, получение доказательства и отправку его на L1. Мы можем считать агрегатора и доказывающего одним и тем же субъектом, потому что отношения между агрегатором и доказывающим очень просты, и агрегатор платит доказывающему за предоставление доказательства.
Эта архитектура очень проста: любой ордер может упаковывать транзакции на основе предыдущего состояния на L1 без разрешения и обновлять соответствующее состояние. В то же время любой агрегатор может предоставить подтверждение для проверки обновленного состояния.
В POE эффективность относится не только к сетевой эффективности участников, конкурирующих друг с другом, но и к экономической эффективности самих секвенаторов и пруверов. В L2 заказчик и доказывающий делят комиссию за транзакцию, а заказчик платит пакетную комиссию агрегатору для создания доказательства. Это гарантирует, что участники экономически мотивированы вносить свой вклад в эффективность сети, что приводит к более надежной и устойчивой экосистеме.
сортировщик
Доход: комиссия за транзакцию L2
Стоимость: batchFee (рассчитывается в $MATIC) + комиссия за транзакцию L1 (вызов метода sequenceBatches)
Агрегатор (доказательство)
Доход: пакетная комиссия (рассчитывается в $MATIC)
Стоимость: стоимость подтверждения + комиссия за транзакцию L1 (вызов метода verifyBatchesTrustedAggregator)
Координатор: batchFee
исходные параметры
пакетная комиссия = 1 $MATIC
veryBatchTimeTarget = 30 минут. Это целевое время для пакета проверки. Протокол обновит переменную batchFee для достижения этого целевого времени.
множительBatchFee = 1002. Это множитель комиссионных сборов в диапазоне от 1000 до 1024 с 3 знаками после запятой.
Регулятор
diffBatches : количество агрегированных пакетов > 30 минут минус количество пакетов <= 30 минут. Максимальное значение равно 12.
Процесс согласования
Увеличьте вознаграждение за агрегацию, чтобы стимулировать агрегаторов, когда diffBatches > 0.
Когда diffBatches < 0, уменьшите вознаграждение за агрегацию, чтобы подавить агрегатор и замедлить процесс агрегации.
Старкнет
Starknet также стремится создать масштабируемый и не требующий разрешения накопительный пакет с быстрым подтверждением. Хотя окончательная спецификация децентрализованного решения еще не достигнута, несколько месяцев назад на форуме были опубликованы некоторые черновики.
По сравнению с простым механизмом Polygon zkEVM схема Starknet более сложна, поскольку включает в себя консенсус L2 и связанное доказательство протокола в сети доказательства.
сортировщик
Вместо того, чтобы просто добавить уровень консенсуса в уровень заказчика, Starknet предлагает протокол консенсуса с двойной бухгалтерской книгой. В этом протоколе L2 обеспечивает быстрый ответ в качестве живого протокола, а контрольные точки L1 обеспечивают окончательное подтверждение в качестве безопасного протокола.
Для живого протокола L2 могут быть приняты различные механизмы консенсуса, такие как системы PoS, устойчивые к Sybil, такие как Tendermint или DAG. С другой стороны, безопасный протокол L1 включает в себя несколько контрактов, которые обрабатывают управление долей, проверку подтверждения и обновление статуса соответственно.
Типичный рабочий процесс консенсусного протокола двойного реестра выглядит следующим образом:
Сначала используйте выходные данные оперативного регистра L2 в качестве входных данных безопасного регистра L1 для создания проверенного оперативного регистра.
Затем возьмите проверенный оперативный реестр в качестве входных данных и снова введите его в чистый согласованный протокол L2, чтобы убедиться, что проверенный оперативный реестр всегда является префиксом оперативного реестра.
Повторите вышеуказанный процесс.
При построении протокола консенсуса с двойной бухгалтерской книгой существует компромисс между стоимостью и задержкой. Идеальное решение направлено на достижение как низкой стоимости, так и быстрого окончательного утверждения.
Чтобы снизить затраты на газ на L2, Starknet делит контрольные точки на «минутный уровень» и «часовой уровень». Для контрольных точек «минутного уровня» в цепочку фиксируется только само состояние, а остальные данные (доказательства достоверности, доступность данных и т. д.) отправляются по сети StarkNet L2. Эти данные хранятся и проверяются полными узлами StarkNet. С другой стороны, «ежечасные» контрольные точки публично проверяются на уровне L1. Оба типа контрольных точек обеспечивают одинаковое окончательное подтверждение. Для контрольных точек «минутного уровня» подтверждение достоверности проверяется полными узлами StarkNet и может быть выдано любым узлом на L1, чтобы придать L1 окончательность контрольным точкам «минутного уровня». Следовательно, доказывающему необходимо генерировать небольшие доказательства для широкого распространения в сети L2.
Чтобы еще больше уменьшить задержку, Starknet предлагает протокол выбора лидера, чтобы определить лидера заранее. Основная логика такова: лидер текущей эпохи i предопределен исходя из суммы ставки L1 и некоторой случайности. В частности, в эпоху i-2 метод лидера_election лексикографически разбивает сортировщики на основе суммы залогов в эпоху i-3. Затем отправьте транзакцию для обновления одноразового номера и случайного выбора точки. Сортировщик, соответствующий позиции, в которую попадает точка, будет лидером эпохи i.
Сертификат
В рамках модуля POE проводится открытое соревнование между участниками, что может привести к ситуации, когда победитель получает все. Starknet пытается создать механизм конкуренции без риска централизации. Вот несколько вариантов:
Ротация: это может частично решить проблему централизации, но может не дать стимулов для поиска лучшего человека для проверки работы.
На основе ставок: сортировщик определяет вероятность быть избранным в качестве доказывающего на основе суммы, которую он ставит.
Схема Commit-Reveal: первому коммиттеру необходимо заложить токены, чтобы получить короткую монопольную возможность, а затем сгенерировать доказательства в течение этого временного окна. Во избежание DDoS-атак, если первый не сможет вовремя сгенерировать доказательства, количество залоговых токенов, требуемых последним, будет увеличиваться в геометрической прогрессии. Хотя при таком механизме сеть может потерять машину с лучшей производительностью, но можно вырастить больше пруверов.
В дополнение к конкуренции среди доказывающих, барьер для входа должен быть снижен, чтобы большее количество доказывающих могло участвовать в сети. Starknet предлагает сложный протокол, использующий рекурсивные доказательства, называемые доказательствами цепного протокола.
В протоколах Proof-of-Chain сам блокчейн делится на несколько разных форков. Таким образом, доказательства могут быть не только рекурсивными, но и генерация доказательств может быть параллельной. Например, в настройке с 3 ответвлениями 12 черных блоков разделены на 3 ряда, каждый ряд представляет собой ответвление. Мы можем думать о каждой ветви как о подцепочке, где каждый блок должен свидетельствовать о предыдущем блоке. С точки зрения всей цепочки, слот n должен доказать слот n-3. Интервал в 3 блока дает заказчику достаточно времени для расчета и приобретения пруфов заранее. Это чем-то похоже на шардинг, когда злоумышленнику нужно контролировать только одну ветвь, чтобы контролировать всю сеть пруверов.
Для объединения этих ветвей Starknet предлагает технологию объединения, которая может объединять несколько узлов для совместной проверки легитимности транзакций и обеспечения согласованности и надежности записей транзакций.
Одним из решений является требование, чтобы каждый слот был объединен с несколькими ветвями одновременно. Другое решение — поочередно пытаться объединить каждую ветвь с другими ветвями, тем самым уменьшая нагрузку на доказательство. Конечно, это также открытая проблема, и в будущем могут быть лучшие решения.
координация
Чтобы активно гарантировать, что у доказывающего может быть достаточно места для прибыли, Starknet предлагает метод ссылки на схему EIP1559: установить базовую плату как нижний предел цены ресурса доказывающего, активно проводить обнаружение цены, а сортировщик может использовать подсказки. мотивировать доказывающего. Таким образом, доказывающий всегда будет переплачивать, и только крайние случаи будут влиять на процесс доказательства. В противном случае, если прувер получает оплату, близкую к рыночной, небольшое колебание может вызвать блокировку прувера.
Децентрализация сертификатора
С точки зрения Rollups, пруверу легче добиться децентрализации, чем сортировщику. Кроме того, текущий прувер является узким местом в производительности и должен соответствовать скорости пакетной обработки сортировщика. Когда децентрализация сортировщика не решена, децентрализованный прувер также может предоставлять услуги для централизованного сортировщика.
На самом деле, не только Rollups, zkBridge и zkOracle также нуждаются в проверочной сети. Все они требуют сильной распределенной сети пруверов.
В долгосрочной перспективе сеть пруверов, которая может поддерживать различную вычислительную мощность, является более устойчивой, в противном случае самые производительные машины монополизируют рынок.
Доказательство рынка
Некоторые протоколы не координируют отношения между секвенсором и прувером, а напрямую абстрагируют координацию в рынок пруфов. На этом рынке пруфы являются товаром, пруверы — производителями пруфов, а протоколы — потребителями пруфов. Рыночное равновесие наиболее эффективно под влиянием «невидимой руки».
Мой
Мина создала рынок пруфов под названием Snarketplace, где продаются пруфы Snark. Наименьшая единица здесь — это доказательство Snark для одной транзакции. Мина использует рекурсивное доказательство дерева состояний под названием Scan State.
Состояние сканирования — это лес бинарных деревьев, где каждая транзакция является узлом. В верхней части дерева создается единственное доказательство, которое может подтвердить все транзакции в дереве. У доказывающего есть две задачи: первая — генерировать доказательства, а вторая — объединять доказательства.
После того, как прувер завершит работу и отправит заявку, производитель блоков протокола Mina выберет участника торгов с самой низкой ценой. Это также равновесная цена, поскольку участники торгов будут подавать заявки выше стоимости пруфов, а производители блоков не будут покупать пруфы, которые не стоят денег.
=Ноль; Фундамент
Рынок пруфов Mina разработан для собственного протокола, в то время как =nil; Foundation предлагает общий рынок пруфов для обслуживания всего рынка.
Сервис рынка состоит из трех компонентов: DROP DATABASE, zkLLVM и Proof Market.
DROP DATABASE: это протокол системы управления базами данных, который можно рассматривать как уровень DA.
Proof Market: это приложение, работающее на DROP DATABASE, похожее на то, что некоторые называют «децентрализованной биржей с защитой от zk».
zkLLVM: это компилятор, который преобразует языки программирования высокого уровня во входные данные для доказуемых вычислительных протоколов.
Каждое доказательство состоит из разных входов и схем, поэтому каждое доказательство уникально. Цепь определяет тип доказательства, аналогично тому, как «транзакционная пара» определяется в финансовых терминах. Кроме того, различные системы доказательства вводят больше схем.
Рабочий процесс выглядит следующим образом: сторона запроса доказательства может написать код на языке программирования высокого уровня, а затем передать его =nil;zkLLVM через цепочку инструментов, создав единую схему, которая станет уникальной торговой парой на рынке.
Что касается проверки спроса, они могут найти компромисс между стоимостью и временем. Доказывающие также будут учитывать свою вычислительную мощность и доход. Поэтому на рынке будет разная вычислительная мощность, высокая вычислительная мощность будет генерировать доказательства быстрее, но с большей стоимостью, а низкая вычислительная мощность будет генерировать доказательства медленнее, но дешевле.
ДВА ШАГА
Недавно Opside предложила двухэтапную схему коммитов для децентрализации сети прувера. Схема делит отправку доказательства на две фазы, чтобы избежать ситуации, когда всегда побеждает самый быстрый доказывающий.
Шаг 1: Отправьте хэш доказательства с нулевым разглашением T-го блока
Начиная с блока T+11, новые пруверы больше не могут отправлять хэши.
Шаг 2: Отправьте доказательство с нулевым разглашением
После блока T+11 любой доказывающий может представить доказательство с нулевым разглашением. Если хотя бы одно доказательство с нулевым разглашением пройдет проверку, оно будет использовано для проверки всех отправленных хэшей, и проверенный доказывающий получит соответствующие вознаграждения PoW пропорционально сумме ипотеки.
Если доказательство с нулевым разглашением не будет проверено до T+20-го блока, все доказывающие, предоставившие хэши, будут оштрафованы. Затем снова откройте сортировщик, вы можете отправить новый хеш, вернуться к шагу 1.
Этот метод может работать с различной вычислительной мощностью. Однако требуемый залог по-прежнему вносит определенный уровень централизации.
Децентрализация сортировщика
Децентрализация ордеров сложнее, чем у валидаторов. Это связано с тем, что сортировщик может упаковывать и упорядочивать транзакции, и необходимо учитывать такие вопросы, как MEV и распределение доходов.
Учитывая, что Ethereum будет отдавать предпочтение живости, а не отзывчивости, решения L2 должны дополнять этот компромисс, отдавая приоритет отзывчивости, а не живучести. Однако по сравнению с централизованными сортировщиками децентрализованные сортировщики по своей сути жертвуют скоростью отклика. Поэтому для решения этой дилеммы необходимо реализовать различные оптимизации.
В настоящее время существует три различных предложения децентрализованных сортировщиков. Первое решение реализуется за счет оптимизации механизма консенсуса. Вторая схема включает сеть общих секвенсоров. Третья схема основана на валидаторах L1.
консенсус
Протокол консенсуса в первую очередь отвечает за упорядочивание транзакций и обеспечение их доступности, а не за их выполнение. Однако прямое добавление еще одного уровня консенсуса, как упоминалось ранее, — непростое решение.
Чтобы улучшить отзывчивость, общий подход состоит в том, чтобы полагаться на меньший набор валидаторов. Например, Algorand и Polkadot используют случайные выборки небольших комитетов для пакетной обработки транзакций. Все узлы используют случайные маяки и проверяемую случайную функцию (VRF), с вероятностью включения в комитет в заданный период, пропорциональной их сумме ставок.
Чтобы уменьшить сетевой трафик, можно использовать меньшие комитеты доступности данных (DA). Или используйте VID (рассеивание проверенной информации). VID распределяет код удаления данных по всем узлам, участвующим в консенсусе, так что любое подмножество узлов, имеющих достаточно высокий коэффициент залога, может сотрудничать для восстановления данных. Недостатком этого подхода является снижение сложности трансляции, но увеличение сложности восстановления данных.
Arbitrum выбрал авторитетных организаций для формирования набора валидаторов, таких как ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, Исследовательский центр распределенной бухгалтерской книги IFF (DLRC) и Unit 410, чтобы присоединиться к комитету сортировщика. Компромисс в этом подходе состоит в том, чтобы компенсировать нехватку количества за счет улучшения качества децентрализации.
Общая сеть секвенсора
Сортировщики играют жизненно важную роль в модульных блокчейнах, особенно в Rollups. Каждый Rollup обычно строит свою собственную сеть сортировщиков. Однако такой подход не только создает проблемы избыточности, но и затрудняет компоновку. Для решения этой проблемы некоторые протоколы предлагают построить общую сеть сортировщиков Rollup. Этот подход снижает сложность достижения атомарности, компонуемости и функциональной совместимости — функций, в которых пользователи и разработчики отчаянно нуждаются в открытых блокчейнах без разрешений. Кроме того, это также устраняет необходимость в отдельном легком клиенте для сети заказов.
Астрия
Astria разрабатывает блокчейн промежуточного программного обеспечения для экосистемы Celestia Rollup, которая включает в себя собственную коллекцию распределенных ордеров. Этот набор ордеров отвечает за прием транзакций из нескольких Rollup и запись их на базовый уровень без их выполнения.
Роль Astria в основном сосредоточена на упорядочении транзакций и работает независимо от базового уровня и Rollup. Данные транзакций хранятся на базовом уровне (например, Celestia), в то время как полные узлы Rollup сохраняют состояние и выполняют операции. Это гарантирует, что Astria отделена от Rollup.
Для окончательности Astria предлагает два уровня обязательств:
«Мягкое обязательство»: позволяет Rollup предоставлять конечным пользователям быстрые подтверждения блокировки.
«Твердое обязательство»: скорость такая же, как у базового уровня, что обеспечивает более высокую безопасность и завершенность.
Эспрессо
Эспрессо внес значительный вклад в развитие технологий с нулевым разглашением. Их последняя разработка представляет собой комплексное решение для децентрализованных сортировщиков, которое можно применять к Optimistic Rollups и zkRollups.
Децентрализованная сеть заказов состоит из:
Консенсус HotShot: отдайте предпочтение высокой пропускной способности и быстрому завершению, а не динамической доступности.
Espresso DA: сочетание решения DA на основе комитета и VID, где узлы с высокой пропускной способностью передают данные всем другим узлам. Доступность каждого отдельного блока также поддерживается небольшим случайно избранным комитетом. VID обеспечивают надежное, но более медленное резервное копирование, гарантируя доступность до тех пор, пока не будет скомпрометирован достаточно высокий процент стейкингового веса всех узлов.
Сводный REST API: Ethereum совместим с JSON-RPC.
Контракт секвенсора: проверка консенсуса HotShot (т. е. работа в качестве легкого клиента) и запись контрольных точек (т. е. выполнение криптографической фиксации транзакции) и управление таблицей обязательств HotShot.
Сеть P2P: протокол сплетен.
По сравнению с Astria, Espresso предлагает DA. Поэтому рабочий процесс будет немного отличаться, а именно:
Пользователь создает и отправляет транзакцию в Rollup.
Транзакция распространяется через сеть заказчика и сохраняется в мемпуле.
Назначьте лидера с помощью механизма залога HotShot, предложите блок и передайте его исполнителям и испытателям Rollup.
Лидер отправляет транзакцию в Комитет доступности данных и получает в качестве обратной связи сертификат DA.
Лидер также отправляет подтверждение блока контракту сортировщика уровня 1 вместе с сертификатом, который контракт использует для проверки блока.
Espresso представляет протокол Gossip для доказательств, чтобы обеспечить более гибкий пользовательский интерфейс. Он предоставляет три варианта завершения транзакции:
Быстро: пользователи могут доверять серверу Rollup, который выполнил транзакцию и сгенерировал подтверждение, или они могут воспользоваться преимуществами низкой задержки HotShot для выполнения транзакции.
Умеренный: пользователь может немного подождать, пока будет сгенерировано доказательство, а затем проверить его.
Медленно: пользователи могут ждать обновлений проверенного состояния L1, чтобы получить обновленное состояние без каких-либо предположений или расчетов доверия.
В дополнение к вышеупомянутым оптимизациям, Espresso также планирует, чтобы весь набор валидаторов Ethereum сам участвовал в запуске протокола ордера Espresso. Использование одного и того же набора валидаторов обеспечит аналогичную безопасность, а совместное использование ценности с валидаторами L1 будет более безопасным. Кроме того, Espresso также может воспользоваться решением для повторного стейкинга ETH, предоставляемым EigenLayer.
Радиус
Radius создает ненадежный общий уровень упорядочения на основе доказательств с нулевым разглашением, фокусируясь на решении проблемы MEV в L2, поскольку доход L2 в основном поступает от блочного пространства. Компромисс, который следует учитывать, — это баланс между доходами MEV и L2. Цель Radius — устранить MEV, который вреден для пользователей, и предлагает двухуровневый сервис.
Верхний уровень предназначен для обычных пользовательских транзакций и обеспечивает криптографическую защиту от нежелательных MEV с помощью головоломок с временной блокировкой. В частности, он использует технологию Практического проверяемого отложенного шифрования (PVDE), которая будет генерировать доказательства с нулевым разглашением для головоломок с временной блокировкой на основе RSA за 5 секунд. Этот метод обеспечивает практическое решение для защиты пользователей от вредных MEV. Короче говоря, содержимое транзакции не может быть известно, пока секвенсор не определит порядок транзакций.
Базовый уровень предназначен для строителей блоков и позволяет им участвовать в деятельности, приносящей доход, одновременно смягчая негативное влияние MEV.
Сводки на основе
Сворачивание на основе — это концепция, недавно предложенная Джастином Дрейком, в которой разработчики блоков L1 сотрудничают с поисковиками и разработчиками L1 для включения блоков сворачивания в следующий блок L1 без разрешения. Его можно рассматривать как сеть общих секвенсоров на L1. Преимущества и недостатки агрегации на основе очевидны.
Положительным моментом является то, что в основе Rollup используются живость и децентрализация, обеспечиваемые L1, а его реализация проста и эффективна. Rollup также экономически совместим с L1. Однако это не означает, что накопительный пакет на базе ставит под угрозу его суверенитет. Несмотря на то, что MEV передан L1, накопительный пакет по-прежнему может владеть токенами управления и взимать базовую плату. Исходя из этой гипотезы, агрегация на основе может воспользоваться этими преимуществами, добиться превосходства и, в конечном счете, максимизировать отдачу.
в заключение
Глядя на предложенные предложения, видно, что до децентрализации Rollup еще далеко. Некоторые из этих предложений все еще находятся на стадии проекта и требуют дальнейшего обсуждения, в то время как для других разработаны только предварительные спецификации. Все эти сценарии необходимо реализовать и тщательно протестировать.
Хотя некоторые накопительные пакеты могут не предлагать в явном виде соответствующее децентрализованное решение, они часто включают механизмы обхода для устранения единых точек отказа из-за централизованных заказчиков. Например, zkSync предоставляет метод FullExit, который позволяет пользователям выводить свои средства напрямую из L1. Когда система переходит в режим исхода и не может обрабатывать новые блоки, пользователь может инициировать операцию вывода средств.
Чтобы обеспечить устойчивость к цензуре, эти накопительные пакеты часто также позволяют пользователям отправлять транзакции непосредственно на L1. Например, zkSync использует приоритетную очередь для таких транзакций, отправленных на L1. Точно так же Polygon zkEVM включает принудительный пакетный метод в контракт L1. Если в течение недели агрегация не происходит, пользователь может вызвать этот метод на уровне L1 и предоставить проверяющей стороне массив байтов транзакции и BathFee.
Несомненно то, что в обозримом будущем децентрализация Rollup будет комбинированным решением, которое может включать в себя упомянутые выше важные решения или некоторые другие инновационные варианты.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Общие сведения о децентрализованных накопительных пакетах в одной статье
Оригинальное название: «Децентрализованные накопительные пакеты».
По мере увеличения использования накопительных пакетов и размещения приложений экосистемы затраты на миграцию для пользователей будут расти, а централизованные заказчики получат монопольное влияние на ценообразование. Контроллеры централизованных заказчиков имеют право максимизировать извлечение ценности (MEV) из пользователей как напрямую (например, за счет комиссий), так и косвенно (например, за счет опережающих транзакций, сэндвич-атак и т. д.). — Эспрессо
Как отметила команда Espresso, централизованные накопительные пакеты в конечном итоге столкнутся с монопольным ценообразованием и проблемами MEV. Кроме того, централизованные накопительные пакеты по своей сути нарушают возможность компоновки, что приводит к их фрагментации. **
Тем не менее, почти все текущие накопительные пакеты по-прежнему централизованы, потому что создание децентрализованного, не требующего разрешения и масштабируемого накопительного пакета чрезвычайно сложно. Другая причина заключается в том, что запуск централизованных накопительных обновлений в первую очередь может помочь инкубировать экосистему и захватить долю рынка.
И когда мы обсуждаем децентрализованные роллапы, особенно zkRollups, есть два уровня децентрализации. Первое — это децентрализация прувера, а второе — децентрализация заказчика. Для достижения полной децентрализации необходимо также решить проблему координации между заказчиком и прувером.
В соответствии с тенденцией модульности в настоящее время существует три основных типа участников децентрализованного объединения. Первая категория нацелена на создание полностью децентрализованных накопительных пакетов и предлагает комплексное решение. Вторая категория — это протоколы, предназначенные для решения сетей пруверов. Наконец, есть несколько решений, которые работают над децентрализацией сортировщика.
Сводки децентрализованы
В zkRollups Polygon и Starknet придумали решения для децентрализации своих роллапов.
Многоугольник
До введения POE (доказательство эффективности) Polygon zkEVM использовал POD (доказательство пожертвования), позволяя сортировщику делать ставки на возможность создания следующего пакета транзакций. Однако это создает проблему, заключающуюся в том, что одна злоумышленник может контролировать всю сеть, предлагая самую высокую цену.
После принятия POE заказчик и испытатель будут наиболее эффективно участвовать в сети без разрешений в своих собственных аппаратных условиях. Любой может присоединиться к Polygon zkEVM, если это экономически целесообразно.
В Polygon zkEVM для сортировщика требуется 16 ГБ ОЗУ и 4-ядерный процессор, а для прувера — 1 ТБ ОЗУ и 128-ядерный процессор. Кроме того, существует роль, называемая агрегатором, которая отвечает за сбор данных L1, отправку их на доказывающую, получение доказательства и отправку его на L1. Мы можем считать агрегатора и доказывающего одним и тем же субъектом, потому что отношения между агрегатором и доказывающим очень просты, и агрегатор платит доказывающему за предоставление доказательства.
Эта архитектура очень проста: любой ордер может упаковывать транзакции на основе предыдущего состояния на L1 без разрешения и обновлять соответствующее состояние. В то же время любой агрегатор может предоставить подтверждение для проверки обновленного состояния.
В POE эффективность относится не только к сетевой эффективности участников, конкурирующих друг с другом, но и к экономической эффективности самих секвенаторов и пруверов. В L2 заказчик и доказывающий делят комиссию за транзакцию, а заказчик платит пакетную комиссию агрегатору для создания доказательства. Это гарантирует, что участники экономически мотивированы вносить свой вклад в эффективность сети, что приводит к более надежной и устойчивой экосистеме.
сортировщик
Агрегатор (доказательство)
Координатор: batchFee
Старкнет
Starknet также стремится создать масштабируемый и не требующий разрешения накопительный пакет с быстрым подтверждением. Хотя окончательная спецификация децентрализованного решения еще не достигнута, несколько месяцев назад на форуме были опубликованы некоторые черновики.
По сравнению с простым механизмом Polygon zkEVM схема Starknet более сложна, поскольку включает в себя консенсус L2 и связанное доказательство протокола в сети доказательства.
сортировщик
Вместо того, чтобы просто добавить уровень консенсуса в уровень заказчика, Starknet предлагает протокол консенсуса с двойной бухгалтерской книгой. В этом протоколе L2 обеспечивает быстрый ответ в качестве живого протокола, а контрольные точки L1 обеспечивают окончательное подтверждение в качестве безопасного протокола.
Для живого протокола L2 могут быть приняты различные механизмы консенсуса, такие как системы PoS, устойчивые к Sybil, такие как Tendermint или DAG. С другой стороны, безопасный протокол L1 включает в себя несколько контрактов, которые обрабатывают управление долей, проверку подтверждения и обновление статуса соответственно.
Типичный рабочий процесс консенсусного протокола двойного реестра выглядит следующим образом:
Сначала используйте выходные данные оперативного регистра L2 в качестве входных данных безопасного регистра L1 для создания проверенного оперативного регистра.
Затем возьмите проверенный оперативный реестр в качестве входных данных и снова введите его в чистый согласованный протокол L2, чтобы убедиться, что проверенный оперативный реестр всегда является префиксом оперативного реестра.
Повторите вышеуказанный процесс.
При построении протокола консенсуса с двойной бухгалтерской книгой существует компромисс между стоимостью и задержкой. Идеальное решение направлено на достижение как низкой стоимости, так и быстрого окончательного утверждения.
Чтобы снизить затраты на газ на L2, Starknet делит контрольные точки на «минутный уровень» и «часовой уровень». Для контрольных точек «минутного уровня» в цепочку фиксируется только само состояние, а остальные данные (доказательства достоверности, доступность данных и т. д.) отправляются по сети StarkNet L2. Эти данные хранятся и проверяются полными узлами StarkNet. С другой стороны, «ежечасные» контрольные точки публично проверяются на уровне L1. Оба типа контрольных точек обеспечивают одинаковое окончательное подтверждение. Для контрольных точек «минутного уровня» подтверждение достоверности проверяется полными узлами StarkNet и может быть выдано любым узлом на L1, чтобы придать L1 окончательность контрольным точкам «минутного уровня». Следовательно, доказывающему необходимо генерировать небольшие доказательства для широкого распространения в сети L2.
Чтобы еще больше уменьшить задержку, Starknet предлагает протокол выбора лидера, чтобы определить лидера заранее. Основная логика такова: лидер текущей эпохи i предопределен исходя из суммы ставки L1 и некоторой случайности. В частности, в эпоху i-2 метод лидера_election лексикографически разбивает сортировщики на основе суммы залогов в эпоху i-3. Затем отправьте транзакцию для обновления одноразового номера и случайного выбора точки. Сортировщик, соответствующий позиции, в которую попадает точка, будет лидером эпохи i.
Сертификат
В рамках модуля POE проводится открытое соревнование между участниками, что может привести к ситуации, когда победитель получает все. Starknet пытается создать механизм конкуренции без риска централизации. Вот несколько вариантов:
В дополнение к конкуренции среди доказывающих, барьер для входа должен быть снижен, чтобы большее количество доказывающих могло участвовать в сети. Starknet предлагает сложный протокол, использующий рекурсивные доказательства, называемые доказательствами цепного протокола.
В протоколах Proof-of-Chain сам блокчейн делится на несколько разных форков. Таким образом, доказательства могут быть не только рекурсивными, но и генерация доказательств может быть параллельной. Например, в настройке с 3 ответвлениями 12 черных блоков разделены на 3 ряда, каждый ряд представляет собой ответвление. Мы можем думать о каждой ветви как о подцепочке, где каждый блок должен свидетельствовать о предыдущем блоке. С точки зрения всей цепочки, слот n должен доказать слот n-3. Интервал в 3 блока дает заказчику достаточно времени для расчета и приобретения пруфов заранее. Это чем-то похоже на шардинг, когда злоумышленнику нужно контролировать только одну ветвь, чтобы контролировать всю сеть пруверов.
Для объединения этих ветвей Starknet предлагает технологию объединения, которая может объединять несколько узлов для совместной проверки легитимности транзакций и обеспечения согласованности и надежности записей транзакций.
Одним из решений является требование, чтобы каждый слот был объединен с несколькими ветвями одновременно. Другое решение — поочередно пытаться объединить каждую ветвь с другими ветвями, тем самым уменьшая нагрузку на доказательство. Конечно, это также открытая проблема, и в будущем могут быть лучшие решения.
координация
Чтобы активно гарантировать, что у доказывающего может быть достаточно места для прибыли, Starknet предлагает метод ссылки на схему EIP1559: установить базовую плату как нижний предел цены ресурса доказывающего, активно проводить обнаружение цены, а сортировщик может использовать подсказки. мотивировать доказывающего. Таким образом, доказывающий всегда будет переплачивать, и только крайние случаи будут влиять на процесс доказательства. В противном случае, если прувер получает оплату, близкую к рыночной, небольшое колебание может вызвать блокировку прувера.
Децентрализация сертификатора
С точки зрения Rollups, пруверу легче добиться децентрализации, чем сортировщику. Кроме того, текущий прувер является узким местом в производительности и должен соответствовать скорости пакетной обработки сортировщика. Когда децентрализация сортировщика не решена, децентрализованный прувер также может предоставлять услуги для централизованного сортировщика.
На самом деле, не только Rollups, zkBridge и zkOracle также нуждаются в проверочной сети. Все они требуют сильной распределенной сети пруверов.
В долгосрочной перспективе сеть пруверов, которая может поддерживать различную вычислительную мощность, является более устойчивой, в противном случае самые производительные машины монополизируют рынок.
Доказательство рынка
Некоторые протоколы не координируют отношения между секвенсором и прувером, а напрямую абстрагируют координацию в рынок пруфов. На этом рынке пруфы являются товаром, пруверы — производителями пруфов, а протоколы — потребителями пруфов. Рыночное равновесие наиболее эффективно под влиянием «невидимой руки».
Мой
Мина создала рынок пруфов под названием Snarketplace, где продаются пруфы Snark. Наименьшая единица здесь — это доказательство Snark для одной транзакции. Мина использует рекурсивное доказательство дерева состояний под названием Scan State.
Состояние сканирования — это лес бинарных деревьев, где каждая транзакция является узлом. В верхней части дерева создается единственное доказательство, которое может подтвердить все транзакции в дереве. У доказывающего есть две задачи: первая — генерировать доказательства, а вторая — объединять доказательства.
После того, как прувер завершит работу и отправит заявку, производитель блоков протокола Mina выберет участника торгов с самой низкой ценой. Это также равновесная цена, поскольку участники торгов будут подавать заявки выше стоимости пруфов, а производители блоков не будут покупать пруфы, которые не стоят денег.
=Ноль; Фундамент
Рынок пруфов Mina разработан для собственного протокола, в то время как =nil; Foundation предлагает общий рынок пруфов для обслуживания всего рынка.
Сервис рынка состоит из трех компонентов: DROP DATABASE, zkLLVM и Proof Market.
Каждое доказательство состоит из разных входов и схем, поэтому каждое доказательство уникально. Цепь определяет тип доказательства, аналогично тому, как «транзакционная пара» определяется в финансовых терминах. Кроме того, различные системы доказательства вводят больше схем.
Рабочий процесс выглядит следующим образом: сторона запроса доказательства может написать код на языке программирования высокого уровня, а затем передать его =nil;zkLLVM через цепочку инструментов, создав единую схему, которая станет уникальной торговой парой на рынке.
Что касается проверки спроса, они могут найти компромисс между стоимостью и временем. Доказывающие также будут учитывать свою вычислительную мощность и доход. Поэтому на рынке будет разная вычислительная мощность, высокая вычислительная мощность будет генерировать доказательства быстрее, но с большей стоимостью, а низкая вычислительная мощность будет генерировать доказательства медленнее, но дешевле.
ДВА ШАГА
Недавно Opside предложила двухэтапную схему коммитов для децентрализации сети прувера. Схема делит отправку доказательства на две фазы, чтобы избежать ситуации, когда всегда побеждает самый быстрый доказывающий.
Этот метод может работать с различной вычислительной мощностью. Однако требуемый залог по-прежнему вносит определенный уровень централизации.
Децентрализация сортировщика
Децентрализация ордеров сложнее, чем у валидаторов. Это связано с тем, что сортировщик может упаковывать и упорядочивать транзакции, и необходимо учитывать такие вопросы, как MEV и распределение доходов.
Учитывая, что Ethereum будет отдавать предпочтение живости, а не отзывчивости, решения L2 должны дополнять этот компромисс, отдавая приоритет отзывчивости, а не живучести. Однако по сравнению с централизованными сортировщиками децентрализованные сортировщики по своей сути жертвуют скоростью отклика. Поэтому для решения этой дилеммы необходимо реализовать различные оптимизации.
В настоящее время существует три различных предложения децентрализованных сортировщиков. Первое решение реализуется за счет оптимизации механизма консенсуса. Вторая схема включает сеть общих секвенсоров. Третья схема основана на валидаторах L1.
консенсус
Протокол консенсуса в первую очередь отвечает за упорядочивание транзакций и обеспечение их доступности, а не за их выполнение. Однако прямое добавление еще одного уровня консенсуса, как упоминалось ранее, — непростое решение.
Чтобы улучшить отзывчивость, общий подход состоит в том, чтобы полагаться на меньший набор валидаторов. Например, Algorand и Polkadot используют случайные выборки небольших комитетов для пакетной обработки транзакций. Все узлы используют случайные маяки и проверяемую случайную функцию (VRF), с вероятностью включения в комитет в заданный период, пропорциональной их сумме ставок.
Чтобы уменьшить сетевой трафик, можно использовать меньшие комитеты доступности данных (DA). Или используйте VID (рассеивание проверенной информации). VID распределяет код удаления данных по всем узлам, участвующим в консенсусе, так что любое подмножество узлов, имеющих достаточно высокий коэффициент залога, может сотрудничать для восстановления данных. Недостатком этого подхода является снижение сложности трансляции, но увеличение сложности восстановления данных.
Arbitrum выбрал авторитетных организаций для формирования набора валидаторов, таких как ConsenSys, Ethereum Foundation, L2BEAT, Mycelium, Offchain Labs, P2P, Quicknode, Исследовательский центр распределенной бухгалтерской книги IFF (DLRC) и Unit 410, чтобы присоединиться к комитету сортировщика. Компромисс в этом подходе состоит в том, чтобы компенсировать нехватку количества за счет улучшения качества децентрализации.
Общая сеть секвенсора
Сортировщики играют жизненно важную роль в модульных блокчейнах, особенно в Rollups. Каждый Rollup обычно строит свою собственную сеть сортировщиков. Однако такой подход не только создает проблемы избыточности, но и затрудняет компоновку. Для решения этой проблемы некоторые протоколы предлагают построить общую сеть сортировщиков Rollup. Этот подход снижает сложность достижения атомарности, компонуемости и функциональной совместимости — функций, в которых пользователи и разработчики отчаянно нуждаются в открытых блокчейнах без разрешений. Кроме того, это также устраняет необходимость в отдельном легком клиенте для сети заказов.
Астрия
Astria разрабатывает блокчейн промежуточного программного обеспечения для экосистемы Celestia Rollup, которая включает в себя собственную коллекцию распределенных ордеров. Этот набор ордеров отвечает за прием транзакций из нескольких Rollup и запись их на базовый уровень без их выполнения.
Роль Astria в основном сосредоточена на упорядочении транзакций и работает независимо от базового уровня и Rollup. Данные транзакций хранятся на базовом уровне (например, Celestia), в то время как полные узлы Rollup сохраняют состояние и выполняют операции. Это гарантирует, что Astria отделена от Rollup.
Для окончательности Astria предлагает два уровня обязательств:
Эспрессо
Эспрессо внес значительный вклад в развитие технологий с нулевым разглашением. Их последняя разработка представляет собой комплексное решение для децентрализованных сортировщиков, которое можно применять к Optimistic Rollups и zkRollups.
Децентрализованная сеть заказов состоит из:
По сравнению с Astria, Espresso предлагает DA. Поэтому рабочий процесс будет немного отличаться, а именно:
Пользователь создает и отправляет транзакцию в Rollup.
Транзакция распространяется через сеть заказчика и сохраняется в мемпуле.
Назначьте лидера с помощью механизма залога HotShot, предложите блок и передайте его исполнителям и испытателям Rollup.
Лидер отправляет транзакцию в Комитет доступности данных и получает в качестве обратной связи сертификат DA.
Лидер также отправляет подтверждение блока контракту сортировщика уровня 1 вместе с сертификатом, который контракт использует для проверки блока.
Espresso представляет протокол Gossip для доказательств, чтобы обеспечить более гибкий пользовательский интерфейс. Он предоставляет три варианта завершения транзакции:
В дополнение к вышеупомянутым оптимизациям, Espresso также планирует, чтобы весь набор валидаторов Ethereum сам участвовал в запуске протокола ордера Espresso. Использование одного и того же набора валидаторов обеспечит аналогичную безопасность, а совместное использование ценности с валидаторами L1 будет более безопасным. Кроме того, Espresso также может воспользоваться решением для повторного стейкинга ETH, предоставляемым EigenLayer.
Радиус
Radius создает ненадежный общий уровень упорядочения на основе доказательств с нулевым разглашением, фокусируясь на решении проблемы MEV в L2, поскольку доход L2 в основном поступает от блочного пространства. Компромисс, который следует учитывать, — это баланс между доходами MEV и L2. Цель Radius — устранить MEV, который вреден для пользователей, и предлагает двухуровневый сервис.
Верхний уровень предназначен для обычных пользовательских транзакций и обеспечивает криптографическую защиту от нежелательных MEV с помощью головоломок с временной блокировкой. В частности, он использует технологию Практического проверяемого отложенного шифрования (PVDE), которая будет генерировать доказательства с нулевым разглашением для головоломок с временной блокировкой на основе RSA за 5 секунд. Этот метод обеспечивает практическое решение для защиты пользователей от вредных MEV. Короче говоря, содержимое транзакции не может быть известно, пока секвенсор не определит порядок транзакций.
Базовый уровень предназначен для строителей блоков и позволяет им участвовать в деятельности, приносящей доход, одновременно смягчая негативное влияние MEV.
Сводки на основе
Сворачивание на основе — это концепция, недавно предложенная Джастином Дрейком, в которой разработчики блоков L1 сотрудничают с поисковиками и разработчиками L1 для включения блоков сворачивания в следующий блок L1 без разрешения. Его можно рассматривать как сеть общих секвенсоров на L1. Преимущества и недостатки агрегации на основе очевидны.
Положительным моментом является то, что в основе Rollup используются живость и децентрализация, обеспечиваемые L1, а его реализация проста и эффективна. Rollup также экономически совместим с L1. Однако это не означает, что накопительный пакет на базе ставит под угрозу его суверенитет. Несмотря на то, что MEV передан L1, накопительный пакет по-прежнему может владеть токенами управления и взимать базовую плату. Исходя из этой гипотезы, агрегация на основе может воспользоваться этими преимуществами, добиться превосходства и, в конечном счете, максимизировать отдачу.
в заключение
Глядя на предложенные предложения, видно, что до децентрализации Rollup еще далеко. Некоторые из этих предложений все еще находятся на стадии проекта и требуют дальнейшего обсуждения, в то время как для других разработаны только предварительные спецификации. Все эти сценарии необходимо реализовать и тщательно протестировать.
Хотя некоторые накопительные пакеты могут не предлагать в явном виде соответствующее децентрализованное решение, они часто включают механизмы обхода для устранения единых точек отказа из-за централизованных заказчиков. Например, zkSync предоставляет метод FullExit, который позволяет пользователям выводить свои средства напрямую из L1. Когда система переходит в режим исхода и не может обрабатывать новые блоки, пользователь может инициировать операцию вывода средств.
Чтобы обеспечить устойчивость к цензуре, эти накопительные пакеты часто также позволяют пользователям отправлять транзакции непосредственно на L1. Например, zkSync использует приоритетную очередь для таких транзакций, отправленных на L1. Точно так же Polygon zkEVM включает принудительный пакетный метод в контракт L1. Если в течение недели агрегация не происходит, пользователь может вызвать этот метод на уровне L1 и предоставить проверяющей стороне массив байтов транзакции и BathFee.
Несомненно то, что в обозримом будущем децентрализация Rollup будет комбинированным решением, которое может включать в себя упомянутые выше важные решения или некоторые другие инновационные варианты.