Автор: protolambda, исследователь OP Labs Составитель: Фрэнк, Foresight News
Чтобы создать самую мощную и безопасную, совместимую сеть уровня 2, Optimism Collective проводит децентрализацию по многим различным направлениям.
Предстоящая отказоустойчивая система OP Stack станет важным шагом на пути к технологической децентрализации.Открытый исходный код и модульная конструкция OP Stack создают беспрецедентный этап для социальной децентрализации экосистемы L2.
В этой статье мы рассмотрим принцип социальной децентрализации, то, как архитектура L2 позволяет уровню 2 расширить этот принцип, включив в него разнообразие доказательств и разнообразие клиентов, а также опишем, как Optimism Collective использует эту архитектуру для построения своей отказоустойчивой системы.
Протокол Ethereum извлекает выгоду из социальной децентрализации, в частности, предоставляя возможность выбора решений, которые позволяют широкому кругу участников участвовать в построении надежной децентрализованной сети.
Для программного обеспечения узла это означает разнообразие клиентов: чем больше у вас клиентов, тем меньшее влияние одна точка отказа оказывает на сеть валидатора.
Основные разработчики Layer1 описывают эту модель вклада как «базар», шумный и, казалось бы, хаотичный, но очень эффективный и динамичный. Приняв радикально открытый подход к разработке протокола, самый широкий круг участников может принять участие и улучшить протокол.
Optimism Collective имеет уникальные возможности для реализации и дальнейшего развития подхода Ethereum к социальной децентрализации: OP Stack достигает социальной децентрализации, предоставляя открытые спецификации и программное обеспечение с открытым исходным кодом под лицензией MIT, а Optimism Collective может достичь социальной децентрализации, создавая над ней итерации суперцепи.
Более детальное понимание архитектуры L2
Ethereum имеет открытую спецификацию на уровне L1 и модульную клиентскую архитектуру, которая разделяет уровень консенсуса и уровень исполнения.
OP-Stack реализует ту же архитектуру на L2:
Уровень консенсуса поддерживается op-node и Magi, двумя клиентами, которые следуют за L1 и экспортируют входные данные выполнения;
Уровень выполнения поддерживается op-geth, op-erigon и op-reth;
Однако архитектура L2 добавляет к этому стеку новый уровень: уровень проверки.
Это уровень, который надежно соединяет выходные данные L2 обратно с L1. Точно так же, как наличие нескольких клиентов является лучшей практикой для обеспечения консенсуса и выполнения как на L1, так и на L2, для уровня проверки L2 наличие нескольких методов аттестации может обеспечить оптимальную безопасность.
Подобно тому, как валидаторы с разными клиентами достигают консенсуса, кворум сетевых аттестаций может показать, что утверждения о состоянии L2 были проверены разными способами, что значительно снижает вероятность ошибок, приводящих к полному сбою.
В настоящее время существует три распространенных типа доказательств: аттестации, доказательства ошибок (также известные как доказательства мошенничества) и доказательства достоверности с нулевым разглашением. Последние два имеют общий шаблон: они выражают переходы состояний L2 в синхронной форме и доказывают их выполнение, учитывая данные L1 и предыдущее состояние L2 в качестве входных данных.
Изолируйте компоненты системы проверки для обеспечения разнообразия доказательств
Покажите, что систему можно далее разложить на независимые компоненты:
«Виртуальная машина» (ВМ) для запуска и проверки программы;
«оракул прообраза», который принимает в качестве входных данных данные L1 и предварительное состояние L2;
Многие из сегодняшних доказательств с нулевым разглашением все еще тесно связывают эти компоненты, создавая ZK-EVM, который работает на данных одной транзакции L1. Однако стек OP разделяет их, чтобы изолировать сложность и обеспечить разнообразие клиентов, делая все это более мощным.
Интерактивные доказательства ошибок добавляют игры пополам к трассировкам виртуальных машин для проверки доказательств в цепочке, в то время как основанные на виртуальных машинах доказательства с нулевым разглашением выполняют арифметические действия, сворачивают выполнение и предоставляют доказательства достоверности. (См. доказательства с нулевым разглашением на основе виртуальных машин, которые Risc0 и O(1)-Labs разрабатывают в ответ на запросы предложений Optimism ZK).
Программа определяет фактическое изменение состояния как «клиент», а получение входных данных (данные L1 и предварительное состояние L2) как «сервер». Программа работает независимо от сервера/клиента без виртуальной машины, как обычный узел блокчейна, и использует много общего кода.
Например, клиент op-программы Go создается путем импорта форка op-узла и EVM из op-geth, в то время как сервер получает свои данные из RPC L1 и L2 Ethereum.
Функциональный обзор FPVM
Отказоустойчивая виртуальная машина (FPVM) — это один из модулей отказоустойчивого стека в OP Stack.
Эта виртуальная машина не реализует ничего особенного для Ethereum или L2, кроме предоставления правильных интерфейсов (особенно тех, которые связаны с оракулами предварительного образа), а клиент программы проверки ошибок (FPP), работающий в FPVM, предназначен для выражения части преобразования состояния L2.
Благодаря такому разделению виртуальная машина остается минималистской: изменения в протоколе Ethereum (например, добавление кодов операций EVM) не влияют на виртуальную машину.
Вместо этого, когда протокол меняется, FPP можно просто обновить, чтобы импортировать новые компоненты перехода состояния в программное обеспечение узла. разные программы.
Виртуальная машина отвечает за выполнение инструкций низкого уровня и должна имитировать FPP. Требования к виртуальной машине ниже: программы выполняются синхронно, а все входные данные загружаются через один и тот же оракул-прообраз, но все это еще нужно доказать на цепочке L1 EVM.
Для этого одновременно можно доказать только одну инструкцию. Игра пополам сведет задачу доказательства полных следов выполнения к одной инструкции.
Доказательство инструкции может выглядеть по-разному для каждого FPVM, но обычно оно похоже на Cannon, который доказывает инструкцию следующим образом:
Для выполнения этой инструкции виртуальная машина имитирует нечто похожее на командный цикл потока-контекста: инструкция считывается из памяти, интерпретируется, при этом в регистровом файле и памяти могут происходить некоторые изменения;
Для поддержки основных потребностей времени выполнения программы, таких как предварительные образы оракулов и распределение памяти, выполнение также поддерживает подмножество системных вызовов Linux. Системные вызовы чтения/записи позволяют взаимодействовать с оракулом прообраза: программа записывает хеш как запрос на получение прообраза, а затем считывает его частями;
Cannon, первая FPVM, реализовала виртуальную машину MIPS именно таким образом. Дополнительные сведения о виртуальных машинах см. в соответствующей документации и спецификациях пушки. Интерфейс между FPVM и программами FP стандартизирован и документирован в спецификациях.
Из FPVM в ZKVM
Доказательства сбоев не являются единственным типом доказательства перехода состояний. Доказательства действительности ZK являются привлекательным вариантом из-за их потенциала для быстрого межсетевого моста (поскольку доказательства действительности ZK не содержат игр с вызовами в цепочке, нет окна для споров). Чтобы поддерживать расширенный стек Ethereum и размещать различные реализации клиентов, нам все равно необходимо отделить виртуальную машину и программу.
Это подход, использованный в проекте ZK RFP, чтобы доказать, что минимальная виртуальная машина RISC-V (от Risc0) или MIPS (от O(1) Labs) может содержать ту же программу, которая использовалась в доказательстве отказа.
Поддержка ZK-VM требует некоторых незначительных настроек, чтобы позволить оракулам-прообразам загружать данные в неинтерактивном режиме, но за счет обобщения виртуальной машины ZK оказывается более перспективным перед лицом изменений OP Stack.
Возможности для внешних участников
OP Stack приветствует дополнительные возможности виртуальных машин и программ, а также дополнительные независимые системы доказательств, от доказательств до доказательств с нулевым разглашением. Как и разнообразие клиентов, разнообразие доказательств — это коллективное усилие.
Дополнения к проверочному уровню OP Stack, которые в настоящее время находятся в разработке, включают:
RISC-V FPVM «Asterisc», разработанный protolambda и написанный на языке Go;
Программа Rust FP, основанная на Magi и op-reth, созданная участниками Base и OP Labs;
Программа Rust ZK на основе Zeth (ветвь ZK-reth), созданная Risc0;
По мере развития пушки, операционной программы, игры пополам и безграничного творчества сообщества открытого исходного кода появится множество дополнительных возможностей внести свой вклад в стек посредством тестовых реализаций и участия в программах вознаграждения за ошибки.
Источник: Голден Финанс
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Интерпретация отказоустойчивой системы, которую запустит OP Stack: большой шаг к децентрализации технологий, вдохновленных Ethereum
Автор: protolambda, исследователь OP Labs Составитель: Фрэнк, Foresight News
Чтобы создать самую мощную и безопасную, совместимую сеть уровня 2, Optimism Collective проводит децентрализацию по многим различным направлениям.
Предстоящая отказоустойчивая система OP Stack станет важным шагом на пути к технологической децентрализации.Открытый исходный код и модульная конструкция OP Stack создают беспрецедентный этап для социальной децентрализации экосистемы L2.
В этой статье мы рассмотрим принцип социальной децентрализации, то, как архитектура L2 позволяет уровню 2 расширить этот принцип, включив в него разнообразие доказательств и разнообразие клиентов, а также опишем, как Optimism Collective использует эту архитектуру для построения своей отказоустойчивой системы.
«Социальная децентрализация», вдохновленная Ethereum
Протокол Ethereum извлекает выгоду из социальной децентрализации, в частности, предоставляя возможность выбора решений, которые позволяют широкому кругу участников участвовать в построении надежной децентрализованной сети.
Для программного обеспечения узла это означает разнообразие клиентов: чем больше у вас клиентов, тем меньшее влияние одна точка отказа оказывает на сеть валидатора.
Основные разработчики Layer1 описывают эту модель вклада как «базар», шумный и, казалось бы, хаотичный, но очень эффективный и динамичный. Приняв радикально открытый подход к разработке протокола, самый широкий круг участников может принять участие и улучшить протокол.
Optimism Collective имеет уникальные возможности для реализации и дальнейшего развития подхода Ethereum к социальной децентрализации: OP Stack достигает социальной децентрализации, предоставляя открытые спецификации и программное обеспечение с открытым исходным кодом под лицензией MIT, а Optimism Collective может достичь социальной децентрализации, создавая над ней итерации суперцепи.
Более детальное понимание архитектуры L2
Ethereum имеет открытую спецификацию на уровне L1 и модульную клиентскую архитектуру, которая разделяет уровень консенсуса и уровень исполнения.
OP-Stack реализует ту же архитектуру на L2:
Уровень консенсуса поддерживается op-node и Magi, двумя клиентами, которые следуют за L1 и экспортируют входные данные выполнения;
Уровень выполнения поддерживается op-geth, op-erigon и op-reth;
Однако архитектура L2 добавляет к этому стеку новый уровень: уровень проверки.
Это уровень, который надежно соединяет выходные данные L2 обратно с L1. Точно так же, как наличие нескольких клиентов является лучшей практикой для обеспечения консенсуса и выполнения как на L1, так и на L2, для уровня проверки L2 наличие нескольких методов аттестации может обеспечить оптимальную безопасность.
Подобно тому, как валидаторы с разными клиентами достигают консенсуса, кворум сетевых аттестаций может показать, что утверждения о состоянии L2 были проверены разными способами, что значительно снижает вероятность ошибок, приводящих к полному сбою.
В настоящее время существует три распространенных типа доказательств: аттестации, доказательства ошибок (также известные как доказательства мошенничества) и доказательства достоверности с нулевым разглашением. Последние два имеют общий шаблон: они выражают переходы состояний L2 в синхронной форме и доказывают их выполнение, учитывая данные L1 и предыдущее состояние L2 в качестве входных данных.
Изолируйте компоненты системы проверки для обеспечения разнообразия доказательств
Покажите, что систему можно далее разложить на независимые компоненты:
Многие из сегодняшних доказательств с нулевым разглашением все еще тесно связывают эти компоненты, создавая ZK-EVM, который работает на данных одной транзакции L1. Однако стек OP разделяет их, чтобы изолировать сложность и обеспечить разнообразие клиентов, делая все это более мощным.
Интерактивные доказательства ошибок добавляют игры пополам к трассировкам виртуальных машин для проверки доказательств в цепочке, в то время как основанные на виртуальных машинах доказательства с нулевым разглашением выполняют арифметические действия, сворачивают выполнение и предоставляют доказательства достоверности. (См. доказательства с нулевым разглашением на основе виртуальных машин, которые Risc0 и O(1)-Labs разрабатывают в ответ на запросы предложений Optimism ZK).
Программа определяет фактическое изменение состояния как «клиент», а получение входных данных (данные L1 и предварительное состояние L2) как «сервер». Программа работает независимо от сервера/клиента без виртуальной машины, как обычный узел блокчейна, и использует много общего кода.
Например, клиент op-программы Go создается путем импорта форка op-узла и EVM из op-geth, в то время как сервер получает свои данные из RPC L1 и L2 Ethereum.
Функциональный обзор FPVM
Отказоустойчивая виртуальная машина (FPVM) — это один из модулей отказоустойчивого стека в OP Stack.
Эта виртуальная машина не реализует ничего особенного для Ethereum или L2, кроме предоставления правильных интерфейсов (особенно тех, которые связаны с оракулами предварительного образа), а клиент программы проверки ошибок (FPP), работающий в FPVM, предназначен для выражения части преобразования состояния L2.
Благодаря такому разделению виртуальная машина остается минималистской: изменения в протоколе Ethereum (например, добавление кодов операций EVM) не влияют на виртуальную машину.
Вместо этого, когда протокол меняется, FPP можно просто обновить, чтобы импортировать новые компоненты перехода состояния в программное обеспечение узла. разные программы.
Виртуальная машина отвечает за выполнение инструкций низкого уровня и должна имитировать FPP. Требования к виртуальной машине ниже: программы выполняются синхронно, а все входные данные загружаются через один и тот же оракул-прообраз, но все это еще нужно доказать на цепочке L1 EVM.
Для этого одновременно можно доказать только одну инструкцию. Игра пополам сведет задачу доказательства полных следов выполнения к одной инструкции.
Доказательство инструкции может выглядеть по-разному для каждого FPVM, но обычно оно похоже на Cannon, который доказывает инструкцию следующим образом:
Cannon, первая FPVM, реализовала виртуальную машину MIPS именно таким образом. Дополнительные сведения о виртуальных машинах см. в соответствующей документации и спецификациях пушки. Интерфейс между FPVM и программами FP стандартизирован и документирован в спецификациях.
Из FPVM в ZKVM
Доказательства сбоев не являются единственным типом доказательства перехода состояний. Доказательства действительности ZK являются привлекательным вариантом из-за их потенциала для быстрого межсетевого моста (поскольку доказательства действительности ZK не содержат игр с вызовами в цепочке, нет окна для споров). Чтобы поддерживать расширенный стек Ethereum и размещать различные реализации клиентов, нам все равно необходимо отделить виртуальную машину и программу.
Это подход, использованный в проекте ZK RFP, чтобы доказать, что минимальная виртуальная машина RISC-V (от Risc0) или MIPS (от O(1) Labs) может содержать ту же программу, которая использовалась в доказательстве отказа.
Поддержка ZK-VM требует некоторых незначительных настроек, чтобы позволить оракулам-прообразам загружать данные в неинтерактивном режиме, но за счет обобщения виртуальной машины ZK оказывается более перспективным перед лицом изменений OP Stack.
Возможности для внешних участников
OP Stack приветствует дополнительные возможности виртуальных машин и программ, а также дополнительные независимые системы доказательств, от доказательств до доказательств с нулевым разглашением. Как и разнообразие клиентов, разнообразие доказательств — это коллективное усилие.
Дополнения к проверочному уровню OP Stack, которые в настоящее время находятся в разработке, включают:
По мере развития пушки, операционной программы, игры пополам и безграничного творчества сообщества открытого исходного кода появится множество дополнительных возможностей внести свой вклад в стек посредством тестовых реализаций и участия в программах вознаграждения за ошибки.
Источник: Голден Финанс