EVM compatível vs equivalente: onde implantar seu dApp em 2026

Você implanta um contrato Solidity no Optimism, e ele funciona idêntico ao Ethereum. Você o implanta no zkSync, e a compilação falha. Você o implanta no Moonbeam, e ele funciona — mas o endereço da sua conta muda em outro pallet do Substrate. Você o implanta no Scroll, e ele funciona — mas o opcode COINBASE retorna o endereço de um contrato, não do minerador. Essas diferenças parecem menores até que uma chamada cross-chain falha em produção com $10M de TVL. Este guia técnico detalha por que cada EVM moderna quebra o padrão de forma distinta — e como escolher a rede sem surpresas.

Qual a diferença entre EVM compatível e EVM equivalente?

A EVM (Ethereum Virtual Machine) é o motor de execução do Ethereum: uma máquina baseada em pilha, palavras de 256 bits, opcodes específicos. Desde o sucesso do Ethereum, dezenas de redes copiaram ou adaptaram este modelo. Mas "compatível" e "equivalente" não são a mesma coisa:

• EVM equivalente: cumpre à risca o Ethereum Yellow Paper. Seu contrato Solidity é executado idêntico, byte por byte, opcode por opcode. Ferramentas como Hardhat, Foundry ou Tenderly funcionam sem modificação. Exemplos: Optimism, Base, Arbitrum One, Scroll (Tipo 2).
• EVM compatível: executa contratos Solidity, mas a arquitetura subjacente, o modelo de armazenamento ou o consenso são distintos. Alguns opcodes têm semântica diferente; os endereços de contas podem ser gerados de outra forma. Exemplos: Polygon PoS, Moonbeam, Avalanche subnets, BSC, zkSync Era, Tron.

A diferença parece acadêmica até que você implante. Um contrato que chama SELFDESTRUCT funciona no Ethereum e Optimism. Falha no Scroll. Não compila no zkSync. E aqui começa o problema.

Por que o Ethereum L1 é o padrão canônico?

O Ethereum L1 executa a EVM de forma monolítica e unificada com consenso e disponibilidade de dados. O modelo é:

• Execução por pilha (stack-based): instruções PUSH, POP, ADD, MUL, etc. Cada opcode ocupa 1 byte. Existem ~140 opcodes definidos.
• Palavras de 256 bits: tudo é manipulado como inteiros U256. Mesmo tamanho de um hash Keccak-256.
• Memória volátil endereçável por bytes, com custo de gas quadrático ao expandir. Isso encarece as operações de memória grande para prevenir DoS.
• Storage de chave-valor 256/256 persistido na árvore Merkle-Patricia.
• Endereços H160 (20 bytes), derivados com Keccak-256 sobre a chave pública secp256k1.
• Evolução por EIPs coordenadas em hard forks (Cancun, Pectra, etc.). Cliente Geth, Nethermind, Besu, Reth.

Qualquer divergência em relação a este modelo é uma decisão arquitetônica com consequências. Vamos rede por rede.

Como os rollups otimistas alcançam a equivalência EVM?

Os rollups otimistas (Optimism, Arbitrum, Base) executam transações fora da cadeia do Ethereum L1, mas publicam os dados em L1. Herdam a segurança assumindo que as transações são válidas, com um período de disputa (7 dias) durante o qual qualquer um pode contestar.

OP Stack — equivalência estrita + transações de depósito

O framework OP Stack (Optimism Mainnet, Base, Zora, Mode, World Chain) busca equivalência EVM absoluta. Mas introduz um conceito alheio: transações de depósito para comunicar L1 ↔ L2.

Quando um contrato L1 chama seu homólogo em L2, o OP Stack aplica address aliasing: o endereço do emissor é transformado por um deslocamento fixo para evitar que um contrato malicioso em L1 atue com os privilégios de seu endereço homólogo em L2:

As EOA (contas externas) mantêm o endereço idêntico; apenas os contratos são aliased. Além disso, o OP Stack elimina o mempool público (apenas o sequenciador o vê) e introduz estados de finalidade diferenciados: Unsafe, Safe, Finalized.

Arbitrum Nitro + Stylus — Geth no núcleo + WASM paralelo

Arbitrum Nitro (garantindo >12.000 M$ TVL) adota uma abordagem distinta: executa uma versão modificada do cliente canônico Geth para execução nativa. Se houver disputa, compila a função de transição de estado para WebAssembly e resolve o conflito em L1 por meio de provas de fraude interativas multi-rodadas (BOLD).

A inovação mais radical é o Stylus: uma segunda máquina virtual baseada em WASM que compartilha storage com a EVM tradicional, permitindo implantar contratos em Rust, C ou C++. Sua precificação de gas usa uma unidade chamada tinta (ink) que é convertida para gas EVM:

Como as zkEVM Tipo 2 diferem das Tipo 4?

Os ZK-Rollups usam provas criptográficas (SNARKs/STARKs) para certificar a legitimidade das transações. L1 verifica matematicamente milhares de execuções em segundos. A finalidade de retiradas é quase-imediata (vs 7 dias em otimistas). A taxonomia de Vitalik classifica as zkEVM por nível de equivalência:

Scroll — Tipo 2 (equivalência de bytecode)

Scroll é Tipo 2: o bytecode compilado de Solidity é executado idêntico. Mas introduz modificações obrigadas pelo custo de provar certos opcodes em circuitos Halo2:

• COINBASE não retorna o endereço do validador, mas sim o do contrato de cofre de taxas (0x5300...0005)
• DIFFICULTY e PREVRANDAO sempre retornam 0
• SELFDESTRUCT está completamente desabilitado: qualquer chamada reverte
• EIP-1559 calcula basefee mas não queima ETH

Pré-compilados afetados: RIPEMD-160, blake2f, point evaluation (EIP-4844 blobs) e curvas BLS12 — todos N/A. modexp tem input limitado a 8192 bits. Adiciona-se 0p256Verify nativo para assinaturas secp256r1 (EIP-7951).

zkSync Era — Tipo 4 (equivalência de compilador)

zkSync Era não interpreta bytecode EVM. Usa zksolc (LLVM-based) para traduzir Solidity/Vyper diretamente para EraVM, uma máquina virtual de registros otimizada para circuitos zk. Isso causa discrepâncias profundas:

• Implantação: contratos filhos devem ser declarados no campo factoryDeps de uma transação EIP-712. CREATE e CREATE2 não aceitam código de inicialização dinâmico. type(T).runtimeCode gera erro de compilação.
• Gas de memória: linear constante (1 erg por byte), não quadrático. msize() reporta bytes em vez de palavras de 32.
• Opcodes proibidos: SELFDESTRUCT, CALLCODE, EXTCODECOPY são erros graves na compilação.
• Ether nativo: as transferências são simuladas via contrato sistema MsgValueSimulator — EraVM não suporta passagem de saldos em chamadas internas.
• Variáveis imutáveis: são armazenadas em ImmutableSimulator, não modificando o bytecode do construtor.

zkSync oferece um EVM interpreter opcional para executar bytecode padrão sem recompilar — útil para integrações rápidas, mas perde otimizações.

Por que Moonbeam e Astar têm contas duplas?

As parachains da Polkadot operam sobre Substrate (framework modular Parity). A EVM não é o núcleo: é adicionada como módulo opcional via Frontier (pallets pallet-evm e pallet-ethereum).

O choque de formatos é estrutural:

• Substrate SS58: chaves de 32 bytes, assinaturas sr25519, formato Base58Check
• Ethereum H160: 20 bytes, assinaturas secp256k1, hex

Frontier resolve o endereçamento com um mapeamento unidirecional:

Isso gera uma conta SS58 virtual sem chave privada conhecida, onde os saldos acessíveis da EVM são armazenados. A função hash é unidirecional: impossível deduzir H160 de SS58 arbitrária.

Moonbeam quebrou esse dualismo: reconfigurou todo o runtime do Substrate para usar apenas H160 e secp256k1 de forma nativa. Permite usar MetaMask para assinar tanto transações EVM quanto extrínsecas Substrate. Astar mantém contas duplas, mas adiciona pallet-unified-accounts para gerenciar mapeamento bidirecional explícito.

Para que a EVM acesse o estado nativo da parachain (staking, governança), Frontier usa contratos pré-compilados como tradutores: quando a dApp invoca um pré-compilado, Frontier executa internamente funções de pallets Substrate. Isso permite fazer staking nativo ou votar em referendos a partir de código Solidity.

Quando convém uma sidechain em vez de um rollup?

As sidechains são cadeias soberanas paralelas ao Ethereum: validadores próprios, consenso próprio, sem herança de segurança. A conexão com L1 ocorre por contratos ponte com seu próprio modelo de confiança. Quatro modelos arquitetônicos de pontes:

Gnosis Chain — gas em xDAI estável

Gnosis Chain é uma sidechain PoS assegurada por >200.000 validadores. A diferença técnica mais útil: o gas é pago em xDAI, não em seu token nativo GNO. xDAI é um stablecoin 1:1 USD ponteado do L1. Resultado: transações que custam $0,001-$0,01 previsivelmente, sem volatilidade. Ideal para apps comerciais que exigem taxas estáveis.

Polygon PoS — migrando para Validium

Polygon PoS publica checkpoints em L1 a cada 30 minutos, mas a finalidade operacional é local (validadores DPoS com stake em POL). Está em transição arquitetônica para Validium L2: provas de validade ZK enviadas ao Ethereum para certificar transições de estado sem perder baixo custo. Migração impulsionada pela pressão competitiva pós-Kelp DAO.

Outros casos

• SKALE Network: modelo "gas gratuito" usando sFUEL sem valor econômico. Quebra protocolos cross-chain como LayerZero que exigem pagamento de gas no destino — requer ERC-20 secundário.
• Avalanche Subnets: EVM personalizada com gas em token nativo da subnet ou ERC-20 específico.
• Tron VM: Solidity sim, mas API distinta (TronWeb em vez de Web3.js/Ethers). Gas pago em TRX.

O que acontece com SELFDESTRUCT, COINBASE e outros opcodes raros?

Resumo de qual rede quebra qual opcode:

Se seu contrato depende de qualquer um desses, testá-lo em cada rede antes de migrar é obrigatório. Não basta verificar se compila.

Como decido onde implantar meu dApp?

Quatro perguntas em ordem:

1. Você precisa da máxima segurança do Ethereum? → L2 rollup. Optimism, Arbitrum, Base se você quer equivalência estrita. Scroll se você precisa de finalidade rápida com zk.
2. Você tem lógica computacional pesada (verificação de provas, AI on-chain, big data)? → Arbitrum Stylus para WASM. zkSync EraVM se você aceita perder ferramentas padrão em troca de desempenho.
3. Você precisa de governança complexa ou staking nativo? → Parachain (Moonbeam, Astar). Você aceita o dualismo de contas em troca de acesso ao ecossistema Polkadot.
4. Seu aplicativo é comercial e precisa de gas previsível? → Gnosis Chain (xDAI). Você paga com confiança na ponte; ganha estabilidade de taxas.

A conclusão incômoda: não existe rede "melhor" universal. Existem redes otimizadas para casos de uso específicos. A equivalência EVM resolve a fricção de desenvolvimento, não necessariamente a fricção operacional. A compatibilidade EVM aceitável quebra ferramentas, mas abre capacidades impossíveis em L1.

Guias relacionados