O que é a optimistic virtual machine (OVM)?

A Optimistic Virtual Machine (OVM) é o ambiente de execução para smart contracts que rodam em um optimistic rollup. Optimistic rollups são soluções de escalabilidade de camada 2 (L2) que ajudam a escalar throughput e latência na Ethereum através de execução off-chain. Rollups são "soluções de escalabilidade híbridas" porque, embora executem transações off-chain, eles publicam os dados necessários para reconstruir o estado da chain na Ethereum.

Optimistic Virtual Machines (OVMs) são cruciais para o funcionamento dos optimistic rollups. OVMs permitem que desenvolvedores rodem aplicações descentralizadas em rollups L2, da mesma forma que fariam na Ethereum, sem diferenças perceptíveis na experiência do usuário.

Este guia explica o que significa uma OVM e como ela difere de outras virtual machines, como a EVM e a zkEVM. Também vamos cobrir a arquitetura básica dos designs de OVM usados em optimistic rollups populares, como Optimism e Arbitrum.

O que é uma optimistic virtual machine?

A Optimistic Virtual Machine (OVM) é uma virtual machine compatível com a EVM para executar computação geral em protocolos de camada 2 (L2).

Uma OVM executa transações "otimisticamente", o que significa que ela não impõe a validade das transações, mas depende da chain L1 para arbitrar disputas sobre a correção das transições de estado. Essas disputas são conhecidas como fraud proofs.

Podemos detalhar essa definição considerando seus componentes principais.

Compatibilidade com a EVM

A Ethereum Virtual Machine (EVM) é um "computador descentralizado e global" que permite a execução de programas na blockchain Ethereum. A EVM é composta por milhares de computadores individuais (nodes) que fornecem recursos computacionais que qualquer pessoa pode acessar para rodar software (por exemplo, smart contracts) na rede Ethereum.

"Compatibilidade com a EVM" significa que um sistema específico foi projetado para trabalhar com programas escritos ou compilados para a EVM. A Optimistic Virtual Machine é compatível com a EVM porque suporta o conjunto de instruções (opcodes) da EVM conforme especificado no Ethereum Yellow Paper. Isso permite que a OVM execute smart contracts da Ethereum sem mudanças significativas no código.

Execução otimista

Virtual machines também podem funcionar como state machines, permitindo que transicionem entre vários estados em resposta a inputs. Em blockchains, o protocolo de consenso governa as transições de estado e define as regras que orientam as funções de transição de estado. Por exemplo, as regras para atualizar o estado da Ethereum são definidas pela EVM e aplicadas pelo consenso proof-of-work (PoW) da rede.

A OVM depende de um modelo de "execução otimista"—o protocolo não verifica se uma transição de estado é válida ou não antes de aceitá-la. Isso aumenta a eficiência, já que a necessidade de chegar a um consenso sobre a validade das atualizações de estado torna o processamento mais lento em blockchains de camada 1 (L1), como a Ethereum. Ao assumir que todas as transações são válidas por padrão, a OVM consegue progredir muito mais rápido.

No entanto, para garantir segurança, os designs de OVM permitem que qualquer pessoa conteste a validade das transições de estado—com a chain L1 servindo como juiz. Esse processo depende de "fraud proofs", que explicamos em uma seção posterior.

Computação geral na L2

Se uma virtual machine (VM) suporta computação geral, ela pode executar a maioria das tarefas, dadas as instruções corretas e recursos suficientes. Como a OVM pode executar lógica arbitrária (ou seja, é Turing-completa), desenvolvedores podem aplicá-la para rodar diferentes tipos de smart contracts.

Além disso, a OVM roda em uma blockchain de camada 2, um protocolo que opera sobre uma blockchain base (Ethereum, neste caso). Protocolos L2 são uma extensão da chain principal e são gerenciados por smart contracts na blockchain L1. Mais importante ainda, a chain L1 garante a correção das transições de estado na OVM L2 e a disponibilidade dos dados por trás da execução.

Em que a OVM difere da EVM?

A OVM é semelhante à EVM já que ambas servem para executar computação. No entanto, a OVM funciona apenas como uma interface para a EVM.

A EVM é a virtual machine usada para processar transações na L1, mas a VM da L1 é lenta porque cada computação precisa ser reexecutada por todos os nodes da rede antes de ser aceita. Também é cara, já que há muitas transações a processar, e os nodes só conseguem processar um pequeno número de transações por vez.

A OVM (rodando na L2) permite que usuários utilizem a EVM da L1 sem atualizar diretamente o estado desta última. Em vez disso, a OVM executa transações "off-chain" (ou seja, fora da chain L1), mas usa os dados off-chain para garantir o que acontecerá na camada 1.

Aqui vai um exemplo:

Digamos que Alice tenha 2 ETH no optimistic rollup e envie 1 ETH para Bob.

Um aggregator submete a transação ao contrato do rollup na camada um que, se não for contestada, é incluída como parte de uma transação minerada na Ethereum.

Dessa forma, garantimos que uma transação pagando 1 ETH a Bob no rollup passará pelo consenso na chain principal da Ethereum e será finalizada como parte do estado desta última.

Essa garantia decorre dos seguintes fatos:

1. A OVM usa as regras da EVM para orientar a execução das transações. Se o optimistic rollup executar uma transação corretamente, ela será aceita na L1.
2. O aggregator publica os dados da transação na L1, permitindo que qualquer pessoa conteste a transação caso ela tenha sido executada incorretamente.

Bob e Alice podem decidir sacar seus fundos do rollup ou continuar transacionando.

De qualquer forma, eles terão se beneficiado da EVM sem executar nenhuma transação na L1.

Outras diferenças entre a OVM e a EVM incluem:

• Imposição de validade
• Finalidade instantânea
• Velocidade de transação

Imposição de validade

A OVM não impõe a validade de uma função de transição de estado. Por exemplo, um operador malicioso pode transferir o saldo de Alice para si mesmo e submeter a transação à L1. Se a transação não for contestada, a OVM simplesmente a aceita.

Por outro lado, toda transição de estado na EVM deve seguir as regras de consenso da rede antes de ser aceita.

Por exemplo, o cenário descrito acima não seguiria essas regras, já que a chave de assinatura do remetente não corresponderia à sua chave pública (o que é um critério para transações válidas).

Finalidade instantânea

A EVM garante finalidade instantânea. Isso significa que uma transição de estado é permanente assim que aceita na rede e não pode ser alterada ou revertida.

A OVM não pode garantir finalidade instantânea porque não impõe a validade das transações (finalizar transações inválidas corromperia a chain).

Em vez disso, atualizações no estado da OVM só são finais se, e somente se, forem aceitas na chain L1.

Velocidade de transação

Como explicado, a OVM tem uma capacidade de processamento maior em comparação com a EVM devido a diferenças de design. Um único node (o sequencer) pode escrever na chain sem precisar esperar aprovação de outros nodes.

Isso é diferente da EVM, onde os nodes não podem escrever na chain a menos que uma transação tenha sido verificada e aceita por outros nodes peer-to-peer. Isso reduz o número de transações que podem ser processadas na EVM.

Em que a OVM difere das zkEVMs?

Como explicado, a OVM foca principalmente na execução e depende da EVM da camada um para impor regras sobre atualizações de estado. Assim, transações realizadas na OVM são simplesmente submetidas à L1 sem nenhuma prova de sua validade. Isso aumenta a escalabilidade, mas aumenta o risco de que transações inválidas sejam finalizadas na L1, especialmente se ninguém as contestar.

Uma zkEVM (Zero-Knowledge Ethereum Virtual Machine) resolve esse problema gerando provas criptográficas que atestam a correção da computação off-chain. Isso dá à L1 fortes garantias da validade das atualizações de estado.

A zkEVM é compatível com a EVM, assim como a OVM, e pode rodar smart contracts. No entanto, ela difere da OVM de várias formas:

1. Finalidade quase instantânea
2. Prova objetiva
3. Complexidade

Vamos explorar isso um pouco mais.

1. Finalidade quase instantânea

Transições de estado são finalizadas imediatamente porque a validity proof é verificada on-chain. Isso elimina a necessidade de atrasos na finalização de transações L2 na L1.

2. Prova objetiva

​Zero-Knowledge proofs são usadas para garantir a correção da computação da VM. Isso elimina a necessidade de provas subjetivas (ou seja, esperar o challenge period passar) ou fraud proofs para determinar a validade das transações.

3. Complexidade​

Uma zkEVM é mais difícil de implementar do que a OVM porque gerar validity proofs para múltiplas etapas de computação é caro. As OVMs não são sobrecarregadas pela necessidade de verificar a computação off-chain antecipadamente e só usam fraud proofs quando necessário. Isso as torna mais fáceis de implementar do que as zkEVMs.

Como funciona a optimistic virtual machine?

Assim como a EVM, a Optimistic Virtual Machine funciona como um ambiente de runtime para executar computação. No entanto, a OVM também precisa lidar com a prova de computação, já que optimistic rollups dependem de fraud proofs para detectar transições de estado inválidas.

Execução

A OVM fornece a funcionalidade para implantar e executar contratos, monitorar saldos e outras tarefas que uma plataforma de smart contract precisa realizar. A OVM recebe input na forma de transações enviadas por um node na chain L2. Esses inputs fazem com que a OVM mude seu estado e produza outputs, como emitir eventos ou processar pagamentos.

Outros detalhes sobre execução na OVM incluem gas, bytecode e transações.

Gas

"Gas" refere-se a recursos computacionais para executar programas na EVM. Assim como a EVM, a OVM usa o conceito de gas para limitar as etapas de execução de cada transação.

Os remetentes de transações precisam definir um limite de gas para especificar quanto gas estão dispostos a gastar em uma transação. Isso impede que transações maliciosas rodem infinitamente e consumam todos os recursos da rede. As taxas de gas também compensam os nodes da L2 por fornecerem recursos computacionais para executar transações.

Bytecode

Bytecode refere-se a instruções de baixo nível que a Optimistic Virtual Machine (OVM) consegue interpretar para executar funções. Smart contracts escritos em linguagens de alto nível compatíveis com a EVM, como Solidity, precisam ser compilados para bytecode antes da implantação. O próprio bytecode é executado como uma série de opcodes que realizam operações sobre os inputs da transação.

A OVM é compatível com a EVM no nível de bytecode, exceto por algumas diferenças. Isso significa que você pode implantar bytecode EVM compilado na OVM com mudanças mínimas.

Transações

Uma transação na OVM funciona de forma parecida com a EVM. Uma transação pode ser iniciada por uma externally owned account (EOA) ou uma contract account. Transações de EOAs podem ser qualquer uma das seguintes:

• Transferência de ativos (por exemplo, Alice envia 5 ETH para Bob)
• Criação de contrato (por exemplo, Bob envia uma transação para a rede com o bytecode compilado como data payload)
• Execução de smart contract (por exemplo, Alice paga por 5 tokens UNI)

Da mesma forma, contract accounts podem iniciar transações (chamadas "message calls") com uma EOA como destinatária ou outro contrato. Um contrato também pode criar um novo contrato na OVM usando uma transação de criação de contrato.

Fraud proving

Como mencionado, a OVM depende de um esquema de fraud proving para detectar e reverter transições de estado inválidas. Para que fraud proofs funcionem, o estado da OVM é hasheado como uma Merkle tree, com a raiz armazenada no contrato do rollup na camada 1. Merkle trees e roots permitem que nodes façam afirmações sobre diferentes partes do estado da OVM.

Por exemplo, um operador de rollup—após iniciar uma transição de estado executando transações—deve publicar uma nova state root ao submeter blocos do rollup. A state root equivale a dizer: "Esta sequência de transações, quando executada, transiciona a VM de um estado antigo (referenciado na old state root) para um novo estado (referenciado na new state root)."

No entanto, o contrato do rollup não tem como saber se a transição de estado foi válida ou não (o sistema é "otimista"). Para impedir que nodes executem atualizações de estado inválidas na OVM, rollups usam fraud proofs.

O que é uma fraud proof?

Uma fraud proof é simplesmente uma alegação de que uma transação, se executada corretamente, leva a uma state root diferente daquela calculada pelo block producer. Isso é possível porque qualquer pessoa que monitore a chain L2 pode baixar as transações submetidas ao operador do rollup, reexecutá-las usando sua própria cópia do estado do rollup e calcular a state root independentemente.

Digamos que o saldo de Alice fosse 5 ETH no estado antigo da OVM (criptograficamente representado pelo hash raiz: "0x67989898…"). Se ela transferir 4 ETH, o rollup entra em um novo estado (criptograficamente representado pelo hash raiz: "0x7879056…").

Se a transação fosse inválida (por exemplo, talvez a assinatura estivesse incorreta), ela deveria reverter, o que deixaria o estado da VM inalterado.

No entanto, imaginemos que um operador malicioso tenha aplicado a atualização inválida (talvez transferindo o ETH de Alice para sua própria carteira); ele pode publicar a nova, embora incorreta, state root para finalizar a transação.

Assim, cabe ao challenger publicar a state root correta e declarar o bloco do rollup inválido. É o equivalente a dizer: "Esta transação, se executada corretamente, leva a uma state root diferente."

Quais são as duas formas de provar fraude em rollups baseados em OVM?

Geralmente, há duas abordagens para provar fraude em rollups baseados em OVM: reexecução de transações e o protocolo de bisseção.

1. Reexecução de transações

Aqui, a OVM é "containerizada" em um smart contract rodando na chain L1. O smart contract atua como um ambiente sandboxed que permite reproduzir uma transação da OVM dentro da EVM para obter a state root correta. Isso é feito fornecendo outros inputs relacionados ao contexto, como state e storage, além da transação contestada.

No exemplo do operador malicioso descrito anteriormente, a transação reverteria—mantendo a state root como está. A state root calculada inevitavelmente corresponderia à state root do challenger, expondo o operador malicioso e impedindo a transição de estado inválida.

2. Protocolo de bisseção

O protocolo de bisseção é uma abordagem diferente para fraud proving que tenta minimizar o trabalho que a chain L1 precisa fazer no fraud proving. Ele é chamado de protocolo de bisseção devido ao seu design particular:

1. O processo começa com um challenger contestando uma assertion (blocos de rollup são chamados de "assertions" já que são contestáveis).
2. O asserter então divide a assertion contestada em duas assertions iguais, com o challenger escolhendo qual parte deseja contestar.
3. Depois que o challenger escolhe outra assertion para contestar, o asserter divide novamente a assertion.
4. Esse processo continua até que ambas as partes estejam disputando o resultado de uma única etapa de computação realizada na OVM.
5. O asserter então precisa fornecer uma one-step proof mostrando que a etapa de execução contestada está correta.
6. Se o asserter não conseguir submeter a proof, ou se o contrato L1 considerar a proof inválida, ele perde o challenge.

Diferente da reexecução de transações, a bisseção elimina a necessidade de reexecutar um bloco/transação inteiro on-chain, o que é caro. Também torna desnecessário publicar state roots para cada transação, o que é necessário ao reexecutar transações para provar fraude.

O protocolo de bisseção é usado no Arbitrum, com outros optimistic rollups, como Optimism, planejando usar um protocolo de bisseção para fraud proving.

Considerações finais

A Optimistic Virtual Machine é fundamental para escalar a Ethereum ao mover computação off-chain para rollups. Com a OVM, desenvolvedores podem implantar smart contracts em chains L2 sem enfrentar as altas taxas de gas e os tempos de processamento lentos que afetam a Ethereum. Além disso, o fraud proving significa que a OVM pode oferecer as mesmas garantias de segurança que a EVM na rede principal da Ethereum.

A Alchemy suporta a construção em optimistic rollups que utilizam a Optimistic Virtual Machine, incluindo Optimism e Arbitrum.

Cadastre-se para uma conta gratuita da Alchemy e comece a construir aplicações ultrarrápidas, escaláveis e compatíveis com a EVM hoje mesmo.