# Децентрализация rollup By [Perfect](https://paragraph.com/@perfeeeeeect) · 2023-06-16 --- _Этот пост исследует определения и общие идеи децентрализации rollup. Он не затрагивает глубоких технических деталей децентрализации реализации rollup._ Мы идентифицируем Taiko как децентрализованный Ethereum-эквивалент ZK-Rollup. Ethereum-эквивалент - это техническое конструктивное решение типа 1 ZK-EVM, о котором мы описываем [здесь](https://taiko.mirror.xyz/w7NSKDeKfJoEy0p89I9feixKfdK-20JgWF9HZzxfeBo). В этом посте мы хотели бы поговорить о другом дескрипторе в этой формулировке: _децентрализованный_. Мы рассмотрим: * Что такое определение децентрализованного rollup? * Как можно децентрализовать rollup? * Какие есть компромиссы у децентрализованного rollup? * Подход Taiko: прогрессивная эффективность * Децентрализованная реализация и децентрализованное управление * Как децентрализация является частью Ethereum-эквивалента Что такое определение децентрализованного rollup? ------------------------------------------------- Вы можете удивиться (или нет), узнав, что существует некоторое несоответствие определения децентрализованного rollup. Мы думаем, что можем достаточно точно подобрать широко принимаемое определение: > Децентрализованный rollup - это когда **любой пользователь может быть уверен в том, что его транзакция будет выполнена**. Стоит задуматься, почему вообще важно, является ли rollup децентрализованным или нет. Учитывая, что для гарантии безопасности rollup'ов необходимы L1 (главным образом Ethereum в наши дни для ведущих rollup'ов), пользователи защищены, как бы там ни было? Rollup'ы гарантируют, что только если L1 (уровень доступности данных) существует, пользователи могут восстановить L2 состояние и **выйти из rollup'а, принудительно выполнив транзакцию на L1**. Если система не удовлетворяет этому условию, то мы можем сказать, что это не rollup, а другой тип L2 или сайдчейн. Это должно показать, что выбор сильно децентрализованного (всегда живого, устойчивого к цензуре) L1 критически важен. Еще одно уточнение заключается в том, что для общего rollup'а, в отличие от приложения-специфического rollup'а, пользователи должны иметь возможность **принудительно включать любую произвольную транзакцию, а не только транзакции «выхода»**. ![](https://storage.googleapis.com/papyrus_images/6ec24655dfeebd15813fdf748fbd62dc598876566d2e618fe80d99f909235dcb.png) Установив, что мы говорим о rollup, мы утверждаем, что различие, определяющее децентрализованный или нет rollup, заключается в том, **насколько сложно или реально для пользователя заставить свою транзакцию быть включенной**. Например, **нужны ли им очень мощные вычислительные ресурсы для создания ZK-proof?** Или они могут использовать бытовое оборудование или арендовать дешевый сервер на короткое время? Есть ли какой-то привилегированный субъект, который может свободно распоряжаться транзакцией в течение длительного периода времени, откладывая свою возможность попытаться быть включенным на 30 дней? Чем меньше запретов, тем больше децентрализации. ![Между этими крайностями существует целый спектр. "Менее децентрализованный" - это нечто.](https://storage.googleapis.com/papyrus_images/40a529ad5220b7590171143ce6da67d21abda5e77d282d38442dae75299bad23.png) Между этими крайностями существует целый спектр. "Менее децентрализованный" - это нечто. На самом деле обычный пользователь, вероятно, не хотел бы запускать полную node rollup и, в случае ZK-Rollup, дополнение-доказательство. Они хотели бы знать, что rollup, на который они проводят транзакции, или даже rollup, который они и сами используют, способен **иметь широкий и разнообразный набор участников, выполняющих необходимые функции**. И что новые участники могут присоединяться к сети, чтобы выполнять эти функции, безопасно - в том числе и они сами, если они хотят. С учетом вышеизложенного, давайте завершим этот раздел еще одним определением децентрализованного rollup, чтобы мы лучше понимали: > Децентрализованный rollup - это такой rollup, в котором **несколько сторон могут участвовать в каждой сетевой позиции** - то есть в качестве предложителей, доказывающих и запускающих узлов. Это приводит нас к следующему разделу. Как вы децентрализуете rollup? ------------------------------ Учитывая вышеописанные определения, особенно второе, видим, что мы можем **децентрализовать rollup, обеспечивая выполнение всех ролей несколькими сторонами** - в идеале, обширным и географически разнообразным набором. Эти роли: * **Proposers** * **Provers** * **Node runners** Прежде чем мы рассмотрим каждую роль, давайте просто коснемся точки, затронутой в предыдущем разделе: rollupы, как решение L2, решают, какой L1 они собираются масштабировать, или более точно, какой L1 они будут использовать для гарантий безопасности. «Гарантии безопасности» здесь означает полагаться на L1 для обеспечения консенсуса и доступности данных (DA). Хотя это нечто, что сам rollup не может настроить в пользу децентрализации, **выбор L1 с достаточно децентрализованной структурой является критически важным решением**, и Taiko выбирает Ethereum для наиболее надежных гарантий безопасности. Перейдем к ролям. ### Proposers Proposers создают блоки rollup из L2-транзакций пользователей и предлагают их L1. Иногда их называют «Секвенсорами» в других системах rollup. Proposers решают, **какие транзакции будут включены в блок и в каком порядке**. Это мощная позиция, так как они могут извлекать прибыль из упорядочивания транзакций и решать, какие транзакции исключить, и таким образом могут цензурировать определенные транзакции, приложения или пользователей. Как мы установили —> децентрализованный rollup должен позволять пользователям ожидать **включение** всех их действительных транзакций. ### Provers Provers создают SNARK-доказательства, подтверждающие допустимость транзакций и блоков L2 из соответствующих блоков. Производители доказательств решают, **какие предложенные блоки превратить в блоки, подтверждаемые на цепи**. Эта позиция определяет, когда блок может достичь своего подтвержденного на цепи состояния, но не определяет, какие транзакции попадут в блок или как они будут упорядочены. До этого подтвержденного на цепи состояния, производитель доказательств может оставить висящими некоторые транзакции, зависящие от доказательства подлинности, или оставить висящими некоторые блоки, которые должны быть подтверждены на цепи и которые ожидают подтверждения своего родительского блока. Как мы установили —> децентрализованный rollup должен позволять пользователям ожидать подтверждения всех своих допустимых транзакций. ### Node runners Node runners **выполняют транзакции из данных на цепи (L1)**, чтобы оставаться в синхронизации со статусом rollup. Proposers и производители доказательств должны запускать полноценные узлы rollup, чтобы выполнить свои роли. Другие участники также захотят запустить узлы, например, те, которые предоставляют услуги, такие как обозреватель блоков, поставщики инфраструктуры и пользователи, которые хотят оставаться в синхронизации со статусом цепочки по другим причинам. Как мы установили —> децентрализованный rollup должен позволять пользователям **ожидать выполнения** всех их допустимых транзакций. _Примечание: хотя децентрализация предложителей и производителей доказательств является явным решением протокола роллап (например, смарт-контракты могут быть настроены таким образом, чтобы принимать только блоки или доказательства от адресов из белого списка), запуск узла в основном зависит от ресурсов, которые требуются для роста состояния, оборудования и т.д. и не является прямым решением протокола. Важно учитывать рост состояния, но это не обсуждается в данной статье._ Каковы компромиссы децентрализованного rollup? ---------------------------------------------- Переход от централизации к децентрализации открывает торговую площадку компромиссов. В этом разделе плюсы и минусы относятся как к proposers так и provers (которых мы обычно называем _операторами_); мы не будем учитывать управляющих узлов, как уже упоминалось, но имейте в виду, что запуск узла роллапа является требованием для обоих ролей. В контексте proposers/provers rollup мы видим: ![](https://storage.googleapis.com/papyrus_images/6739d6bb3dc135acdc162f8f1dc1875a37ee8112af0372c4a7100e9376c477f1.png) Подход Taiko: прогрессивная эффективность ----------------------------------------- Текущий подход, выбранный большинством серийно выпускаемых рулонов общего назначения, заключается в централизации на начальном этапе, с обязательством постепенной децентрализации с течением времени. В этом есть определенный смысл, поскольку есть несколько движущихся частей, предположения, которые нужно проверить, и пока еще рано. Наличие централизованных proposer и prover (он же sequencer и validator в более широком смысле) упростило обеспечение правильного и эффективного функционирования роллапа. Мы можем видеть этот популярный подход в следующей таблице. ![Источник: L2beat.com. Отображает различные риски rollup. Для обсуждаемой нами темы, rollup с децентрализованными proposers и provers будет иметь "Propose Blocks" в колонках Sequencer и Validator Failure (и он будет очень доступен для пользователей для работы с такими блоками). Как вы видите, ни один из вышеперечисленных вариантов в настоящее время не удовлетворяет ни тому, ни другому.](https://storage.googleapis.com/papyrus_images/090f69aa2842d07ae7a43837c3e975fae1cd125a65c865c059a2ad6aea2ed002.png) Источник: L2beat.com. Отображает различные риски rollup. Для обсуждаемой нами темы, rollup с децентрализованными proposers и provers будет иметь "Propose Blocks" в колонках Sequencer и Validator Failure (и он будет очень доступен для пользователей для работы с такими блоками). Как вы видите, ни один из вышеперечисленных вариантов в настоящее время не удовлетворяет ни тому, ни другому. С другой стороны, Taiko стремится к **полностью децентрализованному (и безразрешительному) комплекту proposer и prover**. Протокол не закрепляет или не включает в белый список какие-либо стороны; кто угодно сможет исполнять эти обязанности. Далее, Taiko планирует иметь минимальную схему координации, определенную протоколом, для proposer and prover. Текущий план состоит в том, чтобы она была без лидера. Все rollups выберут наилучшую позицию, которая соответствует потребностям их пользователей. Эта точка будет отличаться в разных rollups и путь, чтобы достичь этой же точки, может также отличаться. Можно начать с централизованного подхода и постепенно снижать контроль, или можно начать с децентрализованного подхода и реализовать жесткие правила координации (или, возможно, назначить контроль). Конечно, возможно, что некоторые недостатки децентрализации станут препятствием для работоспособной сети, в этом случае Taiko может ввести меры, такие как выборы лидеров, чтобы избежать избыточной работы. > В этом смысле подход Taiko можно считать эффективным, скорее чем децентрализованным. Он движется от полностью децентрализованного и неструктурированного края и более в центр, если это необходимо. Это не значит, что Taiko будет полностью лишен ["training-wheel-free"](https://ethereum-magicians.org/t/proposed-milestones-for-rollups-taking-off-training-wheels/11571) с самого начала. Некоторые меры, такие как возможность обновления смарт-контрактов, останутся в силе до тех пор, пока они не будут испытаны на боевом тесте. Этот подход основан на безопасности: без обновляемости на основе прокси активы пользователей могут столкнуться с значительными рисками ошибок. Контролируемая обновляемость - один из рычагов, который будет передан DAO в какой-то момент. Децентрализованная реализация и децентрализованное управление ------------------------------------------------------------- Vitalik недавно [написал](https://vitalik.ca/general/2022/12/05/excited.html), что _"децентрализованная структура управления защищает от атакующих изнутри, а децентрализованная реализация защищает от мощных атакующих снаружи"_. Это было сказано в контексте DAO - то есть, как структура управления, так и реализация касались DAO. В частности, это было сказано для одной из целей децентрализации DAO: устойчивости. Мы считаем, что это достаточно полезно использовать для всех rollups в целом и разделять "структура управления" на означающую DAO конкретного rollup (принимая на веру, что реализация управления основана на смарт-контрактах), а "реализацию" - это значит архитектуру самого rollup. ![Источник: https://vitalik.ca/general/2022/12/05/excited.html](https://storage.googleapis.com/papyrus_images/ab661a6b70dc93509e3510485e8b7b1124e96f688240e0ae84fc55c5f99d510d.png) Источник: https://vitalik.ca/general/2022/12/05/excited.html В этом контексте мы обсуждали, как rollup может защититься от внешних угроз (цензуры, отказов в работе) с помощью децентрализованной реализации. **Однако мы не должны игнорировать, как rollup может защититься от внутренних угроз** - от организации и сообщества, ответственных за его начальное создание и поддержку. В этом случае инструментом, которым располагает rollup, является управление, или упрощенно, его DAO. Что касается управления, Taiko принимает подход, похожий на другие rollups и большую часть протоколов на Ethereum в целом, от DeFi до инфраструктуры. Этот подход действительно является постепенным децентрализацией: контроль над протоколом gradually будет передан сообществу, а именно Taiko DAO. Сейчас еще рано описывать детали DAO и какие механизмы управления мы предложим, но это будет предметом будущих постов. В заключение на эту тему мы считаем, что **реализация предлагает анализ свойств роллапа в точке времени, в то время как управление может описать, как реализация может меняться со временем**, и какие стороны могут принимать эти решения. Как децентрализация является частью эквивалентности Ethereum ------------------------------------------------------------ Стремясь к чистой эквивалентности Ethereum, Taiko высоко оценивает свою приоритетность децентрализации. Кажется странным, чтобы эквивалентность как цель охватывала EVM, хэш-функции, состояние и tx-деревья и т. д., не отражая эквивалентности в составе сети. Эмулирование Ethereum для Taiko означает, что все выстраивается вокруг Ethereum: ZK-EVM, другая базовая архитектура Ethereum, философские соображения, сообщество и ~вайба~. Это распространяется на децентрализацию сети и основные свойства, которые он предоставляет разработчикам и их пользователям: устойчивость к цензуре. Спасибо за прочтение. ### Присоединяйтесь к нам Изучите открытые вакансии на нашей [доске объявлений](https://www.notion.so/Taiko-Jobs-828fd7232d2c4150a11e10c8baa910a2). ### Следите за нами Чтобы быть в курсе последних событий в компании Taiko: * Website: [https://taiko.xyz](https://taiko.xyz/) * Discord: [https://discord.gg/taikoxyz](https://discord.gg/taikoxyz) * GitHub: [https://github.com/taikoxyz](https://github.com/taikoxyz) * Reddit: [https://www.reddit.com/r/taiko\_xyz](https://www.reddit.com/r/taiko_xyz) * Twitter: [https://twitter.com/taikoxyz](https://twitter.com/taikoxyz) ### Вклад Внесите свой вклад в Taiko и получите GitPOAP! Вы также будете упомянуты в качестве участника в нашем README. Начните с [руководства по внесению вклада](https://github.com/taikoxyz/taiko-mono/blob/main/CONTRIBUTING.md). Translated by: perfeect & igorizuchaetcrypty --- *Originally published on [Perfect](https://paragraph.com/@perfeeeeeect/rollup)*