La Máquina Virtual de Ethereum (EVM) es una máquina virtual basada en pila, casi Turing completa, que sirve como entorno de ejecución para contratos inteligentes en la cadena de bloques de Ethereum y en todas las redes compatibles con EVM. Es el motor computacional central de Ethereum, responsable de procesar cada transición de estado —desde simples transferencias de ETH hasta complejas interacciones de protocolos de finanzas descentralizadas (DeFi)— de forma determinista y aislada, lo que garantiza que cada nodo de la red obtenga el mismo resultado para cualquier transacción.
La EVM opera ejecutando instrucciones de bajo nivel llamadas opcodes, que se compilan a partir de lenguajes de programación de alto nivel como Solidity y Vyper en bytecode. Cada opcode realiza una operación atómica específica: cálculos aritméticos, manipulación de memoria, lecturas y escrituras de almacenamiento, hash criptográfico y lógica de control de flujo. Cuando un usuario o contrato inicia una transacción que llama a un contrato inteligente, la EVM carga el bytecode del contrato desde el árbol de estado de la cadena de bloques y lo procesa instrucción por instrucción, consumiendo un recurso medido llamado "gas" por cada operación. Este mecanismo de medición de gas evita bucles infinitos y el abuso de recursos al exigir que el remitente de la transacción pague por el trabajo computacional que requiere su transacción.
Fundamentalmente, la EVM está diseñada para ser completamente determinista y aislada. Con entradas idénticas y el mismo estado de la cadena de bloques, cada nodo que ejecuta la EVM producirá exactamente la misma salida. Este determinismo es lo que permite que miles de nodos en todo el mundo verifiquen transacciones de forma independiente y mantengan el consenso sobre el estado global de la red Ethereum. El diseño aislado de la EVM también garantiza que la ejecución de contratos inteligentes no pueda acceder al sistema de archivos, la red ni el sistema operativo de la máquina anfitriona, lo que impide que los contratos maliciosos comprometan los nodos que los ejecutan.
La influencia de la EVM se extiende mucho más allá de Ethereum. Su arquitectura se ha convertido en el estándar de facto para la ejecución de contratos inteligentes en toda la industria blockchain. Las principales redes, como BNB Smart Chain (BSC), Polygon, Avalanche C-Chain, Arbitrum, Optimism, Fantom, Cronos y muchas otras, han adoptado la compatibilidad con EVM, lo que permite a los desarrolladores implementar los mismos contratos inteligentes Solidity en múltiples cadenas con mínimas modificaciones. Esta compatibilidad entre cadenas ha creado un enorme ecosistema de herramientas compartidas, conocimiento de desarrolladores y protocolos componibles que, en conjunto, conforman la columna vertebral del ecosistema de aplicaciones descentralizadas (dApps).
Origen e Historia
2013: Vitalik Buterin publicó el libro blanco de Ethereum, en el que propone una cadena de bloques con un lenguaje de programación Turing-completo integrado capaz de ejecutar contratos inteligentes arbitrarios. El libro blanco describe el concepto de máquina virtual como capa de ejecución, lo que distingue a Ethereum del lenguaje Script, más limitado, de Bitcoin.
2014: Gavin Wood fue el autor del Libro Amarillo de Ethereum, donde especificó formalmente la arquitectura de la EVM en términos matemáticos rigurosos. El Libro Amarillo definió el conjunto de instrucciones, los costos de gas, la función de transición de estado y el modelo de memoria que regirían la ejecución de los contratos inteligentes. Esta especificación formal se convirtió en la referencia canónica para todas las implementaciones de la EVM.
2015: Ethereum se lanzó el 30 de julio con la versión Frontier. La EVM entró en funcionamiento con su conjunto inicial de aproximadamente 140 códigos de operación, lo que permitió la ejecución de los primeros contratos inteligentes en una cadena de bloques pública. Los primeros contratos eran sencillos (emisores de tokens y monederos multifirma), pero demostraron la viabilidad de la EVM como motor de computación de propósito general.
2016: El ataque informático a The DAO el 17 de junio expuso una vulnerabilidad crítica de reentrada en el diseño de contratos inteligentes de la EVM. Aproximadamente 60 millones de dólares en ETH (unos 3.6 millones de ETH) fueron sustraídos del contrato de The DAO mediante una vulnerabilidad de llamada recursiva. Si bien la vulnerabilidad residía en el código del contrato inteligente y no en la propia EVM, el incidente impulsó una profunda investigación sobre los patrones de seguridad de la EVM y condujo al desarrollo de patrones de diseño de comprobaciones, efectos e interacciones, así como de protección contra la reentrada. Las consecuencias también derivaron en la polémica bifurcación de Ethereum, que dividió la cadena en Ethereum (ETH) y Ethereum Classic (ETC).
2017 2018-: El auge de las ICO impulsó la adopción masiva de contratos inteligentes de Ethereum, poniendo a prueba la EVM a una escala sin precedentes. El estándar de token ERC-20 se convirtió en el tipo de contrato más utilizado, y la EVM procesó millones de transferencias de tokens. CryptoKitties (diciembre de 2017) congestionó la red, revelando las limitaciones de rendimiento de la EVM.
2019 2020-: El verano de 2020 en el sector DeFi impulsó la popularidad de protocolos como Uniswap, Aave y Compound, obligando a la EVM a gestionar interacciones multicontrato cada vez más complejas. Los precios del gas se dispararon hasta alcanzar cientos de gwei, y la optimización del gas de la EVM se convirtió en una habilidad fundamental para los desarrolladores de Solidity.
2021 2022-: Las cadenas compatibles con EVM experimentaron un auge de popularidad. BSC, Polygon, Avalanche, Fantom y Arbitrum lanzaron entornos de ejecución compatibles con EVM, lo que permitió a los desarrolladores portar dApps de Ethereum con un mínimo esfuerzo. El término "compatible con EVM" se convirtió en un requisito de marketing para las nuevas cadenas de capa 1 y capa 2.
2022 2024-: La fusión de Ethereum con Proof-of-Stake (septiembre de 2022) no modificó la EVM en sí, pero sí alteró la capa de consenso subyacente. Se intensificaron las investigaciones sobre arquitecturas sucesoras de la EVM, con propuestas para la actualización del EOF (EVM Object Format) y debates sobre una posible migración a entornos de ejecución basados en eWASM o RISC-V. La actualización Dencun (marzo de 2024) introdujo las transacciones de blobs EIP-4844, ampliando las capacidades de disponibilidad de datos de la EVM para las agregaciones.
En términos simples
Imagina la máquina de votación electrónica (EVM) como una calculadora compartida gigante que ejecuta el mismo programa en miles de ordenadores simultáneamente. Todos los ordenadores obtienen la misma respuesta porque las reglas de la calculadora están perfectamente definidas. Si alguien intenta hacer trampa, todos los demás ordenadores lo saben inmediatamente porque sus respuestas no coinciden.
Imagina una máquina expendedora con un manual de instrucciones muy detallado. Al insertar monedas (gasolina) y pulsar botones (realizar una transacción), la máquina sigue las instrucciones paso a paso para dispensar el producto (ejecutar el contrato). El manual de instrucciones es el mismo para todas las máquinas expendedoras del mundo, así que siempre sabrás qué sucede al pulsar cada botón.
La EVM funciona como un traductor universal para contratos inteligentes. Un desarrollador escribe código en un lenguaje legible para humanos (Solidity), la EVM lo traduce a instrucciones de máquina (bytecode) y, a continuación, todos los nodos de Ethereum utilizan ese mismo lenguaje de máquina. Por eso, un contrato escrito una sola vez puede ejecutarse en Ethereum, Polygon, BSC y Arbitrum sin necesidad de reescribirlo.
Imagínese un servicio de depósito en garantía notariado con un robot incorruptible como agente. Usted le da al robot reglas específicas («libera este dinero solo cuando ambas partes firmen»), y el robot las sigue al pie de la letra: sin sobornos, sin errores, sin interrupciones. La EVM es ese robot, y las reglas son el código del contrato inteligente.
Es como una máquina recreativa donde cada juego cuesta tokens. Los juegos sencillos (transferencias básicas) cuestan solo unos pocos tokens, mientras que los juegos complejos (intercambios DeFi a través de múltiples pools) cuestan muchos más. Si te quedas sin tokens a mitad de partida, la máquina se detiene y tu juego termina, pero no recuperas tus tokens. Así es como funciona el gas en la EVM.
Importante: La EVM es determinista, pero no infalible. Los errores en el código de los contratos inteligentes implementados en la EVM pueden provocar vulnerabilidades y la pérdida de fondos. La EVM ejecuta exactamente lo que se le indica; si las instrucciones son erróneas, los resultados también lo serán. Siempre audite los contratos inteligentes antes de interactuar con ellos, especialmente cuando hay mucho valor en juego.
Características técnicas clave
Arquitectura basada en pilas
La EVM utiliza una pila de último en entrar, primero en salir (LIFO) con una profundidad máxima de 1,024 elementos.
Cada elemento de la pila tiene un ancho de 256 bits (32 bytes), lo que coincide con el tamaño de palabra nativo de Ethereum.
Las operaciones aritméticas y lógicas extraen operandos de la pila y devuelven los resultados.
El diseño basado en pilas simplifica la verificación formal y mantiene la implementación compacta.
A diferencia de las máquinas virtuales basadas en registros (como LLVM), la arquitectura de pila evita la complejidad de la asignación de registros.
Conjunto de instrucciones de código de operación
La EVM define aproximadamente 140 o códigos de operación organizados en categorías: aritmética, comparación, operaciones a nivel de bits, hash, entorno, bloques, pila/memoria/almacenamiento, registro, sistema y operaciones de inserción/duplicación/intercambio.
Los códigos de operación clave incluyen: ADD, MUL, SLOAD, SSTORE, CALL, DELEGATECALL, CREATE, CREATE2, SELFDESTRUCT, LOG0–LOG4, y REVERT
Cada código de operación tiene un costo de gas fijo o dinámico definido en el Libro Amarillo, actualizado a través de EIP (por ejemplo, EIP-2929 aumentó los costos de acceso al almacenamiento en frío).
El DELEGATECALL El código de operación habilita el patrón proxy, que es fundamental para los contratos inteligentes actualizables.
Cómo funciona la ejecución de EVM
Se envía una transacción a la red dirigida a una dirección de contrato con datos de llamada que especifican la función y los parámetros.
La EVM carga el código de bytes del contrato objetivo desde el árbol de estado mundial en su contexto de ejecución.
Se crea un nuevo marco de ejecución con la memoria asignada, una pila vacía y el límite de gas de la transacción.
El contador de programa comienza en el byte 0, y la EVM lee y ejecuta los códigos de operación secuencialmente.
Cada código de operación consume gas según su coste definido; si se agota el gas, la ejecución se detiene con una excepción de "falta de gas" y se revierten todos los cambios de estado.
Cuando la ejecución finaliza correctamente, los cambios de estado (escrituras en el almacenamiento, transferencias de saldo, despliegues de nuevos contratos) se confirman en el estado global.
Se genera un recibo de transacción que contiene el estado de ejecución, el gas utilizado, los registros de eventos emitidos y cualquier dato devuelto.
Sistema de medición de gas
El gas sirve como unidad de esfuerzo computacional, asignando a cada código de operación un precio proporcional a su consumo de recursos.
Operaciones simples como ADD cuesta 3 de gas, mientras que el almacenamiento escribe (SSTORE) cuesta entre 5,000 y 20,000 de gas dependiendo de si la ranura se está configurando desde cero o modificada
El coste base de la transacción es de 21,000 unidades de gas, con costes adicionales para los datos de llamada (4 unidades de gas por byte cero, 16 unidades de gas por byte distinto de cero).
EIP-1559 (actualización de Londres, agosto de 2021) introdujo una tarifa base que se quema más una tarifa de prioridad opcional (propina) para el constructor de bloques.
El límite de gas por bloque (~30 millones a partir de 2024) limita el cálculo total por bloque, lo que limita efectivamente el rendimiento de la EVM.
Modelo de memoria y almacenamiento
Pila: Pila LIFO volátil de 1024 elementos para cálculos intermedios; de uso gratuito pero con profundidad limitada.
Memoria: Memoria lineal volátil, direccionable por bytes, que se expande según sea necesario; el consumo de gas es proporcional al cuadrado del tamaño asignado.
Almacenamiento: Almacén persistente de clave-valor de 256 bits asociado a cada dirección de contrato; este es el recurso más costoso (20 000 unidades de gas para escribir en una nueva ranura).
Datos de llamada: Datos de entrada de solo lectura asociados a la transacción; más económicos que la memoria y el almacenamiento, utilizados para los parámetros de la función.
Ventajas desventajas
Ventajas
Desventajas
Portabilidad entre cadenas: Los contratos inteligentes escritos para la EVM se pueden implementar en docenas de cadenas compatibles con la EVM (BSC, Polygon, Avalanche, Arbitrum, Optimism) con cambios mínimos.
Limitaciones de rendimiento: La arquitectura basada en pilas y el modelo de ejecución secuencial limitan el rendimiento a aproximadamente 15-30 transacciones por segundo en la red principal de Ethereum.
Ecosistema de desarrolladores masivo: Solidity es el lenguaje de contratos inteligentes más conocido, con una amplia gama de herramientas (Hardhat, Foundry, Remix, OpenZeppelin) y recursos para desarrolladores.
Altos costos de gas: Las operaciones complejas en la red principal de Ethereum pueden costar cientos de dólares en tarifas de gas durante los períodos de mayor congestión, lo que deja fuera del alcance a los usuarios pequeños.
Seguridad probada en combate: Tras casi una década de uso en producción y miles de millones de dólares protegidos, la especificación principal de la EVM ha demostrado ser extraordinariamente sólida contra las vulnerabilidades directas.
Sobrecarga del tamaño de palabra de 256 bits: El tamaño de palabra nativo de 256 bits es excesivo para la mayoría de las operaciones, ya que desperdicia recursos en relleno y aumenta los costos de gas para cálculos simples.
Ejecución determinista: Resultados idénticos garantizados en todos los nodos, lo que permite la verificación sin necesidad de confianza y el consenso sin coordinación central.
Modelo de computación limitado: No ofrece soporte nativo para aritmética de punto flotante, paralelismo ni acceso a datos fuera de la cadena, lo que requiere soluciones alternativas para muchos casos de uso reales.
Especificación formal: El documento técnico de Gavin Wood proporciona una especificación matemática rigurosa, que permite múltiples implementaciones independientes (Geth, Nethermind, Besu, Erigon) que interoperan perfectamente.
Inmutabilidad de los contratos inteligentes: una vez implementado, el código de bytes no se puede cambiar; los errores se vuelven permanentes a menos que se utilicen patrones de proxy (que añaden complejidad y riesgo).
Componibilidad rica: la interfaz estandarizada de la EVM permite que los contratos interactúen entre sí sin problemas, lo que posibilita la componibilidad de "Lego de dinero" de DeFi.
Sobrecarga de almacenamiento: El almacenamiento de estado persistente crece indefinidamente. Los requisitos de almacenamiento de los nodos estándar completos son menores debido a la poda, pero los nodos de archivo especializados (que almacenan el historial completo del estado) pueden requerir un almacenamiento superior a 1 TB.
Capacidad de actualización mediante EIP: El conjunto de códigos de operación y el programa de gas se pueden actualizar mediante Propuestas de Mejora de Ethereum, lo que permite que la EVM evolucione sin romper los contratos existentes.
Superficie de vulnerabilidad de reentrada: La capacidad del código de operación CALL para transferir la ejecución a contratos externos crea una clase de errores de reentrada que siguen siendo el vector de explotación más común.
Gestión de riesgos
Riesgo de vulnerabilidad en contratos inteligentes
La EVM ejecuta fielmente código defectuoso: los ataques de reentrada, los desbordamientos de enteros (anteriores a Solidity 0.8) y los errores de control de acceso han provocado pérdidas multimillonarias.
Medidas de mitigación: exigir auditorías profesionales de empresas como Trail of Bits, OpenZeppelin o Certik antes del despliegue en la red principal; utilizar herramientas de verificación formal como Certora y K Framework.
Implemente el patrón de interacciones de efectos y comprobaciones y utilice ReentrancyGuard de OpenZeppelin para todas las llamadas externas.
Riesgo de volatilidad del precio del gas
La congestión repentina de la red puede disparar los precios del gas de 10 gwei a más de 500 gwei, lo que hace que las interacciones contractuales sean prohibitivamente caras.
Mitigación: implementar oráculos de precios de gas y parámetros de precio máximo de gas en las interfaces de usuario de las dApps; utilizar soluciones de capa 2 (Arbitrum, Optimism, Base) para operaciones sensibles al costo.
Considere las transacciones de blobs EIP-4844 para operaciones de agregación con gran cantidad de datos.
Riesgo de compatibilidad entre cadenas
Las cadenas compatibles con EVM pueden implementar diferencias sutiles en el comportamiento del código de operación, la disponibilidad de precompilación o la programación del gas.
Mitigación: pruebe los contratos en la red de prueba de cada cadena objetivo; tenga cuidado con los códigos de operación específicos de la cadena como CHAINID y BASEFEE; mantener configuraciones de despliegue por cadena
Exceso de gasto estatal y riesgo para la sostenibilidad
Cada despliegue de contrato y escritura de almacenamiento aumenta permanentemente el estado global, elevando los requisitos de hardware para los nodos completos.
Medidas de mitigación: minimizar el uso de almacenamiento mediante un empaquetado de datos eficiente (múltiples valores por ranura de 32 bytes); apoyar la investigación sobre Ethereum sin estado y propuestas de caducidad de estado (EIP-4444).
Relevancia cultural
La EVM se ha convertido en el estándar de referencia de la era de los contratos inteligentes, estableciendo las decisiones arquitectónicas de Ethereum como la lengua franca de la computación descentralizada. La frase "compatible con EVM" ha evolucionado de una especificación técnica a una palabra de moda en el marketing: los nuevos proyectos de blockchain suelen anunciar la compatibilidad con EVM como una característica fundamental, reconociendo que el acceso al ecosistema de desarrolladores de Ethereum y a las bibliotecas de contratos inteligentes existentes es esencial para su adopción.
El lenguaje de programación Solidity, que se compila a código de bytes EVM, ha creado toda una categoría profesional de "desarrolladores Solidity" que perciben salarios elevados en la industria tecnológica. Cursos intensivos, programas universitarios y plataformas en línea como CryptoZombies han formado a un gran número de desarrolladores específicamente para el desarrollo basado en EVM.
El mecanismo de gas de la EVM se ha arraigado en la cultura cripto. Frases como "guerras de gas", "optimización de gas" y "sin gas" se han convertido en parte del vocabulario cotidiano de las comunidades cripto. La frustración por las transacciones fallidas debido a la falta de gas ha generado innumerables memes, y la búsqueda de tarifas de gas más bajas ha impulsado toda la narrativa sobre la escalabilidad de la capa 2.
En la comunidad de desarrolladores, la distinción entre «equivalencia EVM» y «compatibilidad EVM» se ha vuelto crucial. Proyectos como OP Stack de Optimism buscan la equivalencia total (comportamiento idéntico de los códigos de operación), mientras que otros se conforman con la compatibilidad (el mismo código Solidity se compila y despliega, pero con pequeñas diferencias de comportamiento). Esta distinción es fundamental para la seguridad y la componibilidad, y se ha convertido en un criterio de evaluación clave para las decisiones de infraestructura.
Ejemplos del mundo real
Implementación multicadena de Uniswap
Escenario: Uniswap, el mayor exchange descentralizado por volumen, necesitaba expandirse más allá de la red principal de Ethereum para dar servicio a los usuarios que no podían acceder al servicio debido a las altas tarifas de gas.
Implementación: Dado que los contratos inteligentes de Uniswap se escribieron en Solidity para la EVM, el protocolo se implementó en Polygon, Arbitrum, Optimism, BSC, Base, Avalanche y Celo con mínimas modificaciones en los contratos. La misma lógica central del AMM (fórmula de producto constante) funciona de forma idéntica en todas las cadenas compatibles con la EVM.
Resultado: Uniswap procesa un volumen de operaciones diario considerable en múltiples cadenas EVM. Los usuarios de Arbitrum y Polygon suelen pagar fracciones de centavo por intercambio, en comparación con los varios dólares que se pagan en la red principal de Ethereum durante los períodos de congestión, mientras que el modelo de seguridad del protocolo permanece fundamentalmente idéntico en todas las implementaciones.
El hackeo de DAO y la reentrada de EVM
Escenario: En junio de 2016, un atacante explotó una vulnerabilidad de reentrada en el contrato inteligente de The DAO, que estaba implementado en la EVM. La función de retiro del contrato enviaba ETH antes de actualizar el saldo del usuario, lo que permitía al atacante llamar recursivamente a la función de retiro antes de que el saldo se estableciera a cero.
Implementación: El atacante creó un contrato malicioso que, al recibir ETH a través de la EVM, CALL El código de operación llamaba inmediatamente a la función de retiro de The DAO. La EVM ejecutaba diligentemente cada llamada recursiva, extrayendo aproximadamente 3.6 millones de ETH (unos 60 millones de dólares en ese momento).
Resultado: La comunidad de Ethereum llevó a cabo una bifurcación dura (hard fork) controvertida para revertir el robo, creando Ethereum (ETH) y Ethereum Classic (ETC). El incidente se convirtió en el caso de estudio definitivo para la seguridad de la EVM, lo que impulsó el desarrollo de mecanismos de protección contra la reentrada, el patrón de comprobaciones, efectos e interacciones, y prácticas de auditoría detalladas que definen la industria en la actualidad.
Aave en Arbitrum a través de la equivalencia EVM
Escenario: Aave, un protocolo líder de préstamos DeFi con un valor total bloqueado sustancial, buscaba implementarse en Arbitrum para ofrecer a los usuarios préstamos y empréstitos a menor costo.
Implementación: La actualización Nitro de Arbitrum logró una equivalencia casi completa con la EVM, lo que significa que el complejo sistema multicontrato de Aave (que incluye préstamos flash, lógica de tasa variable/estable y módulos de gobernanza) pudo implementarse sin modificaciones. El mismo código fuente Solidity, compilado al mismo código de bytes de la EVM, se ejecuta en el entorno de ejecución de agregación optimista de Arbitrum.
Resultado: Aave en Arbitrum se convirtió en uno de los despliegues DeFi más grandes en cualquier capa 2, con costos de gas reducidos en aproximadamente un 90-95% en comparación con la red principal de Ethereum. El despliegue sin contratiempos demostró el potencial de la equivalencia de EVM para migraciones de protocolos complejos.
Guerras de gas de acuñación de NFT
Escenario: Durante lanzamientos de NFT de gran repercusión, como el de Otherside Mint de Yuga Labs (30 de abril de 2022), miles de usuarios intentaron simultáneamente ejecutar transacciones EVM para acuñar NFT, lo que generó una competencia extrema por el gas.
Implementación: Los usuarios fijaron precios de gas cada vez más altos para asegurar que sus transacciones de acuñación se incluyeran en el siguiente bloque, y algunos informes indican que los costos del gas alcanzaron aproximadamente entre 2 y 2.5 ETH por acuñación en su punto máximo. La EVM procesó cada llamada de acuñación secuencialmente dentro de cada bloque, y los constructores de bloques ordenaron las transacciones según el precio del gas.
Resultado: La casa de moneda Otherside gastó más de 150 millones de dólares en comisiones de gas de ETH en aproximadamente 24 horas (las estimaciones de diversas fuentes oscilan entre los 150 y los 176 millones de dólares), lo que demuestra tanto la robustez de la EVM bajo cargas extremas como sus limitaciones fundamentales de rendimiento. Este evento aceleró la adopción de soluciones de capa 2 basadas en EVM para futuros lanzamientos de NFT.
Tabla de comparación
Elemento
EVM (Ethereum)
Máquina virtual Solana (SVM)
CosmWasm (Cosmos)
Mover máquina virtual (Aptos/Sui)
Arquitectura de interiores
Palabra de 256 bits basada en pila
Código de bytes BPF basado en registros
Basado en WebAssembly
Basado en registros y orientado a recursos.
Idioma primario
Solidez, Vyper
Óxido, C
Herrumbre
Moverse
Modelo de ejecución
Secuencial por bloque
Paralelo (Nivel del mar)
Secuencial por bloque
Paralelo (centrado en objetos)
Modelo de gas/tarifa
Gasolina con tarifa base + tarifa de prioridad
Calcular unidades + tarifa de prioridad
Gas con precios configurables
Unidades de gas con descuentos por almacenamiento
Adopción entre cadenas
Más de 50 cadenas (BSC, Polígono, Arbitrum, etc.)
Están surgiendo cadenas compatibles con SVM
Cadenas conectadas mediante IBC (50+)
Limitado (Aptos, Sui, Movement)
Ecosistema de desarrollador
Las más grandes (Hardhat, Foundry, OpenZeppelin)
Crecimiento (Marco de anclaje)
Moderado (herramientas de CosmoWasm)
Emergente (Probador de movimientos)
Verificación formal
Especificación del Libro Amarillo; K-EVM
Herramientas formales limitadas
Moderado (comprobación de CosmoWasm)
Probador de movimientos (integrado)
Términos relacionados
Solidez – El lenguaje de programación de alto nivel más utilizado para escribir contratos inteligentes EVM, que incluye tipado estático, herencia y una amplia biblioteca estándar.
Gas (Ethereum) – La unidad de esfuerzo computacional requerida para ejecutar operaciones en la EVM, pagada por los remitentes de transacciones para compensar a los validadores por procesar sus transacciones.
Contrato Inteligente – Programas autoejecutables almacenados en la cadena de bloques y ejecutados por la EVM, que contienen la lógica de negocio para aplicaciones descentralizadas.
Código de bytes: el código máquina de bajo nivel compilado a partir de Solidity o Vyper que la EVM ejecuta directamente, que consiste en secuencias de códigos de operación y sus argumentos.
Cadena compatible con EVM: cualquier blockchain que implemente la especificación EVM, lo que permite desplegar y ejecutar contratos inteligentes Solidity sin modificaciones.
Resumen de capa 2 – Soluciones de escalabilidad como Arbitrum y Optimism que ejecutan transacciones EVM fuera de la cadena y envían pruebas o datos comprimidos de vuelta a Ethereum por motivos de seguridad.
Papel amarillo Ethereum – La especificación matemática formal de Gavin Wood del EVM, que define cada código de operación, coste de gas y regla de transición de estado.
ABI (Interfaz Binaria de Aplicación): el formato de codificación estándar para llamar a las funciones de los contratos inteligentes de EVM y decodificar sus valores de retorno, lo que permite la interoperabilidad entre contratos y front-ends.
EIP-1559: la propuesta de mejora de Ethereum que reformó el mercado de tarifas de gas de la EVM mediante la introducción de una tarifa base quemada y un mecanismo opcional de propina prioritaria.
Contrato de representación – Un patrón de diseño que utiliza el código de operación DELEGATECALL de la EVM para crear contratos inteligentes actualizables separando el almacenamiento de la lógica.
Códigos de operación: el conjunto fundamental de instrucciones de la EVM, cada una de las cuales realiza una única operación atómica, como una suma, un acceso al almacenamiento o una llamada a un contrato.
Trie de estado: la estructura de datos Trie de Merkle Patricia que almacena el estado global (saldos de cuentas, almacenamiento de contratos, código de bytes) al que accede la EVM durante la ejecución.
Preguntas Frecuentes
P: ¿Qué significa “compatible con EVM” y por qué es importante? A: La compatibilidad con EVM significa que una cadena de bloques implementa la misma especificación de máquina virtual que Ethereum, lo que permite desplegar contratos inteligentes escritos en Solidity sin modificaciones. Esto es importante porque brinda a las nuevas cadenas acceso instantáneo al enorme ecosistema de herramientas para desarrolladores de Ethereum (Hardhat, Foundry, Remix), bibliotecas de contratos auditadas (OpenZeppelin) y bases de código de dApps existentes. Cadenas como BSC, Polygon, Avalanche C-Chain, Arbitrum y Optimism son compatibles con EVM, por lo que los mismos protocolos (Uniswap, Aave, SushiSwap) pueden funcionar en todas ellas.
P: ¿Por qué la máquina de votación electrónica utiliza gas en lugar de cobrar tarifas fijas? A: El gas existe porque las distintas operaciones consumen cantidades muy diferentes de recursos computacionales. Una simple suma requiere un esfuerzo mínimo, mientras que escribir en un almacenamiento persistente requiere operaciones de entrada/salida de disco en miles de nodos a nivel global. El gas asigna un precio a cada operación proporcional a su coste real en recursos, lo que impide que los atacantes saturen la red con cálculos costosos a bajo coste. El mecanismo de gas también proporciona una garantía de parada natural: incluso si un contrato contiene un bucle infinito, eventualmente se quedará sin gas y se detendrá, protegiendo así la red de ataques de denegación de servicio.
P: ¿Qué sucede cuando un contrato inteligente se queda sin gas durante la ejecución de la EVM? A: Cuando se agota el gas durante la ejecución, la EVM se detiene inmediatamente y revierte todos los cambios de estado realizados durante la transacción: las escrituras en el almacenamiento, las transferencias de saldo y la creación de contratos se deshacen como si la transacción nunca hubiera ocurrido. Sin embargo, la tarifa de gas se consume y se paga al validador del bloque, ya que el trabajo computacional ya se realizó. Por eso es importante establecer un límite de gas adecuado: si es demasiado bajo, la transacción falla (desperdiciando el gas); si es demasiado alto, se corre el riesgo de pagar de más si la operación finaliza antes de tiempo (aunque el gas no utilizado se reembolsa).
P: ¿En qué se diferencia la EVM del procesador de un ordenador convencional? A: A diferencia de una CPU física, la EVM es una máquina virtual: un software que simula un ordenador. Las principales diferencias son: (1) la EVM es completamente determinista, lo que significa que produce resultados idénticos en todas las máquinas, mientras que las CPU físicas pueden tener comportamientos no deterministas; (2) la EVM cobra por cada operación mediante gas, mientras que las CPU procesan instrucciones a la velocidad del hardware; (3) la EVM tiene almacenamiento persistente en la cadena de bloques, mientras que la memoria de la CPU es volátil; (4) la EVM se ejecuta de forma idéntica en miles de nodos simultáneamente, mientras que una CPU se ejecuta en una sola máquina. Piénselo como un ordenador deliberadamente lento y costoso, diseñado para el consenso global sin necesidad de confianza, en lugar de para el rendimiento.
P: ¿Se pueden actualizar o corregir los contratos inteligentes de EVM después de su implementación? R: Directamente, no. El código de bytes de EVM es inmutable una vez implementado. Sin embargo, el patrón de proxy (que utiliza el código de operación DELEGATECALL) permite a los desarrolladores crear contratos actualizables. Un contrato proxy almacena el estado y delega la ejecución a un contrato de implementación que contiene la lógica. Para actualizar, los desarrolladores implementan un nuevo contrato de implementación y actualizan el proxy para que apunte a él. Este patrón lo utilizan la mayoría de los principales protocolos DeFi, pero introduce riesgos de gobernanza y centralización (quien controla la actualización del proxy puede cambiar el comportamiento del contrato). Los proxies transparentes (EIP-1967) y los proxies UUPS son las implementaciones más comunes.
P: ¿Cuál es la diferencia entre equivalencia EVM y compatibilidad EVM? A: La compatibilidad con EVM significa que una cadena puede ejecutar contratos inteligentes Solidity, pero puede haber diferencias sutiles en el comportamiento del código de operación, los costos de gas o la disponibilidad de precompilación. La equivalencia con EVM significa que la cadena implementa la especificación EVM de forma idéntica, código de operación por código de operación, de modo que incluso el código de bytes de bajo nivel y las herramientas de depuración funcionan exactamente igual que en Ethereum. La actualización Bedrock de Optimism y Arbitrum Nitro buscan la equivalencia con EVM, mientras que cadenas más antiguas como BSC son compatibles con EVM pero no totalmente equivalentes. La equivalencia es importante para contratos complejos que dependen de costos de gas o comportamientos de código de operación específicos.
P: ¿Se sustituirá finalmente la máquina de evaluación de emisiones (EVM)? A: Existen propuestas e investigaciones activas sobre tecnologías sucesoras de EVM, incluyendo eWASM (WebAssembly con sabor a Ethereum), RISC-V y la ruta de actualización EOF (EVM Object Format). Sin embargo, reemplazar EVM plantea un enorme desafío de retrocompatibilidad: miles de millones de dólares en contratos inteligentes están implementados como código de bytes de EVM, y cualquier reemplazo debe ser compatible con los contratos existentes o proporcionar una ruta de migración fluida. La evolución más probable a corto plazo es la serie de actualizaciones EOF, que moderniza el formato de código de bytes de EVM manteniendo la compatibilidad. Un reemplazo completo, de producirse, probablemente tardaría años y requeriría la coexistencia con la EVM actual durante un período de transición prolongado.
Los préstamos respaldados por Bitcoin están entrando en lo que Silicon Valley Bank describe como un nuevo capítulo institucional, con estándares de préstamo más estrictos y en constante crecimiento.
La Unión Europea está reevaluando su emblemática regulación de criptomonedas tan solo tres años después de la entrada en vigor del marco de Mercados de Criptoactivos (MiCA).
