В этой статье рассматривается принцип социальной децентрализации, как L2 архитектура позволяет расширить этот принцип, включая разнообразие доказательств, и как Коллектив Optimism строит свою неуязвимую систему (fault proof system), чтобы использовать эту архитектуру.

Перевод оригинальной статьи от 25 сентября 2023

Для создания наиболее надежной и безопасной сети взаимодействующих L2 сетей, Коллектив Optimism реализует децентрализацию в различных направлениях.

Предстоящая неуязвимая система OP Stack станет огромным шагом вперед в технической децентрализации, а открытый и модульный дизайн OP Stack готовит почву для беспрецедентной социальной децентрализации в L2 экосистеме.

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

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

Разработчики в L1 описывают эту модель внесения вклада как "базар": шумный и кажущийся хаотичным, но чрезвычайно продуктивный и энергичный. С радикальным открытым подходом к разработке протокола наибольший круг участников может улучшать протокол.

Коллектив Optimism уникально позиционирован для реализации и итерации подхода Ethereum к социальной децентрализации. OP Stack обеспечивает социальную децентрализацию с открытыми спецификациями и лицензированным под открытым исходным кодом MIT, и Коллектив Optimism итерирует над ним с созданием Superchain.

Эфириум L1 имеет открытые спецификации и модульную архитектуру клиента, которая разделяет уровни консенсуса и выполнения. OP Stack реализует эту же архитектуру для L2:

• Консенсус обеспечивается клиентами op-node и Magi, которые следуют L1 и получают входные данные для выполнения.

• Выполнение поддерживается op-geth, op-erigon и op-reth.

Архитектура L2 добавляет новый уровень к этому стеку: уровень доказательств. Это уровень, который безопасно связывает выводы L2 с обратной стороны с L1. Точно так же, как наличие нескольких клиентов является bewведением для обеспечения безопасности консенсуса и выполнения на L1 и L2, многодоказательный подход для уровня доказательств L2 обеспечивает наилучшую безопасность.

Подобно разнообразию клиентов в наборе валидаторов, достигающем консенсуса, кворум ончейн-доказательств может сигнализировать о том, что утверждение состояния L2 было проверено разными способами, что значительно снижает риск возникновения ошибки, приводящей к полному сбою.

Существуют три общих типа доказательств: аттестации, доказательства вины (также известные как доказательства мошенничества) и доказательства валидности ZK. Последние два имеют общий шаблон. Они выражают переход состояния L2 в синхронной форме и доказывают его выполнение при предоставлении входных данных L1 и предварительного состояния L2.

Системы доказательств могут быть еще дополнительно разделены на изолированные компоненты:

1. "Программа" определяет синхронный переход состояния L2.

2. "Виртуальная машина (VM)" выполняет программу и доказывает ее.

3. "Предварительный образ оракула" предоставляет данные L1 и предварительное состояние L2 в качестве входных данных.

Многие ZK-доказательства по-прежнему тесно связывают эти компоненты, создавая ZK-EVM, которая работает с единичными данными L1-транзакции. Однако OP Stack разделяет их, чтобы изолировать сложность и обеспечить разнообразие клиентов, что делает систему более надежной.

Интерактивные доказательства вины добавляют бисекционную игру к следу VM для проверки доказательства на цепи, в то время как ZK-доказательства, основанные на VM, арифметизируют и сворачивают выполнение в доказательстве валидности. (См. ZK-proofs на основе VM, которые разрабатывают Risc0 и O(1)-Labs в ответ на запросы на предложение по Optimism ZK RFP).

Программа определяет фактический переход состояния как "клиент", а получение входных данных (данные L1 и предварительное состояние L2) как "сервер". Если программа работает автономно с сервером/клиентом, но без VM, то она очень похожа на обычный блокчейн-узел и использует много кода. Например, клиент программы на Go создается путем импорта данных из op-node и EVM из op-geth, а сервер получает данные из L1 и L2 через Ethereum RPC.

Fault Proof VM (FPVM) - это один из модулей в стеке надежной OP Stack.

VM не реализует ничего конкретного для Ethereum или L2, за исключением предоставления правильных интерфейсов (в частности, интерфейса к предварительному оракулу). Программа Fault Proof (FPP) (на стороне клиента), выполняющаяся внутри FPVM, является частью, которая выражает переход состояния L2.

Благодаря этому разделению VM остается ультраминимальной: изменения протокола Ethereum, такие как добавление операций EVM, не влияют на VM. Вместо этого, при изменении протокола FPP можно просто обновить, чтобы импортировать новые компоненты перехода состояния из программного обеспечения узла. Аналогично игре новой версии на той же игровой консоли, систему доказательства L1 можно обновить, чтобы доказать другую программу.

Задачей VM является выполнение инструкций на более низком уровне. FPP должен быть эмулирован. Требования к VM невелики: программа синхронна, и все входные данные загружаются через тот же предварительный оракул, но всё это всё равно должно быть доказано в L1 EVM в цепи!

Для этого доказывается только одна инструкция за раз. Бисекционная игра уменьшит задачу доказательства полного следа выполнения до одной единственной инструкции.

Доказание инструкции может выглядеть по-разному для каждой FPVM, но обычно оно выглядит похожим на Cannon, который доказывает инструкцию следующим образом:

1. Для выполнения инструкции VM эмулирует нечто подобное циклу инструкции контекста потока: инструкция считывается из памяти, интерпретируется, и регистр-файл и память могут немного измениться.

2. Для поддержки предварительного оракула и базовых потребностей выполнения программы, таких как выделение памяти, выполнение также поддерживает подмножество системных вызовов Linux. Системные вызовы read/write позволяют взаимодействовать с предварительным оракулом: программа записывает хэш в качестве запроса на получение предварительного образа, а затем читает значение порциями.

Cannon, первый FPVM, реализует MIPS VM таким образом. Пожалуйста, см. документацию и спецификации cannon для получения дополнительной информации о VM. Интерфейс между FPVM и FP-программой стандартизирован и описан в спецификациях.

Fault proofs - это не единственный тип доказательств перехода состояния. Доказательства валидности ZK (ZK validity-proofs) представляют собой привлекательную опцию из-за потенциала для быстрого моста (поскольку для доказательств валидности ZK не существует ончейн игры оспаривания, нет окна для споров). Для поддержки расширенного стека Ethereum и размещения различных клиентских реализаций нам все равно нужно разделить VM и программу.

Этот подход используют проекты, связанные с запросами на предложение по оптимизации в области ZK, чтобы доказать минимальную VM RISC-V (Risc0) или MIPS (O(1) Labs), которая может размещать ту же программу, что и в случае с доказательствами вины.

Для поддержки ZK-VM требуются небольшие адаптации, чтобы предварительный оракул загружал данные в режиме нераздельного взаимодействия, но, обобщая VM, ZK-доказательство становится более устойчивым к будущим изменениям в стеке OP Stack.

OP Stack приветствует дополнительные варианты VM и программ, а также дополнительные независимые системы доказательств, начиная с аттестаций и заканчивая ZK. Как и разнообразие клиентов, разнообразие доказательств - это коллективное усилие!

Текущие дополнения к доказательственному уровню OP Stack включают:

1. FPVM RISC-V "Asterisc", написанный на Go, разрабатывается протоламбдой.

2. Rust FP-программа, основанная на Magi и op-reth, создается совместно с участниками из Base и OP Labs.

3. Rust ZK-программа, основанная на zeth (форке ZK-reth), создается Risc0.

С развитием Cannon, op-программы, бисекционной игры, вышеуказанных компонентов и бесконечным изобретательством открытого исходного кода существует множество дополнительных возможностей для участия в разработке стека путем тестирования реализаций и участия в баг-баунти! Все заинтересованные могут добавить в закладки страницу Bug Bounty от Immunefi Optimism для поиска новых наград, связанных с системой надежности OP Stack. 👀

В этой статье рассматривается принцип социальной децентрализации, как L2 архитектура позволяет расширить этот принцип, включая разнообразие доказательств, и как Коллектив Optimism строит свою неуязвимую систему (fault proof system), чтобы использовать эту архитектуру.

Перевод оригинальной статьи от 25 сентября 2023

Для создания наиболее надежной и безопасной сети взаимодействующих L2 сетей, Коллектив Optimism реализует децентрализацию в различных направлениях.

Предстоящая неуязвимая система OP Stack станет огромным шагом вперед в технической децентрализации, а открытый и модульный дизайн OP Stack готовит почву для беспрецедентной социальной децентрализации в L2 экосистеме.

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

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

Разработчики в L1 описывают эту модель внесения вклада как "базар": шумный и кажущийся хаотичным, но чрезвычайно продуктивный и энергичный. С радикальным открытым подходом к разработке протокола наибольший круг участников может улучшать протокол.

Коллектив Optimism уникально позиционирован для реализации и итерации подхода Ethereum к социальной децентрализации. OP Stack обеспечивает социальную децентрализацию с открытыми спецификациями и лицензированным под открытым исходным кодом MIT, и Коллектив Optimism итерирует над ним с созданием Superchain.

Эфириум L1 имеет открытые спецификации и модульную архитектуру клиента, которая разделяет уровни консенсуса и выполнения. OP Stack реализует эту же архитектуру для L2:

• Консенсус обеспечивается клиентами op-node и Magi, которые следуют L1 и получают входные данные для выполнения.

• Выполнение поддерживается op-geth, op-erigon и op-reth.

Архитектура L2 добавляет новый уровень к этому стеку: уровень доказательств. Это уровень, который безопасно связывает выводы L2 с обратной стороны с L1. Точно так же, как наличие нескольких клиентов является bewведением для обеспечения безопасности консенсуса и выполнения на L1 и L2, многодоказательный подход для уровня доказательств L2 обеспечивает наилучшую безопасность.

Подобно разнообразию клиентов в наборе валидаторов, достигающем консенсуса, кворум ончейн-доказательств может сигнализировать о том, что утверждение состояния L2 было проверено разными способами, что значительно снижает риск возникновения ошибки, приводящей к полному сбою.

Существуют три общих типа доказательств: аттестации, доказательства вины (также известные как доказательства мошенничества) и доказательства валидности ZK. Последние два имеют общий шаблон. Они выражают переход состояния L2 в синхронной форме и доказывают его выполнение при предоставлении входных данных L1 и предварительного состояния L2.

Системы доказательств могут быть еще дополнительно разделены на изолированные компоненты:

1. "Программа" определяет синхронный переход состояния L2.

2. "Виртуальная машина (VM)" выполняет программу и доказывает ее.

3. "Предварительный образ оракула" предоставляет данные L1 и предварительное состояние L2 в качестве входных данных.

Многие ZK-доказательства по-прежнему тесно связывают эти компоненты, создавая ZK-EVM, которая работает с единичными данными L1-транзакции. Однако OP Stack разделяет их, чтобы изолировать сложность и обеспечить разнообразие клиентов, что делает систему более надежной.

Интерактивные доказательства вины добавляют бисекционную игру к следу VM для проверки доказательства на цепи, в то время как ZK-доказательства, основанные на VM, арифметизируют и сворачивают выполнение в доказательстве валидности. (См. ZK-proofs на основе VM, которые разрабатывают Risc0 и O(1)-Labs в ответ на запросы на предложение по Optimism ZK RFP).

Программа определяет фактический переход состояния как "клиент", а получение входных данных (данные L1 и предварительное состояние L2) как "сервер". Если программа работает автономно с сервером/клиентом, но без VM, то она очень похожа на обычный блокчейн-узел и использует много кода. Например, клиент программы на Go создается путем импорта данных из op-node и EVM из op-geth, а сервер получает данные из L1 и L2 через Ethereum RPC.

Fault Proof VM (FPVM) - это один из модулей в стеке надежной OP Stack.

VM не реализует ничего конкретного для Ethereum или L2, за исключением предоставления правильных интерфейсов (в частности, интерфейса к предварительному оракулу). Программа Fault Proof (FPP) (на стороне клиента), выполняющаяся внутри FPVM, является частью, которая выражает переход состояния L2.

Благодаря этому разделению VM остается ультраминимальной: изменения протокола Ethereum, такие как добавление операций EVM, не влияют на VM. Вместо этого, при изменении протокола FPP можно просто обновить, чтобы импортировать новые компоненты перехода состояния из программного обеспечения узла. Аналогично игре новой версии на той же игровой консоли, систему доказательства L1 можно обновить, чтобы доказать другую программу.

Задачей VM является выполнение инструкций на более низком уровне. FPP должен быть эмулирован. Требования к VM невелики: программа синхронна, и все входные данные загружаются через тот же предварительный оракул, но всё это всё равно должно быть доказано в L1 EVM в цепи!

Для этого доказывается только одна инструкция за раз. Бисекционная игра уменьшит задачу доказательства полного следа выполнения до одной единственной инструкции.

Доказание инструкции может выглядеть по-разному для каждой FPVM, но обычно оно выглядит похожим на Cannon, который доказывает инструкцию следующим образом:

1. Для выполнения инструкции VM эмулирует нечто подобное циклу инструкции контекста потока: инструкция считывается из памяти, интерпретируется, и регистр-файл и память могут немного измениться.

2. Для поддержки предварительного оракула и базовых потребностей выполнения программы, таких как выделение памяти, выполнение также поддерживает подмножество системных вызовов Linux. Системные вызовы read/write позволяют взаимодействовать с предварительным оракулом: программа записывает хэш в качестве запроса на получение предварительного образа, а затем читает значение порциями.

Cannon, первый FPVM, реализует MIPS VM таким образом. Пожалуйста, см. документацию и спецификации cannon для получения дополнительной информации о VM. Интерфейс между FPVM и FP-программой стандартизирован и описан в спецификациях.

Fault proofs - это не единственный тип доказательств перехода состояния. Доказательства валидности ZK (ZK validity-proofs) представляют собой привлекательную опцию из-за потенциала для быстрого моста (поскольку для доказательств валидности ZK не существует ончейн игры оспаривания, нет окна для споров). Для поддержки расширенного стека Ethereum и размещения различных клиентских реализаций нам все равно нужно разделить VM и программу.

Этот подход используют проекты, связанные с запросами на предложение по оптимизации в области ZK, чтобы доказать минимальную VM RISC-V (Risc0) или MIPS (O(1) Labs), которая может размещать ту же программу, что и в случае с доказательствами вины.

Для поддержки ZK-VM требуются небольшие адаптации, чтобы предварительный оракул загружал данные в режиме нераздельного взаимодействия, но, обобщая VM, ZK-доказательство становится более устойчивым к будущим изменениям в стеке OP Stack.

OP Stack приветствует дополнительные варианты VM и программ, а также дополнительные независимые системы доказательств, начиная с аттестаций и заканчивая ZK. Как и разнообразие клиентов, разнообразие доказательств - это коллективное усилие!

Текущие дополнения к доказательственному уровню OP Stack включают:

1. FPVM RISC-V "Asterisc", написанный на Go, разрабатывается протоламбдой.

2. Rust FP-программа, основанная на Magi и op-reth, создается совместно с участниками из Base и OP Labs.

3. Rust ZK-программа, основанная на zeth (форке ZK-reth), создается Risc0.

С развитием Cannon, op-программы, бисекционной игры, вышеуказанных компонентов и бесконечным изобретательством открытого исходного кода существует множество дополнительных возможностей для участия в разработке стека путем тестирования реализаций и участия в баг-баунти! Все заинтересованные могут добавить в закладки страницу Bug Bounty от Immunefi Optimism для поиска новых наград, связанных с системой надежности OP Stack. 👀