Yellow.com

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

Durante anos, os dois mundos pareceram fundamentalmente incompatíveis.

Até que engenheiros descobriram como uni-los — e o resultado é hoje uma das peças de infraestrutura mais sofisticadas de toda a indústria cripto.

A ZkEVM — sigla para “zero-knowledge Ethereum Virtual Machine” — é a tentativa de executar contratos inteligentes compatíveis com Ethereum e, em seguida, provar criptograficamente que tudo foi processado de forma correta, usando provas ZK, sem exigir que os desenvolvedores reescrevam uma linha de código.

Na teoria soa simples. Na prática, significou resolver problemas que travaram a indústria por mais de meia década.

TL;DR

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

Quanto mais difícil é construir uma ZkEVM, maior tende a ser sua compatibilidade com o ecossistema existente do Ethereum; esse trade-off está no centro de todas as decisões de design.

Usuários aproveitam as garantias de segurança do Ethereum sem pagar o gás da mainnet, e desenvolvedores conseguem implantar contratos em Solidity já existentes com pouca ou nenhuma alteração.

O que as provas de conhecimento zero realmente fazem

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

O exemplo clássico é provar que você conhece uma senha sem nunca enviar a senha em si. Em blockchains, a afirmação provada é quase sempre computacional: “rodei este programa com esta entrada, obtive esta saída, e fiz tudo corretamente”.

No nosso contexto, quem verifica é um contrato inteligente no Ethereum, na Camada 1, que checa a prova em milissegundos — sem reexecutar cada transação.

Provas de conhecimento zero permitem a uma rede de Camada 2 agrupar milhares de transações, gerar uma única prova compacta de que todas são válidas e publicar apenas essa prova no Ethereum, reduzindo de forma dramática o custo por usuário.

Dois sistemas de prova dominam hoje o cenário de ZkEVM. Os SNARKs (Succinct Non-interactive ARguments of Knowledge) produzem provas minúsculas, de verificação rápida, mas exigem uma cerimônia de setup confiável. Já os STARKs (Scalable Transparent ARguments of Knowledge) dispensam o setup confiável e são resistentes a ataques quânticos, porém geram provas maiores. A maioria das equipes de ZkEVM, por enquanto, converge para modelos baseados em SNARKs, porque o custo de verificação na mainnet do Ethereum é um limite 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 contabilidade de gás, layout de memória complexo e uma infinidade de casos extremos acumulados em quase uma década de uso em produção. Cada opcode — de um simples ADD a pré-compilações criptográficas 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 provas ZK “falam” uma linguagem matemática extremamente restrita. Eles operam nativamente sobre corpos finitos e equações polinomiais. A EVM foi desenhada ignorando completamente essas limitações. Instruções como KECCAK256 (a função de hash do Ethereum) são quase o pior cenário possível para circuitos ZK, porque envolvem operações bit a bit que se traduzem em conjuntos gigantescos e caros de restrições.

Essa incompatibilidade criou o chamado “problema de incompatibilidade com a EVM”. Era possível construir um rollup ZK rápido e barato, desde que ele rodasse apenas programas escritos sob medida para um ambiente “ZK-friendly”. Ou tentar suportar a EVM completa — ao custo de um processo de prova tão caro e lento que mataria a proposta de valor. O desafio de engenharia por trás da ZkEVM é justamente colapsar esse dilema.

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 — por isso, as primeiras implementações de ZkEVM levavam horas para gerar provas e ainda hoje dependem de hardware especializado.

Os quatro tipos de ZkEVM — e o que eles significam

Nem todas as ZkEVMs são iguais. Em 2022, o pesquisador do Ethereum Vitalik Buterin propôs uma taxonomia hoje amplamente usada, que divide as implementações em quatro tipos, conforme o grau de compatibilidade com a pilha atual do Ethereum. Entender esses tipos é a maneira mais rápida de avaliar qualquer projeto de ZkEVM.

Tipo 1 é totalmente equivalente ao Ethereum. Ele prova a transição de estado do Ethereum exatamente como ela é — estrutura de blocos, funções de hash, tudo — sem qualquer modificação. Isso permite que clientes atuais do Ethereum sincronizem o sistema nativamente, e todas as ferramentas funcionem imediatamente. O preço é um processo de prova tão lento e caro que ainda não existe ZkEVM de produção operando nesse nível, embora algumas equipes estejam perseguindo esse objetivo.

Tipo 2 é equivalente à EVM. Muda algumas estruturas internas — trocando, por exemplo, KECCAK por um hash mais amigável a ZK na state trie — mas preserva total compatibilidade com o bytecode da EVM. Os contratos inteligentes se comportam de forma idêntica. Do ponto de vista do desenvolvedor, nada muda. A geração de provas é mais rápida que no Tipo 1, mas ainda pesada. Scroll e as primeiras versões da Polygon zkEVM se enquadram aqui.

Tipo 3 introduz modificações adicionais que quebram um pequeno conjunto de funcionalidades de borda, como certas pré-compilações. Quase todos os contratos existentes continuam a funcionar. As provas ficam significativamente mais baratas de gerar. A maior parte das ZkEVMs lançadas comercialmente entre 2023 e 2024 operou, na prática, em um espectro entre Tipo 2 e Tipo 3 nas versões iniciais.

Tipo 4 compila código-fonte em Solidity ou Vyper para uma máquina virtual própria, desenhada para ser amigável a 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 certos “truques” de baixo nível da EVM deixam de ser possíveis. A zkSync Era adota esse modelo, com um compilador próprio baseado em LLVM.

Essa taxonomia é crucial para quem constrói. Um projeto que migra um protocolo DeFi consolidado da mainnet do Ethereum tende a preferir Tipo 2 ou Tipo 3, em busca de paridade de comportamento. Já equipes que começam do zero podem aceitar um Tipo 4 em troca de custos de prova menores e finalização mais rápida.

Como uma ZkEVM processa uma transação na prática

Seguir o ciclo completo de uma única transação ajuda a tornar a arquitetura concreta. Quando um 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 uma “confirmação suave” imediata ao usuário. Nesse momento, a carteira já mostra o novo saldo, mas a transação ainda não foi finalizada criptograficamente no Ethereum.

Em seguida, o lote de transações é entregue ao prover, um software (ou hardware) especializado que roda o algoritmo de prova ZK. O prover pega o estado antes da execução, todas as transações e o estado final, e gera uma prova de validade confirmando que a transição de estado foi computada de forma correta. Essa etapa é intensiva em computação e pode levar de alguns segundos a vários minutos, dependendo do sistema.

Depois, a prova e uma pequena fração dos dados de transação, já comprimidos, são enviados a um contrato inteligente no Ethereum chamado verifier contract.

Esse contrato verifica a prova em uma única chamada on-chain, com um custo de gás praticamente fixo, independentemente do número de transações no lote. Uma vez verificada, a raiz de estado da Camada 2 é finalizada no Ethereum e passa a ser tão segura quanto qualquer transação na mainnet.

ZkEVM modular e interoperabilidade entre cadeias

O desenho original de ZkEVM assumia uma única camada de liquidação: o Ethereum. Tudo era provado e liquidado exclusivamente na mainnet. Uma arquitetura mais recente — a ZkEVM modular — separa camada de execução, camada de prova e camada de liquidação, permitindo que cada uma seja combinada de forma independente.

É nesse contexto que entram projetos como o Prom.

O Prom se define como uma ZkEVM modular de Camada 2 que habilita interoperabilidade tanto entre cadeias EVM quanto não-EVM. Em vez de provar a execução e liquidar apenas no Ethereum, ele submete provas simultaneamente a múltiplas redes, criando uma ponte matemática entre ecossistemas que antes não tinham conexão verdadeiramente trustless.

A abordagem modular importa porque rompe a suposição de que o Ethereum é a única superfície legítima de liquidação.

No fim, uma prova ZkEVM é “apenas” matemática. Se a Cadeia A e a Cadeia B têm contratos verificadores capazes de checar essa matemática, uma única prova pode finalizar uma mesma transição de estado nas duas redes, em paralelo. É assim que provas ZK deixam de ser apenas uma solução de escalabilidade e passam a funcionar como um primitivo universal de interoperabilidade.

Arquiteturas de ZkEVM modular desacoplam execução de liquidação, o que permite que a mesma prova de validade seja verificada no Ethereum, em uma cadeia não-EVM, ou em ambas — criando uma fonte compartilhada de verdade criptográfica entre ecossistemas que, de outra forma, permaneceriam incompatíveis.

ZkEVM versus Optimistic Rollups, lado a lado

A comparação entre ZkEVM e optimistic rollups surge o tempo todo — e com razão. Ambos atacam o mesmo problema, mas com filosofias quase opostas.

Os optimistic rollups partem do princípio de que as transações são válidas por padrão e só são verificadas se alguém apresentar um “fraud proof” dentro de uma janela de disputa (tipicamente sete dias). Isso torna a operação mais barata e a engenharia mais simples, mas implica que os levantamentos para a mainnet do Ethereum demoram cerca de uma semana, a não ser que o utilizador recorra a uma “liquidity bridge”. Arbitrum e Optimism são hoje as redes dominantes neste modelo.

Os ZkEVM rollups fazem o inverso: não assumem nada. Cada lote de transações é considerado inválido até que a prova criptográfica diga o contrário. O custo computacional do lado do “prover” é bem mais elevado, mas os levantamentos podem ser finalizados na Ethereum em horas, em vez de dias, e o sistema não depende de “watchers” honestos para detetar fraude.

Na prática, para o utilizador, as diferenças principais são:

Velocidade de levantamento: clara vantagem para ZkEVM. A finalização baseada em prova leva horas, contra sete dias para levantamentos nativos nos optimistic rollups.
Custo de transação: hoje, muitos optimistic rollups ainda são mais baratos, porque gerar provas zero-knowledge tem um custo adicional. Mas essa diferença está a encolher à medida que o hardware e os algoritmos de prova evoluem.
Modelo de segurança: ZkEVM oferece garantias de validade criptográfica. Optimistic rollups oferecem segurança económica via “fraud proofs” — robusta, mas não equivalente a uma prova matemática de correção.
Compatibilidade EVM: os ZkEVM modernos (Tipos 2/3) praticamente fecharam o fosso e já suportam quase todo o “stack” de ferramentas Ethereum existente, anulando o que foi durante anos uma vantagem importante dos optimistic rollups.
Risco de liveness: sistemas ZkEVM podem parar se o “prover” falhar. Já os optimistic rollups continuam a processar blocos enquanto o “sequencer” estiver operacional.

Nenhuma abordagem é universalmente superior. Aplicações de grande volume, obcecadas com custo mínimo e que toleram períodos longos de levantamento, tendem a preferir optimistic rollups. Projetos que precisam de finalização rápida, liquidação entre cadeias ou provas matemáticas de correção inclinam-se para ZkEVM.

Quem está realmente a ganhar com ZkEVM agora

ZkEVM já não é tecnologia de laboratório. Várias redes estão ativas, com valor bloqueado significativo e utilizadores reais a pagar comissões. Ainda assim, vale a pena entender quem tira mais partido de cada camada da pilha.

Protocolos DeFi que migram da mainnet Ethereum beneficiam de uma semântica de execução praticamente idêntica (Tipos 2/3) e de custos de gas drasticamente mais baixos. Um protocolo que afastava o retalho com comissões de 30 dólares por swap na mainnet pode oferecer transações de frações de cêntimo num ZkEVM, sem reescrever os seus smart contracts.

Bridges e aplicações cross-chain beneficiam de arquiteturas ZkEVM modulares, capazes de publicar provas em múltiplas cadeias. Em vez de confiar num bridge com multisig — historicamente a categoria mais atacada em cripto — os utilizadores podem apoiar‑se numa prova matemática verificada on-chain.

Empresas e instituições que constroem aplicações permissionadas ou semi‑permissionadas passam a ter um ambiente de execução maduro, com auditabilidade criptográfica. Cada transição de estado é comprovadamente correta, algo crítico para conformidade regulatória e reporte contabilístico.

Programadores que iniciam projetos hoje precisam de perceber o trade-off entre Tipo 4 e Tipo 2 antes de escolher a rede. Se está a escrever Solidity de raiz e quer máxima velocidade de prova e as taxas mais baixas possíveis, uma rede Tipo 4 pode ser mais adequada. Se está a migrar um protocolo já existente e não pode correr riscos de diferenças de comportamento, uma rede Tipo 2 ou Tipo 3 é a opção conservadora.

Para o utilizador comum, ZkEVM apresenta‑se sobretudo como mais uma chain compatível com Ethereum — barata, rápida — onde a carteira que já usa funciona e onde os tokens que já detém podem ser bridged sem fricção. Toda a maquinaria criptográfica que suporta isto permanece invisível, exatamente como se espera de uma boa infraestrutura.

Conclusão

ZkEVM é, provavelmente, o problema de convergência mais complexo na criptografia aplicada: pegar numa máquina virtual desenhada sem estrutura matemática e obrigá‑la a “falar” a linguagem das provas de conhecimento zero.

As equipas que o conseguiram passaram anos a lidar com incompatibilidades de funções de hash, explosão de constraints e limitações de hardware de prova que nem sequer existia quando os artigos académicos de base foram publicados.

O setor continua em rápida mutação. Os tempos de geração de provas estão a cair. Redes descentralizadas de “provers” começam a ganhar forma. A equivalência total com o Ethereum (Tipo 1) mantém‑se como objetivo, e várias equipas estão cada vez mais perto.

Para quem constrói em cima do ecossistema Ethereum — ou investe nele — perceber como ZkEVM funciona na prática, para lá dos slogans de marketing, é a base de todas as decisões estratégicas que vêm a seguir.

Leia a seguir: Investida de US$ 500 bi da Nvidia em financiamento de IA coloca tokens de computação cripto sob vigilância

Porque a ZkEVM executa código do Ethereum, mas o comprova com provas de conhecimento zero