EVM compatible vs equivalente: dónde desplegar tu dApp en 2026

Despliegas un contrato Solidity en Optimism, funciona idéntico que en Ethereum. Lo despliegas en zkSync, falla la compilación. Lo despliegas en Moonbeam, funciona — pero la dirección de tu cuenta cambia en otro pallet de Substrate. Lo despliegas en Scroll, funciona — pero el opcode COINBASE devuelve la dirección de un contrato, no del minero. Estas diferencias parecen menores hasta que una llamada cross-chain falla en producción con $10M de TVL. Esta guía técnica desglosa por qué cada EVM moderna rompe el estándar de forma distinta — y cómo elegir red sin sorpresas.

¿Qué diferencia hay entre EVM compatible y EVM equivalente?

La EVM (Ethereum Virtual Machine) es el motor de ejecución de Ethereum: una máquina basada en pila, palabras de 256 bits, opcodes específicos. Desde el éxito de Ethereum, decenas de redes han copiado o adaptado este modelo. Pero "compatible" y "equivalente" no son lo mismo:

• EVM equivalente: cumple al pie de la letra el Ethereum Yellow Paper. Tu contrato Solidity se ejecuta idéntico, byte por byte, opcode por opcode. Herramientas como Hardhat, Foundry o Tenderly funcionan sin modificación. Ejemplos: Optimism, Base, Arbitrum One, Scroll (Tipo 2).
• EVM compatible: ejecuta contratos Solidity, pero la arquitectura subyacente, el modelo de almacenamiento o el consenso son distintos. Algunos opcodes tienen semántica diferente; las direcciones de cuentas pueden generarse de otra forma. Ejemplos: Polygon PoS, Moonbeam, Avalanche subnets, BSC, zkSync Era, Tron.

La diferencia parece académica hasta que despliegas. Un contrato que llama a SELFDESTRUCT funciona en Ethereum y Optimism. Falla en Scroll. No compila en zkSync. Y aquí empieza el problema.

¿Por qué Ethereum L1 es el estándar canónico?

Ethereum L1 ejecuta la EVM de forma monolítica y unificada con consenso y disponibilidad de datos. El modelo es:

• Ejecución por pila (stack-based): instrucciones PUSH, POP, ADD, MUL, etc. Cada opcode ocupa 1 byte. Hay ~140 opcodes definidos.
• Palabras de 256 bits: todo se manipula como enteros U256. Mismo tamaño que un hash Keccak-256.
• Memoria volátil direccionable por bytes, con coste de gas cuadrático al expandirse. Esto encarece las operaciones de memoria grande para prevenir DoS.
• Storage de clave-valor 256/256 persistido en el árbol Merkle-Patricia.
• Direcciones H160 (20 bytes), derivadas con Keccak-256 sobre la clave pública secp256k1.
• Evolución por EIPs coordinadas en hard forks (Cancun, Pectra, etc.). Cliente Geth, Nethermind, Besu, Reth.

Cualquier divergencia respecto a este modelo es una decisión arquitectónica con consecuencias. Vamos red por red.

¿Cómo logran los rollups optimistas la equivalencia EVM?

Los rollups optimistas (Optimism, Arbitrum, Base) ejecutan transacciones fuera de la cadena de Ethereum L1, pero publican los datos en L1. Heredan la seguridad asumiendo que las transacciones son válidas, con un periodo de disputa (7 días) durante el cual cualquiera puede impugnar.

OP Stack — equivalencia estricta + transacciones de depósito

El framework OP Stack (Optimism Mainnet, Base, Zora, Mode, World Chain) persigue equivalencia EVM absoluta. Pero introduce un concepto ajeno: transacciones de depósito para comunicar L1 ↔ L2.

Cuando un contrato de L1 llama a su homólogo en L2, OP Stack aplica address aliasing: la dirección del emisor se transforma mediante un desplazamiento fijo para evitar que un contrato malicioso en L1 actúe con los privilegios de su dirección homóloga en L2:

Las EOA (cuentas externas) sí mantienen dirección idéntica; solo los contratos se aliasian. Además OP Stack elimina el mempool público (solo el secuenciador lo ve) e introduce estados de finalidad diferenciados: Unsafe, Safe, Finalized.

Arbitrum Nitro + Stylus — Geth en el núcleo + WASM paralelo

Arbitrum Nitro (asegurando >12.000 M$ TVL) toma un enfoque distinto: corre una versión modificada del cliente canónico Geth para ejecución nativa. Si hay disputa, compila la función de transición de estado a WebAssembly y resuelve el conflicto en L1 mediante pruebas de fraude interactivas multi-ronda (BOLD).

La innovación más radical es Stylus: una segunda máquina virtual basada en WASM que comparte storage con la EVM tradicional, permitiendo desplegar contratos en Rust, C o C++. Su tarificación de gas usa una unidad llamada tinta (ink) que se convierte a gas EVM:

¿Cómo difieren las zkEVM Tipo 2 vs Tipo 4?

Los ZK-Rollups usan pruebas criptográficas (SNARKs/STARKs) para certificar la legitimidad de las transacciones. L1 verifica matemáticamente miles de ejecuciones en segundos. La finalidad de retiradas es cuasi-inmediata (vs 7 días en optimistas). La taxonomía de Vitalik clasifica las zkEVM por nivel de equivalencia:

Scroll — Tipo 2 (equivalencia de bytecode)

Scroll es Tipo 2: el bytecode compilado de Solidity se ejecuta idéntico. Pero introduce modificaciones obligadas por el coste de probar ciertos opcodes en circuitos Halo2:

• COINBASE no devuelve la dirección del validador, sino la del contrato de bóveda de tarifas (0x5300...0005)
• DIFFICULTY y PREVRANDAO devuelven siempre 0
• SELFDESTRUCT está completamente deshabilitado: cualquier llamada revierte
• EIP-1559 calcula basefee pero no quema ETH

Precompilados afectados: RIPEMD-160, blake2f, point evaluation (EIP-4844 blobs) y curvas BLS12 — todos N/A. modexp tiene input limitado a 8192 bits. Se añade 0p256Verify nativo para firmas secp256r1 (EIP-7951).

zkSync Era — Tipo 4 (equivalencia de compilador)

zkSync Era no interpreta bytecode EVM. Usa zksolc (LLVM-based) para traducir Solidity/Vyper directamente a EraVM, una máquina virtual de registros optimizada para circuitos zk. Esto provoca discrepancias profundas:

• Despliegue: contratos hijos deben declararse en el campo factoryDeps de una transacción EIP-712. CREATE y CREATE2 no aceptan código de inicialización dinámico. type(T).runtimeCode arroja error de compilación.
• Gas de memoria: lineal constante (1 erg por byte), no cuadrático. msize() reporta bytes en vez de palabras de 32.
• Opcodes prohibidos: SELFDESTRUCT, CALLCODE, EXTCODECOPY son errores duros en compilación.
• Ether nativo: las transferencias se simulan vía contrato sistema MsgValueSimulator — EraVM no soporta paso de saldos en llamadas internas.
• Variables inmutables: se almacenan en ImmutableSimulator, no modificando el bytecode del constructor.

zkSync ofrece un EVM interpreter opcional para ejecutar bytecode estándar sin recompilar — útil para integraciones rápidas pero pierde optimizaciones.

¿Por qué Moonbeam y Astar tienen cuentas duales?

Las parachains de Polkadot operan sobre Substrate (framework modular Parity). La EVM no es el núcleo: se añade como módulo opcional vía Frontier (pallets pallet-evm y pallet-ethereum).

El choque de formatos es estructural:

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

Frontier resuelve el direccionamiento con un mapeo unidireccional:

Esto genera una cuenta SS58 virtual sin clave privada conocida, donde se almacenan los saldos accesibles desde EVM. La función hash es unidireccional: imposible deducir H160 desde SS58 arbitraria.

Moonbeam rompió este dualismo: reconfiguró todo el runtime de Substrate para usar solo H160 y secp256k1 de forma nativa. Permite usar MetaMask para firmar tanto transacciones EVM como extrínsecas Substrate. Astar mantiene cuentas duales pero añade pallet-unified-accounts para gestionar mapeo bidireccional explícito.

Para que la EVM acceda al estado nativo de la parachain (staking, gobernanza), Frontier usa contratos precompilados como traductores: cuando la dApp invoca un precompilado, Frontier ejecuta internamente funciones de pallets Substrate. Esto permite hacer staking nativo o votar en referéndums desde código Solidity.

¿Cuándo conviene una sidechain en vez de un rollup?

Las sidechains son cadenas soberanas paralelas a Ethereum: validadores propios, consenso propio, sin herencia de seguridad. La conexión con L1 va por contratos puente con su propio modelo de confianza. Cuatro modelos arquitectónicos de puentes:

Gnosis Chain — gas en xDAI estable

Gnosis Chain es una sidechain PoS asegurada por >200.000 validadores. La diferencia técnica más útil: el gas se paga en xDAI, no en su token nativo GNO. xDAI es un stablecoin 1:1 USD puenteado desde L1. Resultado: transacciones que cuestan $0,001-$0,01 predeciblemente, sin volatilidad. Ideal para apps comerciales que requieren tarifas estables.

Polygon PoS — migrando a Validium

Polygon PoS publica checkpoints en L1 cada 30 minutos, pero la finalidad operacional es local (validadores DPoS con stake en POL). Está en transición arquitectónica hacia Validium L2: pruebas de validez ZK enviadas a Ethereum para certificar transiciones de estado sin perder bajo coste. Migración impulsada por presión competitiva post-Kelp DAO.

Otros casos

• SKALE Network: modelo "gas gratuito" usando sFUEL sin valor económico. Rompe protocolos cross-chain como LayerZero que exigen pago de gas en destino — requiere ERC-20 secundario.
• Avalanche Subnets: EVM personalizada con gas en token nativo de la subnet o ERC-20 específico.
• Tron VM: Solidity sí, pero API distinta (TronWeb en vez de Web3.js/Ethers). Gas pagado en TRX.

¿Qué pasa con SELFDESTRUCT, COINBASE y otros opcodes raros?

Resumen de qué red rompe qué opcode:

Si tu contrato depende de cualquiera de estos, probarlo en cada red antes de migrar es obligatorio. No basta con verificar que compila.

¿Cómo decido dónde desplegar mi dApp?

Cuatro preguntas en orden:

1. ¿Necesitas máxima seguridad de Ethereum? → L2 rollup. Optimism, Arbitrum, Base si quieres equivalencia estricta. Scroll si necesitas finalidad rápida con zk.
2. ¿Tienes lógica computacional pesada (verificación de pruebas, AI on-chain, big data)? → Arbitrum Stylus para WASM. zkSync EraVM si aceptas perder herramientas estándar a cambio de rendimiento.
3. ¿Necesitas gobernanza compleja o staking nativo? → Parachain (Moonbeam, Astar). Aceptas el dualismo de cuentas a cambio de acceso al ecosistema Polkadot.
4. ¿Tu app es comercial y necesita gas predecible? → Gnosis Chain (xDAI). Pagas con confianza en el puente; ganas estabilidad de tarifas.

La conclusión incómoda: no hay red "mejor" universal. Hay redes optimizadas para casos de uso específicos. La equivalencia EVM resuelve fricción de desarrollo, no necesariamente fricción operativa. La compatibilidad EVM aceptable rompe herramientas pero abre capacidades imposibles en L1.

Guías relacionadas