Interpretação do sistema à prova de falhas a ser lançado pelo OP Stack: Inspirado no Ethereum, um grande passo em direção à descentralização tecnológica

Autor: protolambda, pesquisador do OP Labs

Compilado por: Frank, Foresight News

A fim de criar a rede interoperável de Camada 2 mais poderosa e segura, o Optimism Collective está buscando a descentralização através de muitos caminhos diferentes.

O próximo sistema à prova de falhas do OP Stack será um passo importante em direção à descentralização tecnológica.O código aberto e o design modular do OP Stack estão criando um estágio sem precedentes para a descentralização social do ecossistema L2.

Neste artigo, exploraremos o princípio da descentralização social, como a arquitetura L2 permite que a Camada 2 estenda esse princípio para incluir a diversidade de provas e a diversidade de clientes, e descreveremos como o Optimism Collective aproveita essa arquitetura para construir seu sistema à prova de falhas.

“Descentralização Social” inspirada em Ethereum

O protocolo Ethereum beneficia da descentralização social, particularmente ao fornecer opcionalidade em soluções que permitem que uma vasta gama de contribuidores participem na construção de uma rede descentralizada robusta.

Para software de nó, isso significa diversidade de clientes: quanto mais clientes você tiver, menor será o impacto que um único ponto de falha terá na rede do validador.

Os principais desenvolvedores da Layer1 descrevem esse modelo de contribuição como um “bazar”, que é barulhento e aparentemente caótico, mas muito eficiente e dinâmico. Ao adotar uma abordagem radicalmente aberta ao desenvolvimento de protocolos, a mais ampla gama de colaboradores pode participar e melhorar o protocolo.

O Optimism Collective está em uma posição única para implementar e iterar a abordagem da Ethereum para a descentralização social: o OP Stack alcança a descentralização social fornecendo especificações abertas e software de código aberto sob a licença do MIT, e o Optimism Collective pode alcançar a descentralização social criando iterações de supercadeias sobre ele.

Uma compreensão mais detalhada da arquitetura L2

Ethereum tem uma especificação aberta em L1 e uma arquitetura de cliente modular que separa a camada de consenso e a camada de execução.

OP-Stack implementa a mesma arquitetura em L2:

A camada de consenso é alimentada por op-node e Magi, dois clientes que seguem L1 e exportam entradas de execução;

A camada de execução é suportada por op-geth, op-erigon e op-reth;

No entanto, a arquitetura L2 adiciona uma nova camada a esta pilha: a camada de prova.

Esta é a camada que conecta com segurança as saídas L2 de volta ao L1. Assim como ter vários clientes é uma prática recomendada para garantir o consenso e a execução em L1 e L2, para a camada de verificação de L2, ter vários métodos de atestado pode garantir a segurança ideal.

Semelhante aos validadores com diferentes clientes que chegam a um consenso, um quórum de atestados na cadeia pode mostrar que as reivindicações do estado L2 foram verificadas de diferentes maneiras, reduzindo enormemente a possibilidade de erros que levem à falha completa.

Atualmente, existem três tipos comuns de provas: atestados, provas de erro (também conhecidas como provas de fraude) e provas de validade de conhecimento zero. Os dois últimos compartilham um padrão comum, pois expressam transições de estado L2 de forma síncrona e provam sua execução dados os dados L1 e o estado anterior de L2 como entrada.

Isole os componentes do sistema de prova para obter diversidade de prova

Mostre que o sistema pode ser ainda decomposto em componentes independentes:

• Um “programa” que define transições de estado L2 síncronas;
• Uma “máquina virtual” (VM) para executar e verificar o programa;
• Um “oráculo de pré-imagem” que recebe dados L1 e pré-estado L2 como entrada;

Muitas das provas de conhecimento zero atuais ainda acoplam esses componentes, criando um ZK-EVM que é executado em dados de transação L1 únicos. No entanto, a pilha OP os separa para isolar a complexidade e permitir a diversidade de clientes, tornando o todo mais poderoso.

Provas de falha interativas adicionam jogos de bissecção aos rastreamentos de máquinas virtuais para verificar provas em cadeia, enquanto provas de conhecimento zero baseadas em máquinas virtuais aritméticas e dobram a execução e fornecem provas de validade. (Veja as provas de conhecimento zero baseadas em máquina virtual que Risc0 e O(1)-Labs estão projetando em resposta às RFPs do Optimism ZK).

O programa define a transição de estado real como o “cliente” e a aquisição de entrada (dados L1 e pré-estado L2) como o “servidor”. O programa é executado independentemente do servidor/cliente sem uma máquina virtual, como um nó blockchain normal, e compartilha muito código.

Por exemplo, o cliente do programa operacional Go é construído importando o fork do nó operacional e o EVM do op-geth, enquanto o servidor obtém seus dados de RPCs Ethereum L1 e L2.

Visão geral funcional do FPVM

A máquina virtual à prova de falhas (FPVM) é um dos módulos da pilha à prova de falhas no OP Stack.

Esta VM não implementa nada específico para Ethereum ou L2 além de fornecer as interfaces corretas (especialmente aquelas relacionadas a oráculos de pré-imagem).O cliente Fault Proofing Program (FPP) em execução dentro do FPVM é para expressar o estado L2.parte de conversão.

Com esta separação, a máquina virtual é mantida minimalista: alterações no protocolo Ethereum (como a adição de opcodes EVM) não afetam a máquina virtual.

Em vez disso, quando o protocolo muda, o FPP pode simplesmente ser atualizado para importar os novos componentes de transição de estado no software do nó. Semelhante a jogar uma nova versão do jogo no mesmo console de jogo, o sistema de atestado L1 pode ser atualizado para atestar programas diferentes.

A máquina virtual é responsável por executar instruções de baixo nível e precisa simular FPP. Os requisitos da máquina virtual são menores: os programas são executados de forma síncrona e todas as entradas são carregadas através do mesmo oráculo de pré-imagem, mas tudo isso ainda precisa ser comprovado na cadeia L1 EVM.

Para fazer isso, apenas uma instrução pode ser provada por vez. O jogo de bissecção reduzirá a tarefa de provar traços de execução completos a apenas uma instrução.

A prova da instrução pode parecer diferente para cada FPVM, mas geralmente é semelhante ao Cannon, que prova a instrução da seguinte forma:

• Para executar esta instrução, a máquina virtual simula algo semelhante ao ciclo de instrução de um contexto de thread: a instrução é lida da memória, interpretada e algumas alterações podem ocorrer no arquivo de registradores e na memória;
• Para dar suporte às necessidades básicas de tempo de execução do programa, como oráculos de pré-imagem e alocação de memória, a execução também oferece suporte a um subconjunto de chamadas de sistema Linux. As chamadas de sistema de leitura/gravação permitem a interação com o oráculo de pré-imagem: o programa escreve o hash como uma solicitação para obter a pré-imagem e depois o lê em pedaços de cada vez;

Cannon, o primeiro FPVM, implementou a máquina virtual MIPS desta forma. Para obter mais informações sobre máquinas virtuais, consulte a documentação relacionada e as especificações do canhão. A interface entre os programas FPVM e FP é padronizada e documentada em especificações.

De FPVM para ZKVM

As provas de falha não são o único tipo de prova de transição de estado, as provas de validade ZK são uma opção atraente devido ao seu potencial para pontes rápidas entre cadeias (uma vez que as provas de validade ZK não têm jogos de desafio na cadeia, não há janela de disputa). Para suportar a pilha Ethereum avançada e hospedar diferentes implementações de clientes, ainda precisamos dissociar a máquina virtual e o programa.

Esta é a abordagem adotada pelo projeto ZK RFP para provar que uma máquina virtual mínima RISC-V (por Risc0) ou MIPS (por O(1) Labs) pode hospedar o mesmo programa usado na prova de falha.

O suporte ao ZK-VM requer alguns pequenos ajustes para permitir que os oráculos de pré-imagem carreguem dados de forma não interativa, mas ao generalizar a máquina virtual, o ZK prova ser mais preparado para o futuro diante das mudanças no OP Stack.

Oportunidades para colaboradores externos

OP Stack aceita opções adicionais de máquinas virtuais e programas, bem como sistemas de prova independentes adicionais, desde provas até provas de conhecimento zero. Assim como a diversidade de clientes, a diversidade de provas é um esforço coletivo.

As adições à camada de prova do OP Stack atualmente em andamento incluem:

• RISC-V FPVM “Asterisc” desenvolvido pela protolambda e escrito em linguagem Go;
• Programa Rust FP baseado em Magi e op-reth desenvolvido por colaboradores do Base e OP Labs;
• Programa Rust ZK baseado em zeth (ramo ZK-reth) construído por Risc0;

À medida que o canhão, o programa operacional, o jogo de bissecção e a criatividade ilimitada da comunidade de código aberto evoluem, haverá muitas oportunidades adicionais para contribuir com a pilha por meio de implementações de testes e participação em programas de recompensa de bugs.