Yellow.com

A máquina virtual do Ethereum (ETH), criada em 2015, foi pensada para executar contratos inteligentes — não para gerar provas criptográficas. Já as provas de conhecimento zero nasceram para verificar computações de forma barata e privada, sem qualquer noção do que é um opcode.

Por muito tempo, os dois mundos pareceram incompatíveis.

Até que engenheiros descobriram como uni-los. O resultado é uma das infraestruturas tecnológicas mais complexas de todo o mercado cripto.

ZkEVM — sigla para zero-knowledge Ethereum Virtual Machine — é a tentativa de executar contratos inteligentes compatíveis com Ethereum e, em seguida, provar criptograficamente que eles foram executados corretamente, usando provas de conhecimento zero, sem obrigar desenvolvedores a reescrever uma única linha de código.

Na teoria, soa simples. Na prática, significou resolver problemas que travaram a indústria inteira por mais de cinco anos.

Resumindo

Um ZkEVM executa contratos inteligentes compatíveis com Ethereum e gera uma prova de conhecimento zero de que essa execução foi correta, permitindo liquidação rápida e barata de transações de volta na rede principal do Ethereum.

Quanto mais difícil é construir um ZkEVM, maior tende a ser sua compatibilidade com as ferramentas atuais do Ethereum; esse trade-off está no centro de todas as decisões de design nesse segmento.

Usuários mantêm as garantias de segurança do Ethereum sem pagar o gás da rede principal, enquanto desenvolvedores podem implantar contratos em Solidity já existentes com pouca ou nenhuma alteração.

O que as provas de conhecimento zero realmente fazem

Antes de falar da EVM, é preciso entender claramente o que é — e o que não é — uma prova de conhecimento zero. Uma ZK proof é um método criptográfico que permite que uma parte, o provador, convença outra parte, o verificador, de que uma afirmação é verdadeira, sem revelar os dados que a tornam verdadeira.

O exemplo clássico é provar que você sabe uma senha sem jamais transmiti-la. Em blockchains, a afirmação é quase sempre computacional: “Eu executei este programa com esta entrada e obtive esta saída, de forma correta.”

No contexto de ZkEVM, o verificador costuma ser um contrato inteligente no Ethereum, na Camada 1, que valida a prova em milissegundos, sem precisar reexecutar cada transação.

As provas de conhecimento zero permitem que uma rede de Camada 2 agrupe milhares de transações, gere uma única prova compacta de que todas são válidas e publique apenas essa prova no Ethereum, reduzindo drasticamente o custo por usuário.

Dois sistemas de prova dominam o cenário atual de ZkEVM. Os SNARKs (Succinct Non-interactive ARguments of Knowledge) produzem provas muito pequenas, verificadas rapidamente, mas exigem uma cerimônia de configuração confiável (trusted setup). Os STARKs (Scalable Transparent ARguments of Knowledge) dispensam esse setup e são resistentes a ataques quânticos, porém geram provas maiores. A maioria das equipes de ZkEVM hoje converge para sistemas baseados em SNARKs, porque o custo de verificação na rede principal do Ethereum é um gargalo rígido.

Por que é tão difícil provar a EVM

A Ethereum Virtual Machine é um ambiente de execução baseado em pilha, com mais de 140 opcodes, um sistema de cobrança de gás, memória complexa e uma infinidade de casos extremos acumulados em quase uma década de uso real. Cada opcode, do simples ADD até precompilados criptográficos como ECRECOVER, precisa ser representado como uma restrição aritmética para que um sistema de prova ZK consiga “raciocinar” sobre ele.

O problema é que sistemas de prova ZK falam uma linguagem matemática muito restrita. Eles operam nativamente sobre corpos finitos e equações polinomiais. A EVM foi projetada sem levar nada disso em conta. OpCodes como KECCAK256 (a função de hash do Ethereum) são particularmente hostis a circuitos ZK, pois envolvem operações bit a bit que se traduzem em conjuntos enormes e caros de restrições.

Esse descompasso originou o chamado “problema de incompatibilidade com a EVM”. Era possível construir um rollup ZK rápido e barato, mas que só rodava programas feitos sob medida para ambientes “ZK-friendly”. Ou tentar suportar a EVM completa, ao custo de uma geração de provas tão lenta e cara que anulava o benefício. O desafio de engenharia do ZkEVM é justamente reduzir esse trade-off.

Gerar uma prova ZK para um único hash KECCAK256 pode exigir milhões de restrições aritméticas. Um bloco típico do Ethereum contém milhares de hashes, o que explica por que a geração de provas de ZkEVM levava horas nas primeiras implementações e ainda hoje demanda hardware especializado.

Os quatro tipos de ZkEVM e o que eles significam

Nem todo ZkEVM é igual. Em 2022, o pesquisador do Ethereum Vitalik Buterin propôs uma taxonomia hoje amplamente adotada, que divide as implementações em quatro tipos, de acordo com o grau de compatibilidade com o stack atual do Ethereum. Entender esses tipos é a forma mais rápida de avaliar qualquer projeto de ZkEVM.

Tipo 1 é totalmente equivalente ao Ethereum. Prova a transição de estado exata da rede, a estrutura de blocos, funções de hash, tudo, sem modificação. Clientes Ethereum existentes podem sincronizar nativamente, e todo ferramental funciona sem ajustes. O preço é uma geração de provas extremamente lenta e cara. Hoje, não há ZkEVM de produção rodando como Tipo 1, embora algumas equipes busquem esse objetivo.

Tipo 2 é equivalente à EVM. Permite alterações em estruturas internas — por exemplo, trocar o KECCAK por um hash mais amigável a ZK na state trie — mas preserva compatibilidade total com o bytecode da EVM. Contratos se comportam de forma idêntica. O desenvolvedor não percebe diferença. A geração de provas é mais rápida que no Tipo 1, porém ainda pesada. Scroll e as primeiras versões do Polygon zkEVM se enquadram aqui.

Tipo 3 adiciona modificações que quebram um pequeno conjunto de funcionalidades de borda, como certos precompilados. Quase todos os contratos existentes continuam a funcionar. A geração de provas fica significativamente mais barata. A maior parte dos ZkEVMs lançados comercialmente entre 2023 e 2024 operou entre os Tipos 2 e 3 em suas versões iniciais.

Tipo 4 compila código-fonte em Solidity ou Vyper para uma máquina virtual personalizada, otimizada para ZK, em vez de provar diretamente o bytecode da EVM. É a opção mais rápida e barata, mas pode introduzir diferenças sutis de comportamento e inviabilizar alguns truques de baixo nível da EVM. O zkSync Era segue essa abordagem, com um compilador próprio baseado em LLVM.

Essa taxonomia é crucial para quem constrói aplicações. Um projeto que vai migrar um protocolo DeFi já amplamente testado na rede principal tende a preferir ZkEVMs Tipo 2 ou 3, para assegurar paridade de comportamento. Já um protocolo novo, criado do zero, pode aceitar um Tipo 4 em troca de custos menores de prova e finalização mais rápida.

Como um ZkEVM processa uma transação, passo a passo

Seguir uma única transação de ponta a ponta ajuda a visualizar a arquitetura. Quando o usuário envia uma transação a uma rede ZkEVM, a sequência é, em linhas gerais, a seguinte.

Primeiro, a transação chega ao sequencer, o nó responsável por ordenar e agrupar transações em lotes. O sequencer executa essas transações, atualiza o estado da Camada 2 e fornece ao usuário uma “confirmação suave” quase instantânea. Nesse momento, a carteira já mostra o novo saldo, mas a transação ainda não está criptograficamente finalizada no Ethereum.

Em seguida, o lote de transações é repassado ao prover, um software (ou hardware) especializado que executa o algoritmo de prova ZK. O prover pega o estado pré-execução, todas as transações e o estado pós-execução, e gera uma prova de validade garantindo que a transição de estado foi computada corretamente. Essa etapa é intensiva em recursos computacionais e pode levar de alguns segundos a alguns minutos, dependendo do sistema.

Depois, a prova e uma quantidade reduzida de dados comprimidos das transações são enviadas a um contrato inteligente no Ethereum, o verifier contract.

Esse contrato verifica a prova em uma única chamada on-chain, com um custo de gás praticamente fixo, independentemente de quantas transações foram incluídas no lote. Uma vez validada, a nova raiz de estado da Camada 2 é finalizada no Ethereum e passa a desfrutar do mesmo nível de segurança de qualquer transação da rede principal.

ZkEVM modular e interoperabilidade entre cadeias

O desenho original de ZkEVM assumia um único plano de liquidação: o Ethereum. Tudo era provado e liquidado na rede principal. Uma arquitetura mais recente, o ZkEVM modular, separa camada de execução, camada de prova e camada de liquidação, permitindo combiná-las de forma independente.

É nesse contexto que surgem projetos como o Prom.

O Prom se apresenta como um ZkEVM modular de Camada 2 focado em interoperabilidade entre cadeias EVM e não-EVM. Em vez de provar execuções e liquidar exclusivamente no Ethereum, ele submete provas simultaneamente a múltiplas redes, criando uma ponte matemática entre ecossistemas que até então não tinham conexão trustless.

A abordagem modular é relevante porque rompe com a suposição de que apenas o Ethereum pode servir como camada de liquidação.

No fim, uma prova ZkEVM é apenas matemática. Se as Cadeias A e B tiverem contratos verificadores capazes de checar essa mesma prova, um único atestado pode finalizar uma transição de estado em ambas, ao mesmo tempo. É assim que provas ZK deixam de ser apenas uma solução de escala e passam a funcionar como um primitivo universal de interoperabilidade.

Arquiteturas de ZkEVM modular desacoplam execução e liquidação, o que permite verificar a mesma prova de validade no Ethereum, em uma blockchain não-EVM ou em ambas, criando uma fonte compartilhada de “verdade criptográfica” entre ecossistemas que, de outra forma, permaneceriam isolados.

ZkEVM versus optimistic rollups, frente a frente

A comparação entre ZkEVM e optimistic rollups aparece o tempo todo — e com razão: ambos atacam o mesmo problema com filosofias opostas.

Os optimistic rollups partem do princípio de que as transações são válidas por padrão e só as verificam se alguém apresentar uma contestação de fraude dentro de uma janela de disputa (tipicamente sete dias). Isso torna a operação mais barata e a implementação mais simples, mas implica que saques para a camada 1 do Ethereum levem uma semana, a menos que o usuário recorra a uma ponte de liquidez. Arbitrum e Optimism são hoje as principais redes de optimistic rollups.

Os rollups ZkEVM fazem o oposto: não assumem nada. Cada lote de transações é considerado inválido até que uma prova criptográfica demonstre o contrário. O custo computacional do lado do “prover” é maior, mas os saques conseguem ser finalizados na mainnet do Ethereum em horas, em vez de dias, e o sistema não depende de “watchers” honestos para flagrar fraudes.

Na prática, para o usuário final, as diferenças se resumem a:

Velocidade de saque: ZkEVM leva vantagem clara. A finalização via prova ocorre em horas, contra cerca de sete dias para um saque nativo em optimistic rollups.
Custo de transação: hoje, os optimistic rollups ainda tendem a ser mais baratos em muitos casos, porque a geração de provas ZK adiciona custo. Mas essa diferença vem caindo com a evolução de hardware e algoritmos de prova.
Modelo de segurança: ZkEVM oferece garantias de validade baseadas em criptografia. Optimistic rollups oferecem segurança econômica via provas de fraude — robusta, mas não equivalente a uma prova matemática de correção.
Compatibilidade com EVM: ZkEVMs modernos (Tipos 2 e 3) fecharam grande parte da lacuna e já suportam praticamente todo o ferramental existente do Ethereum, eliminando o que antes era uma vantagem relevante dos optimistic rollups.
Risco de disponibilidade (liveness): sistemas ZkEVM podem parar se o provador ficar indisponível. Já os optimistic rollups continuam processando blocos enquanto o sequencer estiver online.

Nenhuma das abordagens é “melhor” em todos os cenários. Aplicações de alto volume, extremamente sensíveis a custo e que toleram uma janela de saque mais longa tendem a preferir optimistic rollups. Projetos que precisam de finalização rápida, liquidação cross-chain ou garantias matemáticas de correção se inclinam para ZkEVM.

Quem de fato se beneficia do ZkEVM hoje

ZkEVM não é promessa de futuro distante. Várias redes já estão em operação, com valor travado relevante e usuários pagando taxas diariamente. Ainda assim, vale entender quem captura mais valor em cada camada da pilha.

Protocolos DeFi que migram da camada 1 do Ethereum se beneficiam de semântica de execução praticamente idêntica (Tipos 2/3) e de uma queda drástica nos custos de gas. Um protocolo que expulsava o varejo com taxas de US$ 30 por swap na mainnet pode oferecer transações a frações de centavo em um ZkEVM, sem reescrever seus smart contracts.

Bridges e aplicações cross-chain colhem ganhos com arquiteturas ZkEVM modulares, que publicam provas em múltiplas cadeias. Em vez de confiar em uma bridge controlada por multisig — historicamente a categoria mais vulnerável a hacks no cripto — o usuário passa a depender de uma prova matemática verificada on-chain.

Empresas e instituições que constroem aplicações permissionadas ou semipermissionadas ganham um ambiente de execução testado, com auditabilidade criptográfica. Cada transição de estado é comprovadamente correta, algo crítico para requisitos de compliance, auditoria e contabilidade.

Desenvolvedores que começam projetos hoje precisam entender o trade-off entre Tipo 4 e Tipo 2 antes de escolher uma rede. Se o plano é escrever Solidity do zero priorizando máxima velocidade de prova e taxas mínimas, uma rede Tipo 4 pode ser a melhor opção. Se a missão é migrar um protocolo existente, sem margem para mudanças sutis de comportamento, uma rede Tipo 2 ou Tipo 3 tende a ser a escolha mais segura.

Para o usuário comum, ZkEVM se apresenta essencialmente como uma chain barata, rápida e compatível com Ethereum: a mesma wallet funciona, os mesmos tokens atravessam pontes e o resto é abstraído. Toda a engrenagem criptográfica fica invisível — exatamente como boa infraestrutura deve ser.

Conclusão

ZkEVM é, hoje, um dos problemas de convergência mais complexos da criptografia aplicada: pegar uma máquina virtual desenhada sem estrutura matemática e obrigá-la a “falar” a linguagem de provas de conhecimento zero.

As equipes que chegaram a soluções práticas passaram anos lidando com incompatibilidades de funções de hash, explosão de constraints e hardware de prova que ainda não existia quando os artigos acadêmicos foram publicados.

O setor segue avançando rápido. Os tempos de geração de prova continuam caindo. Redes descentralizadas de provers começam a ganhar tração. A equivalência total de Tipo 1 com o Ethereum permanece como alvo, e vários times se aproximam dessa linha de chegada.

Para quem constrói ou investe no ecossistema do Ethereum, entender como ZkEVM funciona na prática — para além dos slogans de marketing — é a base sobre a qual todas as decisões estratégicas serão tomadas.

Leia a seguir: A ofensiva de US$ 500 bi da Nvidia em IA coloca tokens de computação cripto no radar

Por que o ZkEVM executa código do Ethereum, mas o comprova com prova de conhecimento zero