Provas de Fraude e Máquinas Virtuais
Aviso: O artigo abaixo é uma tradução amadora feita por um membro da comunidade Oasis. Para ler o conteúdo original, acesse: Fraud proofs and virtual machines
Este artigo é um resumo do artigo de pesquisa — SoK: Validating Bridges as a Scaling Solution for Blockchains — Escrito pela CEO e Fundadora da Oasis Labs, Dawn Song, Patrick McCorry, Bennet Yee e publicado originalmente por Chris Buckland em seu blog aqui.
Rollups fornecem escalonamento a blockchain movendo a execução para um domínio diferente. Os dados da transação são colocados na rede principal, mas as transações não são executadas lá. Em vez disso, eles são executados na rede de rollup e, periodicamente, um compromisso com estado de rollup atual é postado de volta na rede principal. Isso significa que os nós da rede principal não são mais necessários para executar as transações, reduzindo sua carga.
Mas como a rede principal pode ser convencida de que o informe atual do rollup está correto? Os Rollups possuem duas categorias diferentes, que resolvem esse problema de maneiras diferentes:
- Rollups-zk: O estado do rollups é provado por uma prova de zero-knowledge (conhecimento zero).
- Rollups otimistas: O compromisso enviado do estado do rollups postado é aceito de forma otimista, mas os validadores os verificam e enviam uma prova de fraude se acharem que o estado do rollup postado está incorreto. No caso de rollups otimistas, o compromisso com o estado do rollup postado também é chamado de afirmação, pois o estado está sendo afirmado e não provado.
Rollups otimistas exigem que os validadores verifiquem as transições de estado e enviem provas de fraude se encontrarem
Nessa postagem, vamos nos concentrar apenas em rollupś otimistas e nas provas de fraude que os mantêm seguros. Veremos como eles são empregados atualmente por dois rolluṕs otimistas populares — Arbitrum e Optimism — e quais são as atuais orientações de pesquisa à prova de fraude.
Para obter mais detalhes sobre como os rollups funcionam no geral, posso recomendar esta postagem de blog.
Provas de fraude
As provas de fraude atuais vem em dois sabores diferentes:
- Não interativa
- Interativa
As provas de fraude não interativas permitem que uma parte prove a inexatidão de uma afirmação sem a participação de quaisquer outras partes. Eles fazem isso executando todas as transições de estado entre dois compromissos do estado do rollup declarados para mostrar que o compromisso resultante difere do declarado. As provas de fraude não interativas têm a vantagem de serem simples de raciocinar e projetar. No entanto, a menos que esteja usando um zk-proof, a transição entre as duas asserções deve ser pequena o suficiente para ser executada na rede, o que, combinado com as habilidades atuais da Ethereum, coloca limitações severas das transições que podem ser efetivamente verificadas por este estilo de à prova de fraude.
Provas de fraude interativas exigem que duas ou mais partes trabalhem juntas para mostrar que uma afirmação é válida ou inválida. Na prática, os designs atuais envolvem um defensor (a parte que faz a afirmação) e um desafiante. O desafiante solicita que o defensor divida sua afirmação em sub-afirmações, para as quais o desafiante pode então escolher a sub-afirmação com a qual discorda. Eles continuam solicitando a bissecção da sub-afirmação e assim por diante, até chegarem a uma afirmação que representa uma operação pequena o suficiente para ser executada na rede. As provas interativas de fraude introduzem a complexidade da cooperação entre as partes. Os incentivos envolvidos tornam-nos inerentemente mais complicados de projetar com segurança. No entanto, a única limitação em relação à execução é que uma única operação deve ser executável na rede, o que significa que as transações e os blocos no rollup não são restringidos por nenhum dos limites L1.
Então, quais provas de fraude alguns dos atuais rollups otimistas empregam?
Optimism
Provas de fraude não interativas são o lugar mais atraente para começar e, de fato, esta foi a direção que o Optimism tomou em sua primeira versão. No entanto, para a V2, eles estão adotando provas interativas. Para ver por que, vamos examinar mais de perto as limitações de uma prova de fraude não interativa.
As provas de fraude não interativas precisam executar a transição de estado completa entre duas afirmações. O Optimism escolheu o nível de transação como a granularidade para a transição de estado, na esperança de permitir que os usuários sejam capazes de executar transações Ethereum normais em seu rollup.
No entanto, a reexecução de uma transação Ethereum que ocorreu no rollup de volta na rede principal Ethereum não é suportada nativamente pela Ethereum. Isso ocorre porque as transações têm acesso ao estado e contas subjacentes da rede, que diferem entre o rollup e a rede principal.
Para que o Optimism execute novamente suas transações na rede principal, eles precisam substituir os opcodes que acessam o estado e as contas por outros sintéticos que fazem chamadas para um contrato específico pré-preenchido com o estado relevante. Um número total de 18 opcodes foram substituídos desta forma, com mais 6 sendo removidos completamente. Diz-se que o bytecode com esses opcodes substituídos por chamadas de função são executados dentro da Máquina Virtual da Optimism (OVM). O otimismo fez um fork (criou uma segunda versão paralela a partir do código da primeira) do compilador Solidity para permitir que os desenvolvedores compilem seus contratos para a OVM.
- Substituir instruções de acesso de estado por chamadas de contrato infla severamente o tamanho do bytecode de alguns contratos. A Ethereum tem um limite de ~ 25kB no tamanho do contrato, o que significa que, após serem traduzidos da EVM para a OVM, alguns contratos exigiriam refatoração ou precisariam ser quebrados para possibilitar que sejam postados novamente durante uma prova de fraude.
- Fazer chamadas em vez de usar o acesso de estado nativo requer muito mais “gas”, portanto, as transações em execução na OVM efetivamente tinham um limite de gas inferior do que seus equivalentes que estavam sendo executados na Ethereum.
Os contratos traduzidos da EVM para o bytecode OVM sofrem de duas limitações principais:
Ambas as limitações afetam os desenvolvedores de contrato e usuários, exigindo muito esforço dos desenvolvedores para reescrever os contratos que foram projetados para rodar na rede principal Ethereum. Dado que o desenvolvimento do contrato é um processo caro, demorado e de segurança intensiva, essas limitações representam um obstáculo significativo para a adoção do Optimism V1 e é a principal razão para a sua mudança para provas de fraude interativas.
Arbitrum
Um rollup que atualmente usa provas interativas de fraude na produção é o Arbitrum. Seu protocolo permite que um defensor e um desafiante dividam as afirmações um do outro até que encontrem uma única etapa da qual discordam e, em seguida, executam na rede. O tamanho do único passo escolhido pelo Arbitrum é o de uma única instrução. Executar uma única instrução de uma máquina virtual requer acesso ao estado interno da máquina virtual. Isso inclui a pilha e a memória, bem como o estado e os globais. Deve ser escrito um intérprete para a máquina virtual que pode ser executado na Ethereum e executar instruções únicas.
Como eles precisariam escrever um interpretador de máquina virtual, a Arbitrum escolheu escrever um novo otimizado para seu caso de uso de provar a execução de etapas únicas, em vez de escrever um interpretador para o EVM. Um exemplo de uma otimização que eles fizeram foi alterar a estrutura da memória da VM (máquina virtual) para ser imutável, de forma que ela sempre possa ser acessada em tempo constante ao invés de logarítmico como a estrutura EVM atual exigiria. Eles chamaram essa máquina virtual otimizada de rollup de AVM (Arbitrum Virtual Machine).
Os contratos e transações AVM não têm as mesmas limitações que os OVM, uma vez que as transações nunca são totalmente executadas, eles podem até mesmo exceder os limites da rede principal Ethereum se os nós da Arbitrum permitirem. Escrever uma nova máquina virtual tem outras vantagens. Uma vez que qualquer coisa escrita em código AVM pode ser comprovada na Ethereum, os desenvolvedores do Arbitrum podem incluir novos opcodes, desde que possam ser apoiados por opcodes da EVM. Isso permite que eles incorporem facilmente outro comportamento de nó, como ler transações de seus contratos de caixa de entrada, no conjunto de operações que podem ser comprovadas como corretas. A Arbitrum pode usar o mesmo tipo de prova de fraude para qualquer comportamento de seu nó que deseje tornar comprovável.
Uma grande desvantagem de escrever uma nova máquina virtual é que ela nem sempre é compatível com a Ethereum e, onde a compatibilidade é possível, pode ser necessário um esforço extra para alcançá-la.
Divergindo da Ethereum
Ambas as abordagens acima divergem da EVM, que apresenta desafios de engenharia para Arbitrum, Optimism e seus usuários. Os desenvolvedores que escrevem contratos para o EVM esperam que seus contratos sejam executados na AVM e na OVM, eles esperam que as ferramentas existentes funcionem e os JSON-RPCs sejam consistentes com a Ethereum. Para conseguir isso, os rollups podem precisar fazer um shim (mudar parcialmente) dos terminais JSON-RPC do nó para se comportarem de forma consistente, o que é possível em alguns casos, mas não em outros.
Um exemplo de onde a Arbitrum atingiu a paridade é na aceitação de transações EVM. A Arbitrum escreveu uma EVM para o compilador AVM que é executado na AVM. Isso significa que as transações assinadas e enviadas em bytecode EVM podem ser compiladas de maneira comprovável como parte de sua execução.
Um exemplo de onde nenhum rollup até agora foi capaz de atingir a paridade completa está nas semântica do gas: O Optimism substituiu alguns opcodes que podem exigir mais gas e a Arbitrum ajustou os custos do gas para refletir o custo da AVM.
Convergindo em Ethereum
A escolha do Optimism pela prova de fraude levou a restrições significativas para seus usuários e apresenta uma barreira para a adoção. Eles agora estão recorrendo a provas de fraude interativas para remover essas limitações.
No entanto, ao contrário da versão atual da Arbitrum, eles não querem projetar uma nova máquina virtual, mas sim tentar encontrar uma representação da EVM que possa ser fornecida de forma eficiente na rede. Fazer isso é uma tentativa de manter 100% de compatibilidade com a EVM e a Ethereum. Eles podem, então, ser capazes de fazer alterações mínimas nas bases de código existentes do cliente Ethereum e executá-los como clientes rollup, herdando a segurança e o trabalho árduo que foi colocado neles. Isso também deve significar que eles alcançam compatibilidade com todos os endpoints JSON-RPC existentes e as ferramentas que dependem deles sem nenhum esforço adicional.
Parece que a Arbitrum também percebeu o valor dessa abordagem e, em sua última postagem no blog, eles esboçaram uma abordagem que os levará nessa direção.
Existem várias maneiras de abordar isso:
- Estenda o conjunto de instruções para incluir a validação de bloco completo e divida quaisquer grandes etapas únicas em sub-tapas menores. O projeto Macula é uma tentativa disso. Seu objetivo é gerar um rastreamento de execução para a execução completa de um bloco Ethereum, a seguir escrever um interpretador para este rastreamento de execução. Assim, permitindo que todas as operações em um bloco sejam divididas ao meio em uma única etapa e, em seguida, executadas na rede. Ele lida com opcodes que podem não ser eficientes para provar, como copiar memória, dividindo-os em sub-instruções cuja soma equivaleria à execução da instrução original.
- Use uma arquitetura existente mais adequada para testar e implementar um interpretador EVM para ela. O projeto Cannon extrai as partes de Geth usadas para verificar um bloco. Em seguida, ele compila essas partes de Geth em um conjunto de instruções mais fácil de provar — como MIPS ou RISC-V. Quando este MIPS-Geth é usado para verificar um bloco, um rastreamento de execução é registrado. É esse rastreamento de execução que duas partes podem dividir para encontrar uma única instrução da qual discordam, que seria então executada em rede usando um interpretador MIPS da rede. Esta também parece ser a direção que a Arbitrum planeja tomar, entretanto, em vez de MIPS, eles pretendem usar o padrão WASM.
Crie uma prova de conhecimento zero da execução de uma única etapa. Em vez de executar a única etapa na rede, o contrato pode verificar se uma prova de execução dessa única etapa é válida. Provar grandes transições de estado, como transações completas, no zk atualmente não é possível em curtos períodos de tempo, no entanto, produzir provas para uma única etapa deve ser viável. Esta abordagem está sendo investigada por pesquisadores do Oasis Labs e da UC Berkeley, mas também foi descrita no artigo da Arbitrum.
Cada um desses métodos fornecerá provas de fraude que não têm limites de impedimento de adoção para os usuários e permitirá que os nós de rollup executem as implementações existentes da Ethereum, herdando sua segurança, capacidade de manutenção e compatibilidade com a rede principal Ethereum.
Mas todos eles exigem o estilo interativo mais complicado de prova de fraude. Portanto, é possível obter as propriedades acima usando uma prova de fraude não interativa?
Bem, na verdade, sim! Existem atualmente duas abordagens conhecidas para isso:
Provas de conhecimento zero (zk) para a transição de estado completa. Ainda há uma série de desafios que precisam ser superados antes que as provas zk para transações completas possam ser produzidas em períodos curtos (tempo de bloqueio). No entanto, se a prova de conhecimento zero está sendo usada como prova de fraude, não precisa ser eficiente para produzir a prova. Atualmente, as provas de fraude fornecem um longo período de desafio (~ 1 semana) para dar tempo aos desafiantes para validar a corrente atual, gerar uma prova de fraude e enviá-la ao Ethereum. Mesmo que a geração de uma prova de fraude leve muito tempo (por exemplo, 1–2 dias), esse período de desafio pode ser estendido com pouco impacto no protocolo geral. Como as provas de fraude interativas, este estilo de prova de fraude pode exceder os limites de L1. Esta abordagem está sendo pesquisada por Sumo, Consensys.
Provas de fraude Bare Metal. O objetivo original do Optimism era executar o código EVM no EVM, mas eles não foram capazes, pois o EVM da rede principal não teria acesso ao estado de rollup. Mas é possível projetar um sistema onde isso seja possível?
Esta é a abordagem adotada pela Oasis Labs. Sua blockchain separa a execução em um caminho rápido e lento. Subcomitês do grupo de consenso executam transações em uma raiz de estado. A raiz do estado resultante é então armazenada em uma rede de base que é validada pelo grupo de consenso completo. Se qualquer membro de um subcomitê discordar da raiz do estado resultante, ele pode solicitar que o grupo de consenso total execute novamente qualquer transição de estado em disputa. Um único validador honesto é necessário em um subcomitê para herdar a segurança da rede de base — a mesma segurança dos rollups otimistas.
Esta abordagem se encaixa perfeitamente no conceito de cliente stateless (sem estado) da Ethereum. Neste paradigma, os nós de consenso armazenam apenas uma raiz de estado da rede. As transações são então acompanhadas pelo estado que acessam e uma testemunha para provar que o estado faz parte da raiz do estado. Os clientes stateless aceitam transações acompanhadas de estado e as executam em sua raiz de estado armazenada para produzir uma nova raiz de estado. Se, em vez de executar transações recebidas em sua raiz de estado armazenada, eles as executassem em uma raiz fornecida, eles seriam capazes de executar novamente transações para outras redes compatíveis com a Ethereum. Essa funcionalidade pode ser adicionada como um novo tipo de transação que se comporta da seguinte maneira:
- Os dados contêm um bloco de transações de rollup com estado e testemunhas acompanhantes, e uma raiz de estado.
- O cliente executa o bloco de transações na raiz do estado para produzir a próxima raiz do estado.
- A tupla de (raiz do estado anterior, hash do bloco de transação, raiz do próximo estado) seria então armazenada em um contrato global, permitindo que qualquer contrato inteligente pesquisasse essas informações e executasse slashes (cortes) etc. com base nos resultados.
Com um novo tipo de transação como este em clientes stateless, a Ethereum seria capaz de reexecutar totalmente as transições de estado para outras rede compatíveis com a Ethereum. Ele poderia oferecer uma prova de fraude não interativa simples para rollups otimistas compatíveis com Ethereum. Esta prova de fraude é executada diretamente no EVM, ao invés de dentro de um ambiente virtualizado hospedado no EVM — uma prova de fraude bare metal.
Resumo
Rollups otimistas exigem provas de fraude para permanecerem seguros. Nós demos uma olhada em dois rollups populares e vimos como a escolha deles à prova de fraude causou limitações para seus usuários e desenvolvedores de contratos (Optimism), ou não manteve compatibilidade completa com a Ethereum (Arbitrum). Ambos os rollups estão se movendo em direção à compatibilidade completa com a Ethereum, sem quaisquer novas limitações, e estão usando provas interativas de fraude para fazer isso. No entanto, as provas de fraude interativas são mais complicadas de construir com segurança, e existem caminhos de pesquisa atuais para encontrar provas de fraude não interativas eficientes que não impõem limitações adicionais e ainda podem permanecer compatíveis com a Ethereum.
Agradecimentos a Patrick McCorry, Dawn Song, Bennet Yee e Nicholas Liochon por seus comentários e contribuições.
Publicado originalmente por Chris Buckland em https://medium.com em 22 de outubro de 2021.
