Если мы посмотрим на видение и дорожную карту различных решений для объединения, мы обнаружим, что почти все объединения имеют конечную цель.Если эту цель свести к одному предложению: создать стек технологий, предоставить его сообществу, решить проблему расширения блокчейн и, в конечном итоге, децентрализацию технологического стека операций и управления. Это приводит к термину «децентрализованный накопительный пакет».
Так что же такое децентрализация? Каково разделение труда между различными частями системы Rollup? Означает ли децентрализация максимальное количество участников работы системы? Какое влияние окажет централизованный сортировщик? Как должны быть спроектированы общий ордер и локальный консенсус L2? Какова функция уникального прувера в ZK-Rollup? Как будет выглядеть открытая децентрализованная сеть пруверов? Зачем нам аппаратное ускорение zk? Как решить проблему доступности данных? ....
В сообществе ведутся бесконечные дискуссии о децентрализованном объединении, поэтому ECN подготовила серию подкастов-интервью на тему «Децентрализованное объединение» и пригласила выдающихся основателей и исследователей в этой области, чтобы они рассказали о своем понимании децентрализованного объединения.
По мере того, как все больше и больше ликвидности вливается в платформу уровня 2, появляется все больше и больше поставщиков услуг объединения, не только универсальных решений объединения, цепочек объединения для конкретных приложений, но и платформ объединения как услуги. Поэтому все больше и больше людей обеспокоены тем, что очень важная роль «секвенсора» почти во всех накопительных пакетах по-прежнему централизована. Каковы риски централизованного сортировщика? Является ли децентрализованный сортировщик срочной работой?
**Во втором выпуске мы пригласили Яоки Цзя, основателя сети AltLayer Network, Тогрула Магеррамова, исследователя Scroll, и Абдельхамида Бахту, руководителя исследования Starknet, провести круглый стол на тему децентрализованных сортировщиков, чтобы аудитория и читатели можно понять текущий прогресс и дилеммы децентрализованных сортировщиков. **
Гости в этом выпуске:
Яоци Цзя, основатель AltLayer Network, твиттер @jiayaoqi
Ведущий исследователь Starknet Абдельхамид Бахта, твиттер @dimahledba
Прошлое
Вопрос 1: Как децентрализовать Rollup?
Исследователь Arbitrum Патрик МакКорри
Предварительный просмотр
Проблема 3: сеть Prover и аппаратное ускорение zk
Е Чжан, соучредитель Scroll
Лео Фан, соучредитель Cysic
Проблема 4: Доступность данных и децентрализованное хранилище
Ци Чжоу, основатель EthStorage
Слушать
Нажмите, чтобы подписаться на подкаст, чтобы узнать больше:
YouTube:
Микрокосм:
отметка времени
00:49 Яоци представляет себя
01:37 Абдельхамид представляет себя
02:50 Тогрул представляет себя
04:03 Роль сортировщика в роллапе
08:37 Децентрализованный ордер: улучшение взаимодействия с пользователем и решение проблем с живучестью и цензурой
19:43 Как Starknet будет децентрализовать сортировщик
22:59 Как Scroll децентрализует сортировщик
26:34 Разница между консенсусом L2 в контексте Optimistic rollup и zkRollup
32:28 zkRollup децентрализует сортировщик, а также нужно учитывать доказывающий
36:01 На чем основан накопитель?
40:53 Недостатки общего секвенсора и базового накопительного пакета, а также сценарии их применения
49:02 Какое влияние децентрализованный ордер окажет на MEV?
Знакомство гостей
Яоци
Я основатель AltLayer. AltLayer создает платформу «Объединение как услуга», где разработчики просто нажимают несколько кнопок и настраивают параметры. Используя нашу панель запуска или панель управления, они могут быстро запускать накопительные пакеты приложений за считанные минуты. Вот что мы пытаемся сделать сейчас, чтобы предоставить разработчикам общую среду выполнения и функциональность. Мы также предоставляем несколько секвенсоров, несколько систем виртуальных машин и различные системы проверки для разработчиков на выбор.
Абдельхамид
Я работаю в Starkware и возглавляю исследовательскую группу. Цель этой группы в основном состоит в том, чтобы запустить проекты с открытым исходным кодом, которые похожи на исследования, но с инженерной направленностью. Наша цель — работать над проектами с открытым исходным кодом в тесном сотрудничестве с сообществом и людьми из других экосистем. Одним из таких проектов является Madara, который на самом деле является сортировщиком Starknet. Это не только кандидат в общедоступную сеть Starknet, но и секвенсор для цепочки приложений Starknet и Layer3. Это также связано с тем, что сказал предыдущий гость, мы также думаем о том, чтобы предоставить объединение как сервисную функцию, люди могут развернуть свою цепочку приложений Starknet и выбрать различные решения для обеспечения доступности данных несколько модульным образом. До этого я четыре года работал разработчиком ядра Ethereum, в основном отвечая за работу EIP-1559.
Выбор
Я исследователь в Scroll, и мои основные обязанности в Scroll — разработка протоколов, мостов, децентрализация, стимулы и тому подобное. Так что, когда я не пишу в Твиттере, большую часть времени я просто работаю над тем, как децентрализовать протокол или надзирателей, пруверов и тому подобное. Как и Starkware, мы работаем над накопительным пакетом SDK. Таким образом можно выпускать роллап на базе Scroll, модульно использовать разные варианты доступности данных и так далее. Мы все еще рассматриваем вариант, при котором накопительные пакеты, основанные на Scroll SDK, могут использовать сортировщик Scroll, чтобы помочь им достичь децентрализации, не требуя, чтобы каждый накопительный пакет выполнял децентрализацию сам по себе. Конечно, план еще не утвержден. Тем не менее, это тоже направление, над которым мы работаем.
Раздел интервью
тема первая
Объясните сортировщик роллапа?
Абдельхамид
Сортировщик — очень важный компонент в архитектуре layer2, этот компонент получает транзакции от пользователей, затем упаковывает и объединяет их в блоки, выполняет транзакции и так далее. Это очень важно, потому что это компонент, отвечающий за создание блоков, поскольку уровень 2 также является блокчейном с блоками транзакций. Заказчики создают эти блоки, а пруверы подтверждают эти блоки.
Яоци
Как упомянул Абдель, ордер представляет собой комбинацию многих функций в блокчейне. Таким образом, мы можем на самом деле возлагать на заказчика слишком большую ответственность по сравнению с типичным публичным блокчейном. Сначала необходимо собрать все транзакции от пользователей, а затем отсортировать эти транзакции либо по цене газа, либо по принципу «первым пришел – первым обслужен». После этого секвенсор должен выполнить эти транзакции. Как и сейчас, некоторые Layer2 используют EVM (у Starware есть другая виртуальная машина), но в основном секвенсор должен использовать выделенную виртуальную машину для выполнения транзакций и генерации состояния. Затем транзакция достигает стадии предварительного подтверждения, что означает, что если вы видите время подтверждения в одну или две секунды или даже доли секунды, это в основном состояние предварительного подтверждения, завершенное секвенсором. Затем, для большинства сортировщиков, им также необходимо загрузить или опубликовать контрольные точки или хэши состояния в L1. Это подтверждение на уровне L1, которое мы называем доступностью данных. Таким образом, у сортировщика на самом деле много ролей в системе свертки. Но в целом, я думаю, что это самый важный компонент системы свертки.
** Тема 2 **
Почему важен децентрализованный сортировщик? Если мы используем централизованный сортировщик, какие скрытые опасности для пользователей и системы?
Выбор
Прежде всего, нам нужно знать, что кроме Fuel V1 на текущем этапе настоящего накопительного пакета нет, потому что в других накопительных пакетах все еще есть обучающие колеса.
Однако можно сказать, что раз он классифицируется как накопительный, значит, мультиподпись убрана и так далее. Тогда проблема децентрализации сортировщика становится проблемой взаимодействия с пользователем, а не проблемой безопасности. Так что когда говорят, скажем, о децентрализации L1, проблема совсем в другом. Потому что L1 должен предоставлять гарантии для заказов и легких клиентов. Поэтому, если легкий клиент хочет проверить правильность состояния, он должен доверять валидаторам L1. Для сворачивания это не так. Поскольку сортировщик обеспечивает только временную сортировку, которая затем завершается L1. А поскольку накопительные пакеты также гарантированно устойчивы к цензуре, для этого нам не нужна децентрализация.
Итак, есть несколько причин, по которым вам нужен децентрализованный сортировщик. Во-первых, если, скажем, завершение L1 происходит медленно (либо из-за того, что отправленные вами подтверждения действительности слишком медленны, либо из-за механизма периода оспаривания оптимистичных доказательств мошенничества), вам нужно полагаться на что-то для достижения быстрого подтверждения транзакции. На этом этапе быстрого подтверждения, хотя вы можете быть уверены, что Starkware или Scroll вас не обманут, они указывают, что после подтверждения блока реорганизации не будет. Это предположение о доверии. А децентрализация может добавить какие-то экономические гарантии и так далее.
Но исходя из этого, свертка также не имеет гарантии окончательности в реальном времени. По сути, вы можете принудительно упаковать транзакцию через L1, но упаковка этой транзакции занимает несколько часов. Так например, если за обновление отвечает оракул и время колеблется, то в принципе если оракул обновляется час и более, приложения в роллапе будут недоступны. По сути, децентрализация позволяет нам предоставлять более сильные гарантии защиты от цензуры в реальном времени, потому что тогда противнику нужно будет скомпрометировать не одну сущность или несколько сущностей, а всю сеть заказчиков.
Так что для нас децентрализация — это скорее решение для улучшения взаимодействия с пользователем или исправления крайних случаев обновлений оракула и так далее. Вместо того, чтобы предоставлять базовые гарантии безопасности, это то, что делает L1.
Абдельхамид
Да, вопрос о децентрализованном сортировщике, о котором вы упомянули, не совсем совпадает с децентрализованным L1, что я считаю очень важным. Потому что, когда мы видим, что некоторые L1 критикуют централизованные сортировщики, они не рассматривают должным образом компромиссы, на которые идут централизованные сортировщики.
Исходя из этого, я хотел бы добавить что-то, связанное с пользовательским опытом, связанным с активностью. Потому что, когда у вас есть только один сортировщик, вы подвергаетесь большему риску сбоя сортировщика. Таким образом, децентрализованный ордер также повышает отказоустойчивость и живучесть сети. Но даже в централизованном контексте у нас есть хорошая безопасность, когда дело доходит до безопасности. Потому что, когда вы можете форсировать транзакции пакетов через L1, разница между ними заключается только во временной шкале. А наличие децентрализованного сортировщика позволяет вам иметь быстрые гарантии защиты от цензуры, как упомянул Тогрул. Итак, я просто хочу добавить, что для живости также важно иметь децентрализованную сеть заказов.
Яоци
Я хотел бы добавить кое-что. Активность, пожалуй, самое важное, что нам нужно учитывать на данном этапе. Самые последние случаи аирдропов на самых популярных L2, таких как Optimism и Arbitrum, привели к периоду простоя. Поэтому я думаю, что нам нужно решить, как обрабатывать тысячи запросов транзакций в секунду, когда у нас есть только один сортировщик. Даже теоретически, если у вас есть только один узел, он не сможет обрабатывать столько запросов одновременно. Итак, что касается живучести, нам определенно нужно несколько сортировщиков. Единая точка отказа — настоящее препятствие не только для Web3, но даже для Web2 — большая проблема.
Кроме того, существует проблема цензуры. Если у нас есть только один координатор, даже если мы видим, что им может управлять команда, вам все равно нужно доказать, что команда на самом деле не будет проверять транзакции. Иногда злоумышленники могут внести определенные транзакции в черный список. Это децентрализованная система ордера, они также могут пытаться отправлять транзакции через других ордеров. Вот почему в последнее время мы получаем много критики по поводу одиночных сортировщиков.
Помимо этого, есть некоторые другие проблемы, такие как MEV и ранние запуски. В системе с централизованными сортировщиками, особенно для протоколов DeFi, они могут легко проверить мемпул. Вероятно, не в форме лидера, но у них больше шансов следить за сделкой и решать ее.
Этих проблем много по разным причинам, хотя мы видим, что L2 сильно отличается от L1. Но в конечном счете нам все равно нужно сделать его максимально децентрализованным. Таким образом, нам приходится сталкиваться с некоторыми из тех же проблем, что и с общедоступными блокчейнами или L1.
Абдельхамид
Да, я согласен, что децентрализованный сортировщик важен. Но я также хочу сказать, что, как мы все знаем, это не простой вопрос.
Кроме того, **поскольку накопительные пакеты имеют очень специфическую архитектуру с несколькими объектами. Мы говорим об одном заказчике, но есть и прувер, и нам нужно децентрализовать оба. ** Будут некоторые компромиссы и некоторые трудности в том, как оценивать транзакции, потому что для работы сети необходимы разные факторы. Итак, как вы оцениваете сделку? Сортировщик и прувер имеют разные требования к оборудованию, пруверу нужна сверхмощная машина и так далее. Поэтому ценообразование транзакций в децентрализованном мире также является очень сложной проблемой, поэтому нам нужно время, чтобы медленно двигаться вперед.
Таким образом, мы все столкнемся с таким компромиссом: если мы хотим быстро децентрализоваться, нам, возможно, придется взять несколько тренировочных колес и постепенно децентрализовать, потому что, если мы напрямую хотим идеальной архитектуры, это займет несколько лет. Поэтому я думаю, что мы будем придерживаться прагматичного подхода и попытаемся постепенно децентрализовать. По крайней мере, это наш текущий план, например, начать с простого механизма консенсуса BFT, а затем добавить еще один механизм консенсуса в краткосрочной перспективе или что-то в этом роде. Так что я просто хочу сказать, что это не простой вопрос. Потому что очевидно, что существует компромисс между скоростью разработки и тем, насколько архитектура применима к децентрализованной среде.
Тема 3
Как децентрализовать сортировщик?
Абдельхамид
Есть много функций, которые мы хотим децентрализовать, и все они имеют разные компромиссы.
Например, при децентрализации вы хотите внедрить какой-то механизм консенсуса. Однако механизм консенсуса состоит из нескольких частей. Первый — это выборы лидера, то есть как выбрать, кто будет создавать блоки, кто будет заказчиком, ответственным за создание блоков в заданном слоте или в заданное время. ** Команда Starknet планирует максимально использовать уровень 1. То есть в нашем алгоритме выбора лидера мы хотим сделать ставку на уровень 1. Например, у нас есть токены, а залог будет происходить на смарт-контракте Layer1 Ethereum, который используется для определения механизма избрания лидера. ** Это означает, что нам нужно какое-то взаимодействие, когда заказчик L2 будет запрашивать смарт-контракт Ethereum, чтобы узнать, кто будет следующим лидером или что-то в этом роде. Так что, очевидно, нужна какая-то случайность и другие вещи. Так что это не простой вопрос. Но это первая часть. Тогда вам нужно иметь механизм для самого консенсуса. Есть несколько вариантов: либо механизм с самой длинной цепью, либо BFT, либо их гибрид. Как и у Ethereum, у него есть LMG Ghost и Casper FFG для окончательности.
Так что мы могли бы применить прагматичный подход и начать с BFT. почему? Когда уровень 2 рассматривает децентрализацию, наша цель — не иметь такого большого масштаба сортировщика, как уровень 1. Например, в Ethereum цель состоит в том, чтобы привлечь миллионы валидаторов. В этом случае вы не можете просто использовать механизм BFT, потому что это будет очень плохо по эффективности, и это вызовет очень большие проблемы. Например, если в сети Биткойн есть проблема, если это механизм BFT, цепочка полностью остановится. Но это не так, сеть Биткойн продолжает создавать блоки, атакуется только механизм финализации.
Но на уровне 2, если целью является от нескольких сотен до 1000 сортировщиков, было бы неплохо начать с механизма BFT. Итак, у нас есть механизм выбора лидера, затем консенсус, а затем есть еще две части, но я оставлю это для других гостей, чтобы они продолжали добавлять. Но две другие части — это обновление состояния и генерация доказательств.
Выбор
Во-первых, в L2 децентрализация — это многогранная проблема, описанная Абделем. Особенно в zkRollup, потому что есть пруверы и ордера, между ними нужно координировать, нужно децентрализовать обоих. Эта проблема полностью отличается от L1.
Еще одно отличие состоит в том, что в L2 вся ваша задача состоит в том, чтобы убедить базовый мост в правильности консенсуса, а не в том, чтобы убедить любое количество других узлов. Вы, очевидно, должны сделать то же самое, но ваше основное внимание должно быть сосредоточено на самом мосту.
В настоящее время мы работаем в двух разных направлениях. Во-первых, я думаю, как и все остальные, мы работаем над протоколом BFT. Это не очень эффективно, и есть некоторые перегибы, которые необходимо проработать. Мы придумали грубое решение, но оно все еще не оптимально. Например, один из вопросов: как сбалансировать поощрения между сортировщиками и пруверами? Поскольку заказчик контролирует MEV, а прувер не имеет доступа к MEV, у людей есть стимул управлять заказчиком вместо прувера. Но на самом деле нам нужно больше пруверов, чем заказчиков, так как же сбалансировать поощрения между ними? Это одна из тех проблем.
Второе решение, над которым мы работаем, — это другое направление. Помните, что все может измениться. Каждый день появляются новые предложения. Например, в последнее время много говорят о свертывании на основе и о том, как можно полностью передать сортировку в L1. Второе направление состоит в том, чтобы полностью отказаться от сортировщика и использовать какой-либо внешний сборщик. Например, сборщики Эфириума или Flashbots SUAVE и т. д. предлагают упорядоченные блоки, а затем проводят консенсус внутри прувера. Преимущество здесь в том, что вам не нужно иметь дело со стимулами, потому что в основном вы можете использовать PBS в протоколе, и это создает более простой протокол. Но недостаток в том, что поскольку нам нужно большое количество пруверов (потому что мы можем доказывать параллельно), запустить с ними классический протокол BFT довольно сложно. Итак, вопрос в том, как оптимизировать существующий протокол BFT для работы с сотнями или даже тысячами пруверов? И это не простой вопрос.
Необходимо ли введение консенсуса L2 для децентрализованного ордера?
Яоци
Я могу примерно ответить на этот вопрос, потому что мы совсем недавно выкатили что-то подобное.
Так что введение консенсуса не зависит от того, хотим мы этого или нет. Если у вас много заказчиков или даже просто узлов, вы должны заставить их согласиться. Это действительно зависит от ваших предположений. Если это византийское предположение, мы можем использовать BFT или любой существующий византийский протокол консенсуса. Если это невизантийская установка, например, если мы просто предполагаем, что узел может быть только онлайн и оффлайн, и что он не может действовать злонамеренно, тогда мы можем использовать протокол Raft или какой-либо другой более быстрый протокол консенсуса. Но в любом случае, если у нас есть группа заказчиков или пруверов, если мы хотим организовать их вместе для производства блоков в течение определенного периода времени, тогда у вас должен быть согласованный протокол вокруг них.
Итак, как только что упомянули Тогрул и Абдель, я считаю, что есть много предложений и тем для исследований о том, как мы можем внедрить децентрализованную систему заказов или доказательств. Итак, поскольку мы только что запустили тестовую сеть для мультисортировочной накопительной системы (в настоящее время поддерживает только доказательства мошенничества для Оптимистичных накопительных пакетов), основываясь на нашем опыте проектирования и реализации, я могу кое-что рассказать о трудностях. Как только что упомянул Тогрул, трудность заключается не в самом протоколе консенсуса, а в других вещах, например в части доказательства. Потому что, если это один сортировщик, вам не нужно много узлов. Мы можем думать об этом как о EVM, виртуальной машине. Итак, просто извлекайте транзакции и выполняйте, выполняйте переходы между состояниями. Доказывающая сторона отвечает за создание доказательств перехода состояния предыдущего набора транзакций. Однако, если мы запустим протокол консенсуса для сопоставления и проверки при свертывании, то нам нужно будет ввести в него дополнительную логику консенсуса. Кроме того, вам также нужна система проверки для консенсусного протокола. Следовательно, это потребует много работы для создания системы доказательств. Затем, как только вы сгенерируете доказательство, вы сможете легко проверить его на L1 Ethereum.
Вот почему, когда мы запустили первую тестовую сеть с несколькими заказами, оптимистичный накопитель имел некоторые преимущества в этом отношении. В общем, вы можете упростить многие вещи, например, не учитывать часть доказательства валидности. Как и мы, мы в основном сравниваем все с WASM. Итак, в конце концов, это инструкция WASM. Итак, проверив эти инструкции WASM, относительно легко проверить, используя код Solidity. Если бы мы просто переопределили все интерпретации инструкций WASM на Ethereum.
Но в целом проблема не единичная. Если у нас есть решение проблемы, соответственно, будет еще какая-то доработка, которую нужно решать параллельно. Конечно, будут проблемы с MEV, например, как справедливо распределять MEV. Вы можете назначить всех заказчиков и пруверов в зависимости от того, создали ли они блок или проверили блок. Но, в конце концов, это действительно сочетание многих вопросов, не только технических, но и экономических.
И мы должны помнить, что L2 предлагается, потому что мы хотим значительно снизить стоимость газа. Поэтому у нас не может быть так много узлов. Даже при создании доказательств L2 может быть дороже, чем L1. Поэтому нам действительно нужно выработать сбалансированный подход к такого рода проблемам.
Абдельхамид
Я хотел бы добавить еще один момент. Во-первых, в настоящее время нет фактического доказательства мошенничества без разрешения для оптимистичных накопительных сумм. И я продолжаю подчеркивать это при каждом удобном случае, потому что важно честно говорить об этом при сравнении. Так что они вовсе не L2. Это первое.
Затем я хотел бы добавить кое-что об асинхронности между сортировкой и доказательствами, потому что это очень важно. Как вы сказали, мы хотим оптимизировать сортировку, потому что на данный момент это узкое место для всех решений. Но это нормально в контексте централизованной сортировки, потому что мы знаем, что сортировщик будет производить только переходы значений, и мы сможем их проверить. Но в контексте децентрализованной сортировки это будет сложнее, потому что, возможно, ваш сортировщик сможет выдать что-то, что невозможно проверить. Тогда вам нужно будет иметь дело с этим позже.
В контексте централизованной сортировки, чтобы оптимизировать сортировку, поскольку нам не нужно генерировать доказательства в процессе сортировки, мы можем попытаться сделать это на локальной скорости, что мы и хотим сделать. Переведите Cairo на машинный язык низкого уровня, такой как LLVM, и работайте на сортировщике очень быстро. Затем вы можете доказать асинхронно. И самое классное в доказательствах то, что их можно делать параллельно. Массивная распараллеливание достигается путем доказательства возможности рекурсии. Поэтому мы сможем догнать сортировщик по скорости. Но это сложно, когда децентрализовано, потому что нам нужно гарантировать, что ордер производит только действительные переходы состояний.
Выбор
Добавлю, что не знаю, что здесь делает Старкнет. Но для нас, я думаю, это общее предположение каждого zkRollup, что если вы децентрализуете сортировщик, ваша система проверки должна быть в состоянии обрабатывать недопустимые пакеты. Таким образом, если, скажем, вы отправляете пакет с недействительной подписью, вы должны быть в состоянии доказать, что полученное состояние эквивалентно начальному состоянию. Так что в любом случае будут некоторые накладные расходы. Речь идет о том, как вы минимизируете вероятность этого.
Абдельхамид
Да все верно. Вот почему мы представили Sierra в Cairo 1, чтобы все можно было проверить. Это промежуточное представление гарантирует, что каждую программу Cairo 1 можно проверить, чтобы мы могли включить возвратную транзакцию.
Что такое базовый накопительный пакет?
Яоци
Первоначально накопительный пакет был взят из сообщения в блоге Джастина Дрейка на форумах Ethereum. Одна из его идей заключается в том, что мы можем повторно использовать некоторые верификаторы Ethereum для проверки транзакций свертки, чтобы нам не требовалась отдельная группа узлов для проверки разных транзакций свертки. В частности, в будущем у нас будет много накопительных пакетов, включая универсальные накопительные пакеты и множество накопительных пакетов для конкретных приложений. Так что в этом случае было бы здорово, если бы мы могли найти общее место, такое как пул валидаторов Ethereum, для проверки этих транзакций.
Конечно, это всего лишь идея, так как она также вносит много технических сложностей. Например, теоретически мы могли бы потребовать, чтобы валидаторы Ethereum проверяли транзакции свертки, но очень сложно получить логику проверки сверток, объединенных или встроенных в сам протокол Ethereum. Мы называем это проверкой внутри протокола, для которой требуется хардфорк узлов Ethereum. Конечно, в этом случае мы можем проверить некоторые накопительные транзакции. Но если мы это сделаем, вы увидите проблемы. Это немного похоже на то, что мы хотим, чтобы свертывание L2 разделило давление Ethereum, но в конце концов мы по-прежнему просим валидаторов Ethereum взять на себя часть работы, переложенной на L2. Поэтому многие люди говорят о том, как мы можем это сделать.
Затем мы поговорили с Барнабе, исследователем из Ethereum Foundation, который в настоящее время работает над PBS. Это предложение Ethereum, которое состоит в том, чтобы разделить задачу валидаторов на несколько ролей, создателей и предлагающих. Теперь у нас есть Flashbots, которые берут на себя роль строителей в PBS, они составляют все блоки и отправляют их создателям Ethereum. Поэтому, как только эти блоки будут упакованы в сеть Ethereum, создатели также получат вознаграждение. Как в таком случае вознаграждать этих валидаторов из сети Ethereum? Они также отвечают за проверку свертки.
Одним из решений является «перестейкинг», о котором вы, возможно, много слышали от EigenLayer или некоторых других протоколов. Пользователи могут повторно стейкать ETH в других сортировочных сетях. Или вознаградите валидаторов Ethereum за то, что они действительно запустили программное обеспечение для проверки свертки. При этом они могут быть вознаграждены как из L2, так и через протокол рестейкинга. До сих пор было много предложений по этому поводу, но в целом это идея о том, как можно перепрофилировать существующие валидаторы Ethereum. Как мы можем повторно использовать существующий ETH, чтобы помочь вступить в новую эру накопительных систем или систем L2? Таким образом, он в основном пытается упростить множество вещей для проекта объединения. Если объединению нужен новый сортировщик, если им нужен новый источник обеспечения, они могут повторно использовать существующую инфраструктуру или существующее обеспечение. Вот почему он построен на основе Ethereum, а затем можно повторно использовать дополнительную инфраструктуру и стейкинг для объединения и L2.
Недостатки общего секвенсора и базового накопительного пакета, а также сценарии их применения.
Выбор
Я хочу пожаловаться на это предложение, меня не убеждает предложение, связанное с общим секвенсором. Конечно, они все еще находятся в зачаточном состоянии, и если в будущем эти разработки улучшатся, вполне возможно, что я их поддержу. Просто нынешняя форма меня не убеждает. Есть много причин.
Во-первых, для меня основная ценность общего сортировщика заключается в том, чтобы позволить пользователям получить атомарную компоновку между универсальными накопительными пакетами, такими как Scroll или Starknet. Но проблема в том, что если у вас есть атомарная компонуемость, то ваша свертка будет такой же окончательной, как и самая медленная свертка, с которой вы комбинируете. Таким образом, при условии, что прокрутка объединена с оптимистическим свертыванием, срок действия прокрутки составит семь дней. В то время как основное ценностное предложение ZKRollup заключается в достижении относительно быстрой окончательности, пользователи могут вывести средства на L1 в течение нескольких минут. И в этом случае, в основном отказаться от этого.
Другим недостатком является то, что если вам нужна окончательность вне цепочки, вам нужно запустить узел L2, и пока данные, отправленные в цепочку, завершаются L1, вы получаете окончательность локально в L2. Если каждый объединенный L2 не запускает полный узел, добиться локальной финализации практически невозможно. Это означает, что запуск этой системы может быть дороже, чем запуск такой системы, как Solana, потому что у вас есть несколько полных узлов, работающих одновременно, с их собственными накладными расходами и так далее.
Поэтому по этим причинам я просто не думаю, что это имеет смысл для L2. Для L3 немного по-другому, потому что если кто-то хочет построить цепочку для конкретного приложения и не хочет иметь дело с децентрализацией. Допустим, я создаю игру, и я просто хочу заниматься ее созданием, тогда я могу передать децентрализованную работу на аутсорсинг. Но я не думаю, что это имеет смысл для L2 на данный момент.
Что касается базового свертки, у меня тоже есть свои опасения. Например, как вы делите прибыль MEV с пруверами? Потому что, если не учитывать проблему распределения, в основном L1 может получить всю прибыль от MEV. Еще одна мелочь заключается в том, что время его подтверждения равно времени подтверждения L1, что составляет 12 минут, что не может быть быстрее. Другая проблема заключается в том, что, поскольку это не требует разрешений, несколько искателей могут одновременно отправлять пакеты транзакций, а это означает, что это может привести к централизованным результатам. Потому что строители заинтересованы в том, чтобы включать свои транзакции, если один поисковик подключается легче, чем другие. Следовательно, это может привести к тому, что только один Искатель предложит партии для L2 в конце, что является не очень хорошим решением, потому что, если это произойдет, мы, по сути, вернемся к исходной точке.
Яоци
Интересно, что я только что разговаривал с Беном, основателем Espresso, на прошлой неделе. Мы много обсуждаем это в теме общих сортировщиков. Как упомянул Тогрул, я думаю, что есть некоторая неопределенность в отношении сценариев использования общей системы заказов. В основном это связано с тем, что для L2 общего назначения у нас обычно нет большого количества сортировщиков из-за эффективности, сложности и экономии. И я по-прежнему считаю, что независимо от того, идет ли речь об общем секвенсоре, объединении на основе или повторном сборе, наилучшим вариантом использования в основном является RAS (обновление как услуга) или такие платформы, на которых мы можем развертывать множество обновлений. Честно говоря, нам не нужна большая сеть сортировки, если не так много сверток. У этих объединений уже есть свои собственные системы сортировки и уже есть свои сообщества или партнеры, когда есть только несколько общих L2. Им действительно не нужно иметь отдельную и стороннюю сеть. Кроме того, это нагрузка на стороннюю сеть, потому что приходится настраивать для каждого L2, а у каждого L2 свой тестовый стек. Это требует множества изменений в вашей собственной сети.
Но в то же время, как упомянул Тогрул, для некоторых особых случаев использования. Например, если мы хотим иметь некоторую функциональную совместимость на уровне сортировщика, потенциальным решением могут стать общие сортировщики. Например, один и тот же сортировщик используется для нескольких сверток. В этом случае этот сортировщик может в основном обрабатывать некоторые кросс-сводные транзакции, чтобы обеспечить атомарность кросс-цепочек между свертками A, B и C.
Но вы также можете увидеть проблему здесь, когда я описываю ситуацию. Если бы у нас действительно было много таких общих секвенсоров, они снова стали бы узким местом и новой единой точкой отказа. Мы даем слишком много власти этим так называемым общим заказчикам. Они становятся все более похожими на сеть, контролирующую множество сверток. Наконец, нам снова нужно придумать способ децентрализации этого общего сортировщика.
Но в любом случае, я думаю, это хорошо, что люди постепенно обнаруживают все больше и больше проблем и предлагают все больше и больше решений. В общем, интересно каждый день видеть, что нового в этой области. Со всеми этими новыми решениями мы, по крайней мере, находимся на правильном пути к полной децентрализации всего пространства объединения.
Абдель
Да, я согласен с вами обоими. Я думаю, что это имеет больше смысла для Layer3 и Lisk, потому что они больше не хотят брать на себя ответственность за стимулирование децентрализованной сети и им нужно найти партнеров для запуска таких вещей, как сортировщики. Поэтому я думаю, что для Lisk это имеет смысл. Но, как и Тогрул, я пока не думаю, что это имеет смысл для Layer2.
Тема 4
Какое влияние окажет децентрализованный ордер на MEV?
Абдель
Для Starknet, в контексте централизации, мы не делаем никаких MEV и используем модель «первым пришел — первым обслужен». То есть в контексте децентрализации, конечно, позже будет введено больше MEV. Но пока рано говорить, какое соотношение, потому что оно также зависит от конструкции механизма консенсуса и других аспектов.
Выбор
Но дело в том, что даже если вы не используете MEV, в Старкнете все еще может происходить MEV. Ну, децентрализация сама по себе на самом деле не уменьшает MEV и не увеличивает MEV. Конечно, если вы применяете какой-то протокол честного заказа или пороговое шифрование, например, то да, вы минимизируете MEV. Но полностью избавиться от него нельзя. Моя философия такова: MEV нельзя устранить. Но допустим, вы просто создаете консенсус BFT или строите что-то поверх консенсуса BFT. На самом деле это никак не влияет на MEV. MEV все еще существует, вопрос должен заключаться в том, как поисковик работает с сортировщиком, чтобы извлечь этот MEV.
Яоци
Проблема в том, что даже в модели «первым пришел — первым обслужен» есть непростые моменты. Как только мы открываем мемпул некоторым искателям, у них все еще есть преимущество, позволяющее играть больше. Например, для секвенсоров они эквивалентны ожиданию у двери вашего офиса. Так что в этом случае, как только они увидят какую-то арбитражную возможность, а не только форвардную или сэндвич-атаку, как только пользователь отправит транзакцию, они сразу смогут увидеть ее в мемпуле. Таким образом, они могут быстро размещать свои сделки впереди других. Таким образом, они имеют преимущество перед другими поисковиками.
Но возвращаясь к децентрализации, я думаю, что в основном речь идет о сопротивлении цензуре, как мы обсуждали в начале. Секвенсорами управляет команда. Команда может сказать, что они справедливы ко всем. Но это не запрещено в коде. Итак, если бы у нас была сеть P2P, было бы здорово, если бы мы чувствовали, что эти узлы проверяют мою транзакцию, а затем мы можем отправить ее другим узлам. Итак, речь действительно идет о честности обработки транзакций на уровне L2.
Что касается MEV, потому что в последнее время в дополнение к MEV, генерируемым в рамках одного объединения, есть несколько MEV, генерируемых через мосты. В этой относительно децентрализованной сортировочной сети у вас будет больше возможностей для извлечения MEV. Предполагая, что у нас есть общая сеть заказов, если вы можете каким-то образом повлиять на общего заказа, чтобы изменить порядок транзакций, в основном у вас есть большое преимущество перед всеми остальными.
У общей сети секвенсора есть преимущества и недостатки. С положительной стороны, мы можем еще больше децентрализовать систему ранжирования. Но с другой стороны, у каждого есть возможность быть сортировщиком. Таким образом, они могут делать все, что хотят, и это снова темный лес. Итак, мы ввели децентрализацию, а потом нам пришлось столкнуться с теми же проблемами, с которыми мы столкнулись в Ethereum. Вот почему Flashbots и ребята из Ethereum Foundation хотят продвигаться вперед с PBS, разделять разработчиков и разработчиков, а затем пытаться иметь единое решение на стороне разработчиков.
Поэтому, когда мы смотрим на проблему, это не просто проблема. Это уже не проблема один на один, а один на шесть, и больше.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Диалог с командами AltLayer, Scroll, Starknet: Shared Sequencer и L2 Consensus
Введение
Если мы посмотрим на видение и дорожную карту различных решений для объединения, мы обнаружим, что почти все объединения имеют конечную цель.Если эту цель свести к одному предложению: создать стек технологий, предоставить его сообществу, решить проблему расширения блокчейн и, в конечном итоге, децентрализацию технологического стека операций и управления. Это приводит к термину «децентрализованный накопительный пакет».
Так что же такое децентрализация? Каково разделение труда между различными частями системы Rollup? Означает ли децентрализация максимальное количество участников работы системы? Какое влияние окажет централизованный сортировщик? Как должны быть спроектированы общий ордер и локальный консенсус L2? Какова функция уникального прувера в ZK-Rollup? Как будет выглядеть открытая децентрализованная сеть пруверов? Зачем нам аппаратное ускорение zk? Как решить проблему доступности данных? ....
В сообществе ведутся бесконечные дискуссии о децентрализованном объединении, поэтому ECN подготовила серию подкастов-интервью на тему «Децентрализованное объединение» и пригласила выдающихся основателей и исследователей в этой области, чтобы они рассказали о своем понимании децентрализованного объединения.
По мере того, как все больше и больше ликвидности вливается в платформу уровня 2, появляется все больше и больше поставщиков услуг объединения, не только универсальных решений объединения, цепочек объединения для конкретных приложений, но и платформ объединения как услуги. Поэтому все больше и больше людей обеспокоены тем, что очень важная роль «секвенсора» почти во всех накопительных пакетах по-прежнему централизована. Каковы риски централизованного сортировщика? Является ли децентрализованный сортировщик срочной работой?
**Во втором выпуске мы пригласили Яоки Цзя, основателя сети AltLayer Network, Тогрула Магеррамова, исследователя Scroll, и Абдельхамида Бахту, руководителя исследования Starknet, провести круглый стол на тему децентрализованных сортировщиков, чтобы аудитория и читатели можно понять текущий прогресс и дилеммы децентрализованных сортировщиков. **
Гости в этом выпуске:
Прошлое
Вопрос 1: Как децентрализовать Rollup?
Предварительный просмотр
Проблема 3: сеть Prover и аппаратное ускорение zk
Проблема 4: Доступность данных и децентрализованное хранилище
Слушать
Нажмите, чтобы подписаться на подкаст, чтобы узнать больше:
YouTube:
Микрокосм:
отметка времени
00:49 Яоци представляет себя
01:37 Абдельхамид представляет себя
02:50 Тогрул представляет себя
04:03 Роль сортировщика в роллапе
08:37 Децентрализованный ордер: улучшение взаимодействия с пользователем и решение проблем с живучестью и цензурой
19:43 Как Starknet будет децентрализовать сортировщик
22:59 Как Scroll децентрализует сортировщик
26:34 Разница между консенсусом L2 в контексте Optimistic rollup и zkRollup
32:28 zkRollup децентрализует сортировщик, а также нужно учитывать доказывающий
36:01 На чем основан накопитель?
40:53 Недостатки общего секвенсора и базового накопительного пакета, а также сценарии их применения
49:02 Какое влияние децентрализованный ордер окажет на MEV?
Знакомство гостей
Яоци
Я основатель AltLayer. AltLayer создает платформу «Объединение как услуга», где разработчики просто нажимают несколько кнопок и настраивают параметры. Используя нашу панель запуска или панель управления, они могут быстро запускать накопительные пакеты приложений за считанные минуты. Вот что мы пытаемся сделать сейчас, чтобы предоставить разработчикам общую среду выполнения и функциональность. Мы также предоставляем несколько секвенсоров, несколько систем виртуальных машин и различные системы проверки для разработчиков на выбор.
Абдельхамид
Я работаю в Starkware и возглавляю исследовательскую группу. Цель этой группы в основном состоит в том, чтобы запустить проекты с открытым исходным кодом, которые похожи на исследования, но с инженерной направленностью. Наша цель — работать над проектами с открытым исходным кодом в тесном сотрудничестве с сообществом и людьми из других экосистем. Одним из таких проектов является Madara, который на самом деле является сортировщиком Starknet. Это не только кандидат в общедоступную сеть Starknet, но и секвенсор для цепочки приложений Starknet и Layer3. Это также связано с тем, что сказал предыдущий гость, мы также думаем о том, чтобы предоставить объединение как сервисную функцию, люди могут развернуть свою цепочку приложений Starknet и выбрать различные решения для обеспечения доступности данных несколько модульным образом. До этого я четыре года работал разработчиком ядра Ethereum, в основном отвечая за работу EIP-1559.
Выбор
Я исследователь в Scroll, и мои основные обязанности в Scroll — разработка протоколов, мостов, децентрализация, стимулы и тому подобное. Так что, когда я не пишу в Твиттере, большую часть времени я просто работаю над тем, как децентрализовать протокол или надзирателей, пруверов и тому подобное. Как и Starkware, мы работаем над накопительным пакетом SDK. Таким образом можно выпускать роллап на базе Scroll, модульно использовать разные варианты доступности данных и так далее. Мы все еще рассматриваем вариант, при котором накопительные пакеты, основанные на Scroll SDK, могут использовать сортировщик Scroll, чтобы помочь им достичь децентрализации, не требуя, чтобы каждый накопительный пакет выполнял децентрализацию сам по себе. Конечно, план еще не утвержден. Тем не менее, это тоже направление, над которым мы работаем.
Раздел интервью
тема первая
Объясните сортировщик роллапа?
Абдельхамид
Сортировщик — очень важный компонент в архитектуре layer2, этот компонент получает транзакции от пользователей, затем упаковывает и объединяет их в блоки, выполняет транзакции и так далее. Это очень важно, потому что это компонент, отвечающий за создание блоков, поскольку уровень 2 также является блокчейном с блоками транзакций. Заказчики создают эти блоки, а пруверы подтверждают эти блоки.
Яоци
Как упомянул Абдель, ордер представляет собой комбинацию многих функций в блокчейне. Таким образом, мы можем на самом деле возлагать на заказчика слишком большую ответственность по сравнению с типичным публичным блокчейном. Сначала необходимо собрать все транзакции от пользователей, а затем отсортировать эти транзакции либо по цене газа, либо по принципу «первым пришел – первым обслужен». После этого секвенсор должен выполнить эти транзакции. Как и сейчас, некоторые Layer2 используют EVM (у Starware есть другая виртуальная машина), но в основном секвенсор должен использовать выделенную виртуальную машину для выполнения транзакций и генерации состояния. Затем транзакция достигает стадии предварительного подтверждения, что означает, что если вы видите время подтверждения в одну или две секунды или даже доли секунды, это в основном состояние предварительного подтверждения, завершенное секвенсором. Затем, для большинства сортировщиков, им также необходимо загрузить или опубликовать контрольные точки или хэши состояния в L1. Это подтверждение на уровне L1, которое мы называем доступностью данных. Таким образом, у сортировщика на самом деле много ролей в системе свертки. Но в целом, я думаю, что это самый важный компонент системы свертки.
** Тема 2 **
Почему важен децентрализованный сортировщик? Если мы используем централизованный сортировщик, какие скрытые опасности для пользователей и системы?
Выбор
Прежде всего, нам нужно знать, что кроме Fuel V1 на текущем этапе настоящего накопительного пакета нет, потому что в других накопительных пакетах все еще есть обучающие колеса.
Однако можно сказать, что раз он классифицируется как накопительный, значит, мультиподпись убрана и так далее. Тогда проблема децентрализации сортировщика становится проблемой взаимодействия с пользователем, а не проблемой безопасности. Так что когда говорят, скажем, о децентрализации L1, проблема совсем в другом. Потому что L1 должен предоставлять гарантии для заказов и легких клиентов. Поэтому, если легкий клиент хочет проверить правильность состояния, он должен доверять валидаторам L1. Для сворачивания это не так. Поскольку сортировщик обеспечивает только временную сортировку, которая затем завершается L1. А поскольку накопительные пакеты также гарантированно устойчивы к цензуре, для этого нам не нужна децентрализация.
Итак, есть несколько причин, по которым вам нужен децентрализованный сортировщик. Во-первых, если, скажем, завершение L1 происходит медленно (либо из-за того, что отправленные вами подтверждения действительности слишком медленны, либо из-за механизма периода оспаривания оптимистичных доказательств мошенничества), вам нужно полагаться на что-то для достижения быстрого подтверждения транзакции. На этом этапе быстрого подтверждения, хотя вы можете быть уверены, что Starkware или Scroll вас не обманут, они указывают, что после подтверждения блока реорганизации не будет. Это предположение о доверии. А децентрализация может добавить какие-то экономические гарантии и так далее.
Но исходя из этого, свертка также не имеет гарантии окончательности в реальном времени. По сути, вы можете принудительно упаковать транзакцию через L1, но упаковка этой транзакции занимает несколько часов. Так например, если за обновление отвечает оракул и время колеблется, то в принципе если оракул обновляется час и более, приложения в роллапе будут недоступны. По сути, децентрализация позволяет нам предоставлять более сильные гарантии защиты от цензуры в реальном времени, потому что тогда противнику нужно будет скомпрометировать не одну сущность или несколько сущностей, а всю сеть заказчиков.
Так что для нас децентрализация — это скорее решение для улучшения взаимодействия с пользователем или исправления крайних случаев обновлений оракула и так далее. Вместо того, чтобы предоставлять базовые гарантии безопасности, это то, что делает L1.
Абдельхамид
Да, вопрос о децентрализованном сортировщике, о котором вы упомянули, не совсем совпадает с децентрализованным L1, что я считаю очень важным. Потому что, когда мы видим, что некоторые L1 критикуют централизованные сортировщики, они не рассматривают должным образом компромиссы, на которые идут централизованные сортировщики.
Исходя из этого, я хотел бы добавить что-то, связанное с пользовательским опытом, связанным с активностью. Потому что, когда у вас есть только один сортировщик, вы подвергаетесь большему риску сбоя сортировщика. Таким образом, децентрализованный ордер также повышает отказоустойчивость и живучесть сети. Но даже в централизованном контексте у нас есть хорошая безопасность, когда дело доходит до безопасности. Потому что, когда вы можете форсировать транзакции пакетов через L1, разница между ними заключается только во временной шкале. А наличие децентрализованного сортировщика позволяет вам иметь быстрые гарантии защиты от цензуры, как упомянул Тогрул. Итак, я просто хочу добавить, что для живости также важно иметь децентрализованную сеть заказов.
Яоци
Я хотел бы добавить кое-что. Активность, пожалуй, самое важное, что нам нужно учитывать на данном этапе. Самые последние случаи аирдропов на самых популярных L2, таких как Optimism и Arbitrum, привели к периоду простоя. Поэтому я думаю, что нам нужно решить, как обрабатывать тысячи запросов транзакций в секунду, когда у нас есть только один сортировщик. Даже теоретически, если у вас есть только один узел, он не сможет обрабатывать столько запросов одновременно. Итак, что касается живучести, нам определенно нужно несколько сортировщиков. Единая точка отказа — настоящее препятствие не только для Web3, но даже для Web2 — большая проблема.
Кроме того, существует проблема цензуры. Если у нас есть только один координатор, даже если мы видим, что им может управлять команда, вам все равно нужно доказать, что команда на самом деле не будет проверять транзакции. Иногда злоумышленники могут внести определенные транзакции в черный список. Это децентрализованная система ордера, они также могут пытаться отправлять транзакции через других ордеров. Вот почему в последнее время мы получаем много критики по поводу одиночных сортировщиков.
Помимо этого, есть некоторые другие проблемы, такие как MEV и ранние запуски. В системе с централизованными сортировщиками, особенно для протоколов DeFi, они могут легко проверить мемпул. Вероятно, не в форме лидера, но у них больше шансов следить за сделкой и решать ее.
Этих проблем много по разным причинам, хотя мы видим, что L2 сильно отличается от L1. Но в конечном счете нам все равно нужно сделать его максимально децентрализованным. Таким образом, нам приходится сталкиваться с некоторыми из тех же проблем, что и с общедоступными блокчейнами или L1.
Абдельхамид
Да, я согласен, что децентрализованный сортировщик важен. Но я также хочу сказать, что, как мы все знаем, это не простой вопрос.
Кроме того, **поскольку накопительные пакеты имеют очень специфическую архитектуру с несколькими объектами. Мы говорим об одном заказчике, но есть и прувер, и нам нужно децентрализовать оба. ** Будут некоторые компромиссы и некоторые трудности в том, как оценивать транзакции, потому что для работы сети необходимы разные факторы. Итак, как вы оцениваете сделку? Сортировщик и прувер имеют разные требования к оборудованию, пруверу нужна сверхмощная машина и так далее. Поэтому ценообразование транзакций в децентрализованном мире также является очень сложной проблемой, поэтому нам нужно время, чтобы медленно двигаться вперед.
Таким образом, мы все столкнемся с таким компромиссом: если мы хотим быстро децентрализоваться, нам, возможно, придется взять несколько тренировочных колес и постепенно децентрализовать, потому что, если мы напрямую хотим идеальной архитектуры, это займет несколько лет. Поэтому я думаю, что мы будем придерживаться прагматичного подхода и попытаемся постепенно децентрализовать. По крайней мере, это наш текущий план, например, начать с простого механизма консенсуса BFT, а затем добавить еще один механизм консенсуса в краткосрочной перспективе или что-то в этом роде. Так что я просто хочу сказать, что это не простой вопрос. Потому что очевидно, что существует компромисс между скоростью разработки и тем, насколько архитектура применима к децентрализованной среде.
Тема 3
Как децентрализовать сортировщик?
Абдельхамид
Есть много функций, которые мы хотим децентрализовать, и все они имеют разные компромиссы.
Например, при децентрализации вы хотите внедрить какой-то механизм консенсуса. Однако механизм консенсуса состоит из нескольких частей. Первый — это выборы лидера, то есть как выбрать, кто будет создавать блоки, кто будет заказчиком, ответственным за создание блоков в заданном слоте или в заданное время. ** Команда Starknet планирует максимально использовать уровень 1. То есть в нашем алгоритме выбора лидера мы хотим сделать ставку на уровень 1. Например, у нас есть токены, а залог будет происходить на смарт-контракте Layer1 Ethereum, который используется для определения механизма избрания лидера. ** Это означает, что нам нужно какое-то взаимодействие, когда заказчик L2 будет запрашивать смарт-контракт Ethereum, чтобы узнать, кто будет следующим лидером или что-то в этом роде. Так что, очевидно, нужна какая-то случайность и другие вещи. Так что это не простой вопрос. Но это первая часть. Тогда вам нужно иметь механизм для самого консенсуса. Есть несколько вариантов: либо механизм с самой длинной цепью, либо BFT, либо их гибрид. Как и у Ethereum, у него есть LMG Ghost и Casper FFG для окончательности.
Так что мы могли бы применить прагматичный подход и начать с BFT. почему? Когда уровень 2 рассматривает децентрализацию, наша цель — не иметь такого большого масштаба сортировщика, как уровень 1. Например, в Ethereum цель состоит в том, чтобы привлечь миллионы валидаторов. В этом случае вы не можете просто использовать механизм BFT, потому что это будет очень плохо по эффективности, и это вызовет очень большие проблемы. Например, если в сети Биткойн есть проблема, если это механизм BFT, цепочка полностью остановится. Но это не так, сеть Биткойн продолжает создавать блоки, атакуется только механизм финализации.
Но на уровне 2, если целью является от нескольких сотен до 1000 сортировщиков, было бы неплохо начать с механизма BFT. Итак, у нас есть механизм выбора лидера, затем консенсус, а затем есть еще две части, но я оставлю это для других гостей, чтобы они продолжали добавлять. Но две другие части — это обновление состояния и генерация доказательств.
Выбор
Во-первых, в L2 децентрализация — это многогранная проблема, описанная Абделем. Особенно в zkRollup, потому что есть пруверы и ордера, между ними нужно координировать, нужно децентрализовать обоих. Эта проблема полностью отличается от L1.
Еще одно отличие состоит в том, что в L2 вся ваша задача состоит в том, чтобы убедить базовый мост в правильности консенсуса, а не в том, чтобы убедить любое количество других узлов. Вы, очевидно, должны сделать то же самое, но ваше основное внимание должно быть сосредоточено на самом мосту.
В настоящее время мы работаем в двух разных направлениях. Во-первых, я думаю, как и все остальные, мы работаем над протоколом BFT. Это не очень эффективно, и есть некоторые перегибы, которые необходимо проработать. Мы придумали грубое решение, но оно все еще не оптимально. Например, один из вопросов: как сбалансировать поощрения между сортировщиками и пруверами? Поскольку заказчик контролирует MEV, а прувер не имеет доступа к MEV, у людей есть стимул управлять заказчиком вместо прувера. Но на самом деле нам нужно больше пруверов, чем заказчиков, так как же сбалансировать поощрения между ними? Это одна из тех проблем.
Второе решение, над которым мы работаем, — это другое направление. Помните, что все может измениться. Каждый день появляются новые предложения. Например, в последнее время много говорят о свертывании на основе и о том, как можно полностью передать сортировку в L1. Второе направление состоит в том, чтобы полностью отказаться от сортировщика и использовать какой-либо внешний сборщик. Например, сборщики Эфириума или Flashbots SUAVE и т. д. предлагают упорядоченные блоки, а затем проводят консенсус внутри прувера. Преимущество здесь в том, что вам не нужно иметь дело со стимулами, потому что в основном вы можете использовать PBS в протоколе, и это создает более простой протокол. Но недостаток в том, что поскольку нам нужно большое количество пруверов (потому что мы можем доказывать параллельно), запустить с ними классический протокол BFT довольно сложно. Итак, вопрос в том, как оптимизировать существующий протокол BFT для работы с сотнями или даже тысячами пруверов? И это не простой вопрос.
Необходимо ли введение консенсуса L2 для децентрализованного ордера?
Яоци
Я могу примерно ответить на этот вопрос, потому что мы совсем недавно выкатили что-то подобное.
Так что введение консенсуса не зависит от того, хотим мы этого или нет. Если у вас много заказчиков или даже просто узлов, вы должны заставить их согласиться. Это действительно зависит от ваших предположений. Если это византийское предположение, мы можем использовать BFT или любой существующий византийский протокол консенсуса. Если это невизантийская установка, например, если мы просто предполагаем, что узел может быть только онлайн и оффлайн, и что он не может действовать злонамеренно, тогда мы можем использовать протокол Raft или какой-либо другой более быстрый протокол консенсуса. Но в любом случае, если у нас есть группа заказчиков или пруверов, если мы хотим организовать их вместе для производства блоков в течение определенного периода времени, тогда у вас должен быть согласованный протокол вокруг них.
Итак, как только что упомянули Тогрул и Абдель, я считаю, что есть много предложений и тем для исследований о том, как мы можем внедрить децентрализованную систему заказов или доказательств. Итак, поскольку мы только что запустили тестовую сеть для мультисортировочной накопительной системы (в настоящее время поддерживает только доказательства мошенничества для Оптимистичных накопительных пакетов), основываясь на нашем опыте проектирования и реализации, я могу кое-что рассказать о трудностях. Как только что упомянул Тогрул, трудность заключается не в самом протоколе консенсуса, а в других вещах, например в части доказательства. Потому что, если это один сортировщик, вам не нужно много узлов. Мы можем думать об этом как о EVM, виртуальной машине. Итак, просто извлекайте транзакции и выполняйте, выполняйте переходы между состояниями. Доказывающая сторона отвечает за создание доказательств перехода состояния предыдущего набора транзакций. Однако, если мы запустим протокол консенсуса для сопоставления и проверки при свертывании, то нам нужно будет ввести в него дополнительную логику консенсуса. Кроме того, вам также нужна система проверки для консенсусного протокола. Следовательно, это потребует много работы для создания системы доказательств. Затем, как только вы сгенерируете доказательство, вы сможете легко проверить его на L1 Ethereum.
Вот почему, когда мы запустили первую тестовую сеть с несколькими заказами, оптимистичный накопитель имел некоторые преимущества в этом отношении. В общем, вы можете упростить многие вещи, например, не учитывать часть доказательства валидности. Как и мы, мы в основном сравниваем все с WASM. Итак, в конце концов, это инструкция WASM. Итак, проверив эти инструкции WASM, относительно легко проверить, используя код Solidity. Если бы мы просто переопределили все интерпретации инструкций WASM на Ethereum.
Но в целом проблема не единичная. Если у нас есть решение проблемы, соответственно, будет еще какая-то доработка, которую нужно решать параллельно. Конечно, будут проблемы с MEV, например, как справедливо распределять MEV. Вы можете назначить всех заказчиков и пруверов в зависимости от того, создали ли они блок или проверили блок. Но, в конце концов, это действительно сочетание многих вопросов, не только технических, но и экономических.
И мы должны помнить, что L2 предлагается, потому что мы хотим значительно снизить стоимость газа. Поэтому у нас не может быть так много узлов. Даже при создании доказательств L2 может быть дороже, чем L1. Поэтому нам действительно нужно выработать сбалансированный подход к такого рода проблемам.
Абдельхамид
Я хотел бы добавить еще один момент. Во-первых, в настоящее время нет фактического доказательства мошенничества без разрешения для оптимистичных накопительных сумм. И я продолжаю подчеркивать это при каждом удобном случае, потому что важно честно говорить об этом при сравнении. Так что они вовсе не L2. Это первое.
Затем я хотел бы добавить кое-что об асинхронности между сортировкой и доказательствами, потому что это очень важно. Как вы сказали, мы хотим оптимизировать сортировку, потому что на данный момент это узкое место для всех решений. Но это нормально в контексте централизованной сортировки, потому что мы знаем, что сортировщик будет производить только переходы значений, и мы сможем их проверить. Но в контексте децентрализованной сортировки это будет сложнее, потому что, возможно, ваш сортировщик сможет выдать что-то, что невозможно проверить. Тогда вам нужно будет иметь дело с этим позже.
В контексте централизованной сортировки, чтобы оптимизировать сортировку, поскольку нам не нужно генерировать доказательства в процессе сортировки, мы можем попытаться сделать это на локальной скорости, что мы и хотим сделать. Переведите Cairo на машинный язык низкого уровня, такой как LLVM, и работайте на сортировщике очень быстро. Затем вы можете доказать асинхронно. И самое классное в доказательствах то, что их можно делать параллельно. Массивная распараллеливание достигается путем доказательства возможности рекурсии. Поэтому мы сможем догнать сортировщик по скорости. Но это сложно, когда децентрализовано, потому что нам нужно гарантировать, что ордер производит только действительные переходы состояний.
Выбор
Добавлю, что не знаю, что здесь делает Старкнет. Но для нас, я думаю, это общее предположение каждого zkRollup, что если вы децентрализуете сортировщик, ваша система проверки должна быть в состоянии обрабатывать недопустимые пакеты. Таким образом, если, скажем, вы отправляете пакет с недействительной подписью, вы должны быть в состоянии доказать, что полученное состояние эквивалентно начальному состоянию. Так что в любом случае будут некоторые накладные расходы. Речь идет о том, как вы минимизируете вероятность этого.
Абдельхамид
Да все верно. Вот почему мы представили Sierra в Cairo 1, чтобы все можно было проверить. Это промежуточное представление гарантирует, что каждую программу Cairo 1 можно проверить, чтобы мы могли включить возвратную транзакцию.
Что такое базовый накопительный пакет?
Яоци
Первоначально накопительный пакет был взят из сообщения в блоге Джастина Дрейка на форумах Ethereum. Одна из его идей заключается в том, что мы можем повторно использовать некоторые верификаторы Ethereum для проверки транзакций свертки, чтобы нам не требовалась отдельная группа узлов для проверки разных транзакций свертки. В частности, в будущем у нас будет много накопительных пакетов, включая универсальные накопительные пакеты и множество накопительных пакетов для конкретных приложений. Так что в этом случае было бы здорово, если бы мы могли найти общее место, такое как пул валидаторов Ethereum, для проверки этих транзакций.
Конечно, это всего лишь идея, так как она также вносит много технических сложностей. Например, теоретически мы могли бы потребовать, чтобы валидаторы Ethereum проверяли транзакции свертки, но очень сложно получить логику проверки сверток, объединенных или встроенных в сам протокол Ethereum. Мы называем это проверкой внутри протокола, для которой требуется хардфорк узлов Ethereum. Конечно, в этом случае мы можем проверить некоторые накопительные транзакции. Но если мы это сделаем, вы увидите проблемы. Это немного похоже на то, что мы хотим, чтобы свертывание L2 разделило давление Ethereum, но в конце концов мы по-прежнему просим валидаторов Ethereum взять на себя часть работы, переложенной на L2. Поэтому многие люди говорят о том, как мы можем это сделать.
Затем мы поговорили с Барнабе, исследователем из Ethereum Foundation, который в настоящее время работает над PBS. Это предложение Ethereum, которое состоит в том, чтобы разделить задачу валидаторов на несколько ролей, создателей и предлагающих. Теперь у нас есть Flashbots, которые берут на себя роль строителей в PBS, они составляют все блоки и отправляют их создателям Ethereum. Поэтому, как только эти блоки будут упакованы в сеть Ethereum, создатели также получат вознаграждение. Как в таком случае вознаграждать этих валидаторов из сети Ethereum? Они также отвечают за проверку свертки.
Одним из решений является «перестейкинг», о котором вы, возможно, много слышали от EigenLayer или некоторых других протоколов. Пользователи могут повторно стейкать ETH в других сортировочных сетях. Или вознаградите валидаторов Ethereum за то, что они действительно запустили программное обеспечение для проверки свертки. При этом они могут быть вознаграждены как из L2, так и через протокол рестейкинга. До сих пор было много предложений по этому поводу, но в целом это идея о том, как можно перепрофилировать существующие валидаторы Ethereum. Как мы можем повторно использовать существующий ETH, чтобы помочь вступить в новую эру накопительных систем или систем L2? Таким образом, он в основном пытается упростить множество вещей для проекта объединения. Если объединению нужен новый сортировщик, если им нужен новый источник обеспечения, они могут повторно использовать существующую инфраструктуру или существующее обеспечение. Вот почему он построен на основе Ethereum, а затем можно повторно использовать дополнительную инфраструктуру и стейкинг для объединения и L2.
Недостатки общего секвенсора и базового накопительного пакета, а также сценарии их применения.
Выбор
Я хочу пожаловаться на это предложение, меня не убеждает предложение, связанное с общим секвенсором. Конечно, они все еще находятся в зачаточном состоянии, и если в будущем эти разработки улучшатся, вполне возможно, что я их поддержу. Просто нынешняя форма меня не убеждает. Есть много причин.
Во-первых, для меня основная ценность общего сортировщика заключается в том, чтобы позволить пользователям получить атомарную компоновку между универсальными накопительными пакетами, такими как Scroll или Starknet. Но проблема в том, что если у вас есть атомарная компонуемость, то ваша свертка будет такой же окончательной, как и самая медленная свертка, с которой вы комбинируете. Таким образом, при условии, что прокрутка объединена с оптимистическим свертыванием, срок действия прокрутки составит семь дней. В то время как основное ценностное предложение ZKRollup заключается в достижении относительно быстрой окончательности, пользователи могут вывести средства на L1 в течение нескольких минут. И в этом случае, в основном отказаться от этого.
Другим недостатком является то, что если вам нужна окончательность вне цепочки, вам нужно запустить узел L2, и пока данные, отправленные в цепочку, завершаются L1, вы получаете окончательность локально в L2. Если каждый объединенный L2 не запускает полный узел, добиться локальной финализации практически невозможно. Это означает, что запуск этой системы может быть дороже, чем запуск такой системы, как Solana, потому что у вас есть несколько полных узлов, работающих одновременно, с их собственными накладными расходами и так далее.
Поэтому по этим причинам я просто не думаю, что это имеет смысл для L2. Для L3 немного по-другому, потому что если кто-то хочет построить цепочку для конкретного приложения и не хочет иметь дело с децентрализацией. Допустим, я создаю игру, и я просто хочу заниматься ее созданием, тогда я могу передать децентрализованную работу на аутсорсинг. Но я не думаю, что это имеет смысл для L2 на данный момент.
Что касается базового свертки, у меня тоже есть свои опасения. Например, как вы делите прибыль MEV с пруверами? Потому что, если не учитывать проблему распределения, в основном L1 может получить всю прибыль от MEV. Еще одна мелочь заключается в том, что время его подтверждения равно времени подтверждения L1, что составляет 12 минут, что не может быть быстрее. Другая проблема заключается в том, что, поскольку это не требует разрешений, несколько искателей могут одновременно отправлять пакеты транзакций, а это означает, что это может привести к централизованным результатам. Потому что строители заинтересованы в том, чтобы включать свои транзакции, если один поисковик подключается легче, чем другие. Следовательно, это может привести к тому, что только один Искатель предложит партии для L2 в конце, что является не очень хорошим решением, потому что, если это произойдет, мы, по сути, вернемся к исходной точке.
Яоци
Интересно, что я только что разговаривал с Беном, основателем Espresso, на прошлой неделе. Мы много обсуждаем это в теме общих сортировщиков. Как упомянул Тогрул, я думаю, что есть некоторая неопределенность в отношении сценариев использования общей системы заказов. В основном это связано с тем, что для L2 общего назначения у нас обычно нет большого количества сортировщиков из-за эффективности, сложности и экономии. И я по-прежнему считаю, что независимо от того, идет ли речь об общем секвенсоре, объединении на основе или повторном сборе, наилучшим вариантом использования в основном является RAS (обновление как услуга) или такие платформы, на которых мы можем развертывать множество обновлений. Честно говоря, нам не нужна большая сеть сортировки, если не так много сверток. У этих объединений уже есть свои собственные системы сортировки и уже есть свои сообщества или партнеры, когда есть только несколько общих L2. Им действительно не нужно иметь отдельную и стороннюю сеть. Кроме того, это нагрузка на стороннюю сеть, потому что приходится настраивать для каждого L2, а у каждого L2 свой тестовый стек. Это требует множества изменений в вашей собственной сети.
Но в то же время, как упомянул Тогрул, для некоторых особых случаев использования. Например, если мы хотим иметь некоторую функциональную совместимость на уровне сортировщика, потенциальным решением могут стать общие сортировщики. Например, один и тот же сортировщик используется для нескольких сверток. В этом случае этот сортировщик может в основном обрабатывать некоторые кросс-сводные транзакции, чтобы обеспечить атомарность кросс-цепочек между свертками A, B и C.
Но вы также можете увидеть проблему здесь, когда я описываю ситуацию. Если бы у нас действительно было много таких общих секвенсоров, они снова стали бы узким местом и новой единой точкой отказа. Мы даем слишком много власти этим так называемым общим заказчикам. Они становятся все более похожими на сеть, контролирующую множество сверток. Наконец, нам снова нужно придумать способ децентрализации этого общего сортировщика.
Но в любом случае, я думаю, это хорошо, что люди постепенно обнаруживают все больше и больше проблем и предлагают все больше и больше решений. В общем, интересно каждый день видеть, что нового в этой области. Со всеми этими новыми решениями мы, по крайней мере, находимся на правильном пути к полной децентрализации всего пространства объединения.
Абдель
Да, я согласен с вами обоими. Я думаю, что это имеет больше смысла для Layer3 и Lisk, потому что они больше не хотят брать на себя ответственность за стимулирование децентрализованной сети и им нужно найти партнеров для запуска таких вещей, как сортировщики. Поэтому я думаю, что для Lisk это имеет смысл. Но, как и Тогрул, я пока не думаю, что это имеет смысл для Layer2.
Тема 4
Какое влияние окажет децентрализованный ордер на MEV?
Абдель
Для Starknet, в контексте централизации, мы не делаем никаких MEV и используем модель «первым пришел — первым обслужен». То есть в контексте децентрализации, конечно, позже будет введено больше MEV. Но пока рано говорить, какое соотношение, потому что оно также зависит от конструкции механизма консенсуса и других аспектов.
Выбор
Но дело в том, что даже если вы не используете MEV, в Старкнете все еще может происходить MEV. Ну, децентрализация сама по себе на самом деле не уменьшает MEV и не увеличивает MEV. Конечно, если вы применяете какой-то протокол честного заказа или пороговое шифрование, например, то да, вы минимизируете MEV. Но полностью избавиться от него нельзя. Моя философия такова: MEV нельзя устранить. Но допустим, вы просто создаете консенсус BFT или строите что-то поверх консенсуса BFT. На самом деле это никак не влияет на MEV. MEV все еще существует, вопрос должен заключаться в том, как поисковик работает с сортировщиком, чтобы извлечь этот MEV.
Яоци
Проблема в том, что даже в модели «первым пришел — первым обслужен» есть непростые моменты. Как только мы открываем мемпул некоторым искателям, у них все еще есть преимущество, позволяющее играть больше. Например, для секвенсоров они эквивалентны ожиданию у двери вашего офиса. Так что в этом случае, как только они увидят какую-то арбитражную возможность, а не только форвардную или сэндвич-атаку, как только пользователь отправит транзакцию, они сразу смогут увидеть ее в мемпуле. Таким образом, они могут быстро размещать свои сделки впереди других. Таким образом, они имеют преимущество перед другими поисковиками.
Но возвращаясь к децентрализации, я думаю, что в основном речь идет о сопротивлении цензуре, как мы обсуждали в начале. Секвенсорами управляет команда. Команда может сказать, что они справедливы ко всем. Но это не запрещено в коде. Итак, если бы у нас была сеть P2P, было бы здорово, если бы мы чувствовали, что эти узлы проверяют мою транзакцию, а затем мы можем отправить ее другим узлам. Итак, речь действительно идет о честности обработки транзакций на уровне L2.
Что касается MEV, потому что в последнее время в дополнение к MEV, генерируемым в рамках одного объединения, есть несколько MEV, генерируемых через мосты. В этой относительно децентрализованной сортировочной сети у вас будет больше возможностей для извлечения MEV. Предполагая, что у нас есть общая сеть заказов, если вы можете каким-то образом повлиять на общего заказа, чтобы изменить порядок транзакций, в основном у вас есть большое преимущество перед всеми остальными.
У общей сети секвенсора есть преимущества и недостатки. С положительной стороны, мы можем еще больше децентрализовать систему ранжирования. Но с другой стороны, у каждого есть возможность быть сортировщиком. Таким образом, они могут делать все, что хотят, и это снова темный лес. Итак, мы ввели децентрализацию, а потом нам пришлось столкнуться с теми же проблемами, с которыми мы столкнулись в Ethereum. Вот почему Flashbots и ребята из Ethereum Foundation хотят продвигаться вперед с PBS, разделять разработчиков и разработчиков, а затем пытаться иметь единое решение на стороне разработчиков.
Поэтому, когда мы смотрим на проблему, это не просто проблема. Это уже не проблема один на один, а один на шесть, и больше.