---
id: 16
title: "Qué significa realmente la compatibilidad con EVM: bytecode, precompilados, JSON-RPC y herramientas"
slug: evm-compatibility-explained
date: 2026/09/03
summary: «Compatible con EVM» suele aplanarse en una línea de marketing. Lo que de verdad determina el costo de migración es la semántica del bytecode, el conjunto de precompilados, el comportamiento de JSON-RPC y si Foundry/Hardhat siguen funcionando sin cambios. Este artículo separa esas cuatro capas y explica por qué el paralelismo hace más difícil mantener la compatibilidad.
keywords: compatibilidad con EVM,bytecode,precompilados,JSON-RPC,Foundry,Hardhat
heroImage: /images/community-bg.png
---

Casi todas las páginas de inicio de una cadena nueva dicen «totalmente compatible con EVM». Esa frase suena a garantía técnica y se comporta más bien como una afirmación que exige repreguntas: ¿los contratos se pueden desplegar sin cambiar el bytecode? ¿Las carteras y los exploradores pueden cambiar solo el endpoint RPC? ¿O «compatible» significa apenas «puedes escribir Solidity»? Son tres promesas de ingeniería muy distintas que el marketing suele comprimir en una sola frase.

Para una cadena que mantiene la compatibilidad con EVM mientras rediseña la ejecución en torno al paralelismo, esto es una restricción diaria, no retórica. Después de reordenar las planificaciones y agregar detección de conflictos y ejecución multi-motor, lo que importa es si el comportamiento visible para los autores de contratos sigue coincidiendo con Ethereum. [Posicionamiento de Bitroot](/es/blog/bitroot-positioning) explicó por qué Bitroot insiste en la compatibilidad total con EVM; este artículo descompone «total» en cuatro capas comprobables.

## Bytecode: la unidad mínima de compatibilidad es el opcode, no la sintaxis

La EVM nunca ejecuta el código fuente de Solidity. Ejecuta opcodes compilados —un conjunto de instrucciones construido en torno a pila, memoria y almacenamiento— más un modelo de cuentas donde cada dirección tiene nonce, saldo, hash de código y su propio árbol de almacenamiento. La compatibilidad estricta significa que la semántica de los opcodes, la medición de gas, los límites de profundidad de pila y las reglas de lectura/escritura de cuentas coinciden con un hard fork objetivo de Ethereum. Bajo ese listón, el bytecode no recompilado debería, en principio, producir la misma transición de estado en otra cadena.

Ese estándar fija el piso del costo de migración. La compatibilidad a nivel de bytecode significa que los contratos auditados no necesitan una reauditoría total por una deriva silenciosa en la capa de sintaxis; los contratos que dependen de la derivación de direcciones por CREATE2 o de un costo de gas específico de un opcode para sus defensas de reentrada no deberían comportarse mal porque el precio cambió por debajo. Si una cadena solo «permite escribir contratos en Solidity», los desarrolladores obtienen familiaridad de sintaxis, y una deriva en el momento en que tocan opcodes poco comunes o supuestos de gas.

Conviene comprobar también la alineación con los hard forks: el conjunto de opcodes válidos no es idéntico entre Shanghai, Cancun y las actualizaciones posteriores. Una afirmación de compatibilidad debería nombrar la actualización de Ethereum que sigue, en lugar de agitar una «EVM» vaga. Los equipos que migran pueden volver a desplegar el bytecode de ejecución de la mainnet y comparar los hashes de código y los valores de retorno en rutas de llamada críticas.

La ejecución paralela añade presión. El paralelismo optimista puede especular de forma concurrente y revertir después, pero para los autores de contratos la transición de estado confirmada debe seguir siendo equivalente a algún orden serial definido (normalmente el orden de las transacciones dentro del bloque). Si la planificación cambia el estado final visible, eso no es compatibilidad: es otra máquina virtual. Para los límites de corrección y la serializabilidad, véase [Introducción al control de concurrencia optimista (OCC)](/es/blog/optimistic-concurrency-control-intro). Para ubicar el paralelismo en un mapa de escalabilidad más amplio, compare [Un mapa de la escalabilidad de la cadena de bloques](/es/blog/blockchain-scaling-map) y [El cuello de botella de la EVM de un solo hilo](/es/blog/evm-single-thread-bottleneck): la compatibilidad debe preservar la semántica determinista en la que confían los autores de contratos, no el intérprete de un solo hilo en sí.

## Precompilados: misma dirección con implementación distinta es incompatibilidad

Ethereum implementa operaciones costosas como contratos precompilados en direcciones fijas, como `0x01`–`0x0a`: emparejamiento de curvas elípticas, exponenciación modular, hashing y más. Las aplicaciones y las bibliotecas fijan esas direcciones y esos costos de gas. Si una cadena cambia el conjunto de precompilados, el mapeo de direcciones o la semántica de retorno, Solidity puede seguir compilando mientras la compatibilidad ya está rota: bibliotecas auditadas pueden fallar en cadena o devolver resultados incorrectos.

Entre los patrones comunes de «compatibilidad falsa» están implementar solo los precompilados populares, agregar precompilados personalizados en direcciones reservadas de Ethereum o cambiar el gas sin documentarlo. Los equipos que migran no deberían confiar en la línea «compatible con EVM» del libro blanco; deberían compararla con la tabla de precompilados del fork objetivo: misma entrada y calldata, mismo valor de retorno y mismo gas en la mainnet frente a la cadena objetivo. Las rutas de emparejamiento y modexp merecen cobertura especial porque son costosas y a menudo las usan puentes, verificación de pruebas y bibliotecas criptográficas.

La EVM paralela no exige cambiar la semántica de los precompilados. El riesgo real es la tentación de especializarse «por velocidad». Cualquier cambio de precompilado por rendimiento debería ser una diferencia de protocolo explícita, no colarse en una narrativa de compatibilidad. Si un equipo agrega precompilados personalizados para cómputo especializado, debería usar un espacio de direcciones claramente no reservado y documentar la diferencia, para que las direcciones reservadas de Ethereum queden intactas.

## JSON-RPC: las herramientas viven o mueren por la interfaz, no por el eslogan

Contratos desplegables no es lo mismo que un ecosistema utilizable. Las carteras, los exploradores, los indexadores y los monitores dependen de JSON-RPC: `eth_call`, `eth_getLogs`, `eth_estimateGas`, `eth_getTransactionReceipt` y el resto. Si los significados de los campos, los códigos de error, la indexación de logs o la semántica de pendiente frente a último difieren de las costumbres de los clientes de Ethereum, los frontends y la infraestructura necesitan adaptadores, y el costo de migración pasa de «cambiar el RPC» a «reconstruir la ruta operativa».

`eth_estimateGas` y las APIs de trazas merecen atención especial. Bajo ejecución paralela, las estimaciones de gas que no simulan la semántica serial final pueden quedar sistemáticamente bajas o altas; sin trazas isomorfas a la mainnet, los tests de fork de Foundry y el análisis forense de incidentes se vuelven más difíciles. La compatibilidad de JSON-RPC, por tanto, no es que «MetaMask se conecte», sino que las rutas cotidianas de desarrollo y operación sigan siendo reutilizables. Las suscripciones a filtros, `eth_feeHistory` y los campos relacionados con EIP-1559 suelen decidir si los SDK existentes pueden salir a producción con poco más que un cambio de configuración.

Los indexadores y los exploradores también necesitan un orden de logs y campos de recibo estables. Si la ejecución paralela cambia cuándo es visible el estado intermedio pero los recibos finales siguen siendo isomorfos a la mainnet, las aplicaciones suelen poder adaptarse; si faltan campos de recibo o los códigos de error son propietarios, las herramientas del ecosistema necesitan mantenimiento bifurcado. La aceptación de compatibilidad debería tratar «llamada de lectura + envío de transacción + extracción de logs + estimación de gas» como un solo ciclo cerrado, no solo un despliegue exitoso.

## Herramientas: Foundry y Hardhat son el tribunal de última instancia

Para la mayoría de los equipos, la compatibilidad se juzga en local: si `forge test`, los scripts de Hardhat, los contratos de OpenZeppelin y los plugins de verificación comunes corren contra el RPC objetivo con poco o ningún cambio. Foundry (Forge / Cast / Anvil) es la pila de pruebas por defecto de muchos proyectos nuevos; Hardhat todavía cubre una gran base instalada. Ambos asumen que la salida del compilador, los precompilados en cadena y el comportamiento de RPC son lo bastante cercanos a Ethereum.

Una lista de aceptación breve y repetible:

1. Compilar con la misma versión de Solidity y los mismos ajustes del optimizador; comprobar si los hashes del bytecode desplegado coinciden con los despliegues de la mainnet (o difieren solo por inmutables explicables).
2. Comparar los precompilados críticos.
3. Bifurcar el estado de la cadena objetivo con Anvil / Hardhat Network y correr las pruebas de integración existentes.
4. Cambiar solo el chainId y el RPC en una cartera y completar firmar → enviar → recibo.
5. Correr pruebas de invariantes sobre los contratos centrales: conservación de saldos, control de acceso y defensas de reentrada siguen cumpliéndose en la cadena objetivo.

Cualquier fallo significa que «compatible» todavía tiene huecos. Bitroot pone la complejidad en la planificación paralela del runtime en lugar de pedir a los desarrolladores que reescriban Solidity o cambien de cadena de herramientas, así que las rutas anteriores pueden permanecer intactas; véase también [La tecnología de EVM paralelizada de Bitroot explicada](/es/blog/bitrootevm-) y [Diseño de ejecución paralela multi-motor](/es/blog/bitroot-evm). En comparación con [Tres caminos hacia la ejecución paralela](/es/blog/parallel-execution-approaches), insistir en la compatibilidad de bytecode significa renunciar a parte del techo de paralelismo disponible con modelos de cuentas nuevos, a cambio de un radio de migración más amplio para el ecosistema de desarrolladores.

## Cómo leer una afirmación de «compatible con EVM»

Convierta la frase de marketing en cuatro preguntas de sí o no: ¿la semántica del bytecode coincide con el hard fork objetivo? ¿La tabla de precompilados es idéntica? ¿JSON-RPC cubre los métodos comunes de la mainnet con semántica isomorfa? ¿Los proyectos existentes de Foundry / Hardhat pueden correr con poco o ningún cambio? Cuatro «sí» se acercan a la compatibilidad estricta; cualquier «no» debería ser un documento de diferencias explícito, no algo escondido detrás de un eslogan.

El paralelismo puede cambiar el rendimiento y la latencia bajo conflicto, pero no debería reescribir la semántica determinista en la que confían los autores de contratos. Los reintentos visibles para el usuario y los cambios de latencia bajo cargas calientes son cuestiones de rendimiento y de carga de trabajo, separadas de «si la semántica es compatible»; véanse más adelante [Hotspots de conflicto y cargas de trabajo](/es/blog/parallel-evm-workload-hotspots) y [Glosario de métricas de rendimiento](/es/blog/performance-metrics-glossary). Una cadena que compra un benchmark más rápido volviendo impredecibles las herramientas y el comportamiento del bytecode gasta capital de ecosistema a largo plazo por un cartel de corto plazo, y los efectos de red del camino EVM son justamente lo que ese cartel intenta comprar.

El artículo siguiente ofrece rutas de lectura por rol que apuntan solo a entradas ya publicadas, para que orígenes distintos no se amontonen en un artículo que nadie puede terminar.

## Lecturas relacionadas

- Anterior: [Posicionamiento de Bitroot: los límites de un Layer 1 con EVM paralela optimista](/es/blog/bitroot-positioning)
- Siguiente: [Quién debería leer sobre la EVM paralela: tres caminos para desarrolladores de contratos, ingenieros de cliente e investigadores](/es/blog/who-should-read-parallel-evm)
- Relacionado: [El cuello de botella de la EVM de un solo hilo](/es/blog/evm-single-thread-bottleneck), [Introducción al control de concurrencia optimista (OCC)](/es/blog/optimistic-concurrency-control-intro)