У цій статті блогу більше розповідається про децентралізацію в OP Labs, оскільки ми підтримуємо інженерів екосистеми, які створюють систему відмови від OP Stack, і Optimism Collective, що створює свою першу пораду безпеки.

Критична дискусія на шляху до зрілості блокчейна полягає в тому, як, у якому обсязі та коли проводити децентралізацію. У цьому повідомленні блогу розповідається трохи більше про те, що ми думаємо про цей процес в OP Labs, оскільки ми підтримуємо інженерів екосистеми, які створюють систему відмови від OP Stack, і Optimism Collective, що створює свою першу пораду безпеки.

В познавательной статье на форуме Ethereum Magicians, Виталик Бутерин излагает план действий по достижению 2-го этапа децентрализации, важнейшего этапа для любой сети 2-го уровня, стремящейся к децентрализации. Этот пост стал основой для многих дискуссий о технической децентрализации в Optimism Collective за последние два года. Мы твердо убеждены, что все блокчейны второго уровня должны уделять приоритетное внимание достижению этой стадии децентрализации как можно быстрее (и безопаснее!), чтобы обеспечить более надежную, безопасную и по-настоящему децентрализованную экосистему.

Чтобы напомнить всем, что требуется для достижения накопительного уровня 2, вот критерии, изложенные в исходном сообщении Виталика Бутерина:

Требования:

• В случае, если в коде нет ошибок/ багов, не должно быть какой-либо группы акторов, которая могла бы, даже единогласно, опубликовать корень состояния, отличный от вывода кода.

Эта несколько неуклюжая формулировка («ЕСЛИ в коде нет ошибок, ТО никто не сможет его переопределить») предназначена для того, чтобы разрешить использование советов безопасности способами, которые явно ограничиваются вынесением решений по неоспоримым ошибкам, например, следующим образом:

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

• Если кто-то отправляет транзакцию или серию транзакций, которые содержат два действительных доказательства для двух разных state roots, после обработки одних и тех же данных (т. е. «доказывающий не согласен сам с собой»), контроль временно переходит к совету безопасности.

• Если действительные доказательства не представлены в течение >= 7 дней (т. е. «доказательство застряло»), контроль временно переходит к совету безопасности.

• Обновления разрешены, но с задержкой >= 30 дней.

Подводя итог, можно сказать, что для того, чтобы снять свои «тренировочные колеса» и достичь децентрализации Этапа 2, роллапы должны иметь надежную систему защиты от сбоев, несколько функционирующих механизмов проверки, а роллапы, в которых есть совет безопасности или подобная организация, должны соответствовать определенным критериям.

Что делает этап 2, чего не делает этап 1, так это гарантирует, что не существует какой-либо группы участников, которая могла бы «даже единогласно опубликовать state root, отличный от вывода кода». У L2 уровня 1 все еще есть какая-то версия мультиподписи или совета безопасности, который может гипотетически (хотя и не без затрат) изменить корень состояния цепочки, чтобы подвергнуть цензуре или инициировать недействительный вывод средств. Это не совсем безнадежно. Удаление этой возможности еще больше децентрализует сети и гарантирует пользователям неотъемлемую возможность выхода из системы.

Этот тип гибкости имеет решающее значение для Superchain, поскольку он уравновешивает функциональную совместимость — все, кто использует одно и то же доказательство отказа, будут использовать одну и ту же версию протокола — без ущерба для свободы пользователя и защиты. Право на выход всегда должно сохраняться и не влиять на работу сети или приложения..

При переходе к этапу 2 в проектах можно использовать подход «сначала в глубину»: как можно быстрее добраться до этапа 1 с доказательством одной неисправности, а затем придумать, как создать систему доказательства множественных неисправностей, чтобы достичь статуса этапа 2. Компания Optimism, напротив, использовала подход «сначала в ширину», целью которого является создание функциональной, быстрорастущей многофункциональной сети. Инженеры экосистемы создают первую реализацию отказоустойчивой системы таким образом, чтобы обеспечить такой подход. Между тем, поскольку все это создается открыто, с использованием стека с открытым исходным кодом, другие разработчики в экосистеме смогли начать создавать множество других реализаций параллельно с работой над первой защищенной от сбоев реализацией.

Мы знаем, как важно сделать все правильно с первой попытки. Сегодня инженеры OP Stack заложили основу для быстрого мультизащитного расширения и работают над достижением статуса Stage 1 согласно L2Beat. Но Bedrock создавался с нуля с учетом децентрализации второго этапа. Мы не заинтересованы в достижении Стадии 1 просто ради того, чтобы сказать, что мы это сделали. С первого дня это было лишь частью нашего прагматичного плана по достижению Этапа 2 как можно быстрее и безопаснее..

Этап 2 – это конец игры. Вот как это выглядит на практике:

Мы знали, что для того, чтобы расставить приоритеты в достижении этапа 2, нам нужно разработать кодовую базу, которая облегчит этот этап. Нам нужна была модульность, представленная обновлением Bedrock, чтобы гарантировать, что после того, как для стека OP будет разработана функционирующая, надежная и отказоустойчивая система, разработчики экосистемы смогут использовать ее модульные сверхспособности, чтобы помочь нам разработать не одну или две, а множество альтернативных проверочных систем. механизмы.

В то же время нам нужно было убедиться, что даже непредвиденные технологические разработки не сделают OP Stack устаревшим. Текущая структура стека OP гарантирует, что разработчики могут заменять проверочные компоненты, включив в них технологию ZK, что когда-то угрожало росту Optimistic накопительных пакетов. Сети в экосистеме Optimism не всегда обязаны использовать механизмы подтверждения оптимизма. Мы ожидаем, что они смогут использовать достижения в технологии ZK и возрождение плазмы, или комбинация всех трех механизмов в отказоустойчивой системе их цепочки.

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

До сих пор этот подход приносил огромные плоды. Доказательством тому является то, как быстро альтернативные клиенты стали популярными с момента запуска Bedrock, и сколько команд в экосистеме в настоящее время также работают над альтернативными отказоустойчивыми реализациями. В дополнение к OP Labs и всем альтернативным сопровождающим клиентов (Test in Prod, команда reth и Base, Nethermind, a16z crypto и Кай Чен и команда Hildr), которые используются в качестве критически важных зависимостей в стеке OP, в настоящее время команды Над альтернативными доказательствами ошибок работают команда State Channels, RISCZero, O(1) Labs, AltLayer, Protolambda (в OP Labs), а также инженеры Виллем Олдинг и Эрик Ту, а также geohotz и его первоначальная работа над Cannon.

Вот как это будет выглядеть:

Стек OP представляет собой тройную угрозу. Он является модульным и имеет открытый исходный код, что означает, что вся мощь стека может попасть в руки третьей «угрозы» — чрезвычайно творческого и блестящего сообщества разработчиков. Инженерам OP Labs потребуются годы, чтобы разработать, протестировать и реализовать многочисленные схемы проверки, необходимые для децентрализации второго этапа. Предоставляя лучшие инструменты в руки ведущих разработчиков и инженеров ядра нашей экосистемы, любой, кто заинтересован в успехе Optimism, может разработать компоненты, которые помогут достичь нашей цели.

Чтобы достичь этапа децентрализации 1 и перейти на этап 2, сетям необходимо нечто вроде совета безопасности — мультиподпись, с помощью которой можно управлять обновлениями протокола, которую обслуживают как минимум 8 независимых лиц с порогом подписи 75% или выше.

Осенью 2023 года началась серьезная работа по созданию первого совета безопасности экосистемы Оптимизма, состоящего из людей, не входящих в Фонд. Первые 14 членов совета безопасности экосистемы Оптимизма были ратифицированы голосованием руководства в декабре 2023 года, а еще одно голосование - это вопрос о том, следует ли делиться ключами обновления с Советом безопасности во время промежуточной «Фазы 0», также было успешным.

Одна из ценностей Optimism — технологии с открытым исходным кодом. Подобно тому, как инженеры экосистемы создают открытый стек OP с открытым исходным кодом, лицензированный MIT, так и совет безопасности будет создаваться открыто, например публичная хартия, открытый исходный код выполнения, и прозрачные операции. Это соответствует двум из трех руководящих принципов, которые легли в основу структуры Совета безопасности: прозрачность и общность.

Третий принцип, безопасность превыше жизнеспособности, определяет структуру совета безопасности и безопасность экосистемы Optimism в целом. Приоритет безопасности над работоспособностью означает, что для системы важнее избегать ошибок и недопустимых состояний, особенно тех, которые могут привести к потере средств, даже если это приводит к временной остановке операций.

Вот и все. Это мем.

L2 недостаточно достичь Стадии 1 и ограничить использование тренировочных колес, по-прежнему полагаясь на единый механизм проверки для обеспечения зарождающейся системы защиты от сбоев. Кроме того, эффективность единой системы защиты от сбоев зависит от силы Совета безопасности, который может ею управлять. На первом этапе Совет безопасности из 14 человек был ратифицирован Управлением Оптимизма для управления безопасностью Суперчейна, и ключевой целью в 2024 году является то, чтобы этот совет безопасности управлял ключами обновления экосистемы под руководством Управления Оптимизма. и независимо от Фонда Оптимизма.

Большая часть планирования и развития OP Labs за последние полтора года была направлена ​​на то, чтобы поставить всю экосистему Optimism в такое положение, когда достижение децентрализации второго этапа не только реалистично, но и достижимо. Мы рады совершить это путешествие в следующем году вместе со всеми остальными членами Коллектива!

Ссылка на оригинальную статью:

https://blog.oplabs.co/endgame-is-stage-2/

У цій статті блогу більше розповідається про децентралізацію в OP Labs, оскільки ми підтримуємо інженерів екосистеми, які створюють систему відмови від OP Stack, і Optimism Collective, що створює свою першу пораду безпеки.

Критична дискусія на шляху до зрілості блокчейна полягає в тому, як, у якому обсязі та коли проводити децентралізацію. У цьому повідомленні блогу розповідається трохи більше про те, що ми думаємо про цей процес в OP Labs, оскільки ми підтримуємо інженерів екосистеми, які створюють систему відмови від OP Stack, і Optimism Collective, що створює свою першу пораду безпеки.

В познавательной статье на форуме Ethereum Magicians, Виталик Бутерин излагает план действий по достижению 2-го этапа децентрализации, важнейшего этапа для любой сети 2-го уровня, стремящейся к децентрализации. Этот пост стал основой для многих дискуссий о технической децентрализации в Optimism Collective за последние два года. Мы твердо убеждены, что все блокчейны второго уровня должны уделять приоритетное внимание достижению этой стадии децентрализации как можно быстрее (и безопаснее!), чтобы обеспечить более надежную, безопасную и по-настоящему децентрализованную экосистему.

Чтобы напомнить всем, что требуется для достижения накопительного уровня 2, вот критерии, изложенные в исходном сообщении Виталика Бутерина:

Требования:

• В случае, если в коде нет ошибок/ багов, не должно быть какой-либо группы акторов, которая могла бы, даже единогласно, опубликовать корень состояния, отличный от вывода кода.

Эта несколько неуклюжая формулировка («ЕСЛИ в коде нет ошибок, ТО никто не сможет его переопределить») предназначена для того, чтобы разрешить использование советов безопасности способами, которые явно ограничиваются вынесением решений по неоспоримым ошибкам, например, следующим образом:

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

• Если кто-то отправляет транзакцию или серию транзакций, которые содержат два действительных доказательства для двух разных state roots, после обработки одних и тех же данных (т. е. «доказывающий не согласен сам с собой»), контроль временно переходит к совету безопасности.

• Если действительные доказательства не представлены в течение >= 7 дней (т. е. «доказательство застряло»), контроль временно переходит к совету безопасности.

• Обновления разрешены, но с задержкой >= 30 дней.

Подводя итог, можно сказать, что для того, чтобы снять свои «тренировочные колеса» и достичь децентрализации Этапа 2, роллапы должны иметь надежную систему защиты от сбоев, несколько функционирующих механизмов проверки, а роллапы, в которых есть совет безопасности или подобная организация, должны соответствовать определенным критериям.

Что делает этап 2, чего не делает этап 1, так это гарантирует, что не существует какой-либо группы участников, которая могла бы «даже единогласно опубликовать state root, отличный от вывода кода». У L2 уровня 1 все еще есть какая-то версия мультиподписи или совета безопасности, который может гипотетически (хотя и не без затрат) изменить корень состояния цепочки, чтобы подвергнуть цензуре или инициировать недействительный вывод средств. Это не совсем безнадежно. Удаление этой возможности еще больше децентрализует сети и гарантирует пользователям неотъемлемую возможность выхода из системы.

Этот тип гибкости имеет решающее значение для Superchain, поскольку он уравновешивает функциональную совместимость — все, кто использует одно и то же доказательство отказа, будут использовать одну и ту же версию протокола — без ущерба для свободы пользователя и защиты. Право на выход всегда должно сохраняться и не влиять на работу сети или приложения..

При переходе к этапу 2 в проектах можно использовать подход «сначала в глубину»: как можно быстрее добраться до этапа 1 с доказательством одной неисправности, а затем придумать, как создать систему доказательства множественных неисправностей, чтобы достичь статуса этапа 2. Компания Optimism, напротив, использовала подход «сначала в ширину», целью которого является создание функциональной, быстрорастущей многофункциональной сети. Инженеры экосистемы создают первую реализацию отказоустойчивой системы таким образом, чтобы обеспечить такой подход. Между тем, поскольку все это создается открыто, с использованием стека с открытым исходным кодом, другие разработчики в экосистеме смогли начать создавать множество других реализаций параллельно с работой над первой защищенной от сбоев реализацией.

Мы знаем, как важно сделать все правильно с первой попытки. Сегодня инженеры OP Stack заложили основу для быстрого мультизащитного расширения и работают над достижением статуса Stage 1 согласно L2Beat. Но Bedrock создавался с нуля с учетом децентрализации второго этапа. Мы не заинтересованы в достижении Стадии 1 просто ради того, чтобы сказать, что мы это сделали. С первого дня это было лишь частью нашего прагматичного плана по достижению Этапа 2 как можно быстрее и безопаснее..

Этап 2 – это конец игры. Вот как это выглядит на практике:

Мы знали, что для того, чтобы расставить приоритеты в достижении этапа 2, нам нужно разработать кодовую базу, которая облегчит этот этап. Нам нужна была модульность, представленная обновлением Bedrock, чтобы гарантировать, что после того, как для стека OP будет разработана функционирующая, надежная и отказоустойчивая система, разработчики экосистемы смогут использовать ее модульные сверхспособности, чтобы помочь нам разработать не одну или две, а множество альтернативных проверочных систем. механизмы.

В то же время нам нужно было убедиться, что даже непредвиденные технологические разработки не сделают OP Stack устаревшим. Текущая структура стека OP гарантирует, что разработчики могут заменять проверочные компоненты, включив в них технологию ZK, что когда-то угрожало росту Optimistic накопительных пакетов. Сети в экосистеме Optimism не всегда обязаны использовать механизмы подтверждения оптимизма. Мы ожидаем, что они смогут использовать достижения в технологии ZK и возрождение плазмы, или комбинация всех трех механизмов в отказоустойчивой системе их цепочки.

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

До сих пор этот подход приносил огромные плоды. Доказательством тому является то, как быстро альтернативные клиенты стали популярными с момента запуска Bedrock, и сколько команд в экосистеме в настоящее время также работают над альтернативными отказоустойчивыми реализациями. В дополнение к OP Labs и всем альтернативным сопровождающим клиентов (Test in Prod, команда reth и Base, Nethermind, a16z crypto и Кай Чен и команда Hildr), которые используются в качестве критически важных зависимостей в стеке OP, в настоящее время команды Над альтернативными доказательствами ошибок работают команда State Channels, RISCZero, O(1) Labs, AltLayer, Protolambda (в OP Labs), а также инженеры Виллем Олдинг и Эрик Ту, а также geohotz и его первоначальная работа над Cannon.

Вот как это будет выглядеть:

Стек OP представляет собой тройную угрозу. Он является модульным и имеет открытый исходный код, что означает, что вся мощь стека может попасть в руки третьей «угрозы» — чрезвычайно творческого и блестящего сообщества разработчиков. Инженерам OP Labs потребуются годы, чтобы разработать, протестировать и реализовать многочисленные схемы проверки, необходимые для децентрализации второго этапа. Предоставляя лучшие инструменты в руки ведущих разработчиков и инженеров ядра нашей экосистемы, любой, кто заинтересован в успехе Optimism, может разработать компоненты, которые помогут достичь нашей цели.

Чтобы достичь этапа децентрализации 1 и перейти на этап 2, сетям необходимо нечто вроде совета безопасности — мультиподпись, с помощью которой можно управлять обновлениями протокола, которую обслуживают как минимум 8 независимых лиц с порогом подписи 75% или выше.

Осенью 2023 года началась серьезная работа по созданию первого совета безопасности экосистемы Оптимизма, состоящего из людей, не входящих в Фонд. Первые 14 членов совета безопасности экосистемы Оптимизма были ратифицированы голосованием руководства в декабре 2023 года, а еще одно голосование - это вопрос о том, следует ли делиться ключами обновления с Советом безопасности во время промежуточной «Фазы 0», также было успешным.

Одна из ценностей Optimism — технологии с открытым исходным кодом. Подобно тому, как инженеры экосистемы создают открытый стек OP с открытым исходным кодом, лицензированный MIT, так и совет безопасности будет создаваться открыто, например публичная хартия, открытый исходный код выполнения, и прозрачные операции. Это соответствует двум из трех руководящих принципов, которые легли в основу структуры Совета безопасности: прозрачность и общность.

Третий принцип, безопасность превыше жизнеспособности, определяет структуру совета безопасности и безопасность экосистемы Optimism в целом. Приоритет безопасности над работоспособностью означает, что для системы важнее избегать ошибок и недопустимых состояний, особенно тех, которые могут привести к потере средств, даже если это приводит к временной остановке операций.

Вот и все. Это мем.

L2 недостаточно достичь Стадии 1 и ограничить использование тренировочных колес, по-прежнему полагаясь на единый механизм проверки для обеспечения зарождающейся системы защиты от сбоев. Кроме того, эффективность единой системы защиты от сбоев зависит от силы Совета безопасности, который может ею управлять. На первом этапе Совет безопасности из 14 человек был ратифицирован Управлением Оптимизма для управления безопасностью Суперчейна, и ключевой целью в 2024 году является то, чтобы этот совет безопасности управлял ключами обновления экосистемы под руководством Управления Оптимизма. и независимо от Фонда Оптимизма.

Большая часть планирования и развития OP Labs за последние полтора года была направлена ​​на то, чтобы поставить всю экосистему Optimism в такое положение, когда достижение децентрализации второго этапа не только реалистично, но и достижимо. Мы рады совершить это путешествие в следующем году вместе со всеми остальными членами Коллектива!

Ссылка на оригинальную статью:

https://blog.oplabs.co/endgame-is-stage-2/