La máquina virtual de Ethereum, o EVM por sus siglas en inglés, es el entorno de ejecución de los contratos inteligentes de Ethereum. Para comprender su función, conviene seguir tres ideas conectadas: el contrato contiene bytecode compilado, la EVM ejecuta ese código mediante instrucciones y el estado de Ethereum cambia conforme a unas reglas definidas. El gas mide el trabajo computacional y limita cuánto puede consumir una transacción.
Este enfoque permite entender la ejecución sin convertirla en una promesa de que la aplicación conseguirá el resultado esperado. Las preguntas útiles son: ¿qué código se ejecuta?, ¿qué información almacenada interviene? y ¿qué ocurre si se agota el presupuesto de ejecución?
Qué ejecuta la máquina virtual de Ethereum
El punto de partida es distinguir el programa de su entorno de ejecución. Un contrato inteligente aporta el código; la EVM establece las reglas para ejecutarlo. La documentación de Ethereum sobre la EVM describe cuentas de contrato que contienen bytecode compilado. Cuando otra cuenta realiza una llamada al contrato, se ejecuta ese bytecode.
El bytecode es la forma compilada del programa del contrato. Se ejecuta mediante instrucciones de la EVM llamadas opcodes, o códigos de operación. Puedes entender el bytecode como el programa codificado y los opcodes como las instrucciones individuales con las que realiza su trabajo. Comprender esta relación resulta más útil al empezar que memorizar una lista de instrucciones.
Al leer una explicación de un contrato, separa su propósito, expresado en lenguaje corriente, del código compilado que se ejecuta. Decir que un contrato pretende registrar un valor explica su finalidad. Describir las instrucciones ejecutadas y el valor que queda almacenado explica su comportamiento.
La EVM no es una cartera ni el algoritmo de consenso de Ethereum. Su función en esta explicación es ejecutar contratos. Por eso, afirmar que la EVM ha procesado una operación no basta para establecer todo lo ocurrido alrededor de una interacción con una aplicación.
Las transiciones de estado siguen unas reglas
El estado de Ethereum incluye cuentas, saldos y almacenamiento de contratos. La EVM define las reglas para modificarlo. La documentación expresa esta relación como Y(S, T) = S': un estado previo válido, junto con transacciones válidas, produce un estado resultante válido conforme a las reglas de transición.
La fórmula relaciona entradas, reglas y resultados. El estado previo aporta la información inicial; las transacciones aportan instrucciones que procesar; las reglas determinan el estado resultante. Mirar únicamente el propósito declarado del contrato deja fuera ese contexto de partida.
La documentación describe la función de transición como determinista: el resultado se deriva de sus entradas conforme a las reglas definidas. Determinista no significa que el éxito de la aplicación esté garantizado. Poder reproducir un resultado y satisfacer el objetivo de una persona son cuestiones diferentes.
De dos premisas documentadas se deduce un límite concreto: las transiciones siguen las reglas del protocolo y una ejecución puede agotar su gas y ver revertidos sus cambios. Por tanto, una transición de estado válida no garantiza que una llamada al contrato logre el resultado pretendido. Es una deducción de esas premisas, no una promesa adicional contenida en la fórmula.
El almacenamiento del contrato forma parte del estado
El almacenamiento persistente de un contrato está asociado a su cuenta y forma parte del estado global de Ethereum. Conceptualmente, permite conservar información en lugar de limitarse a calcular resultados intermedios.
La distinción fundamental es entre ejecutar instrucciones y establecer una actualización persistente. Si una explicación menciona una operación de escritura, todavía debe determinar si la actualización prevista llegó a hacerse efectiva. El intento de actualizar un dato no basta para acreditar su valor resultante.
Tampoco debe confundirse el almacenamiento persistente con todos los datos utilizados durante la ejecución. Por ejemplo, la memoria temporal de ejecución de la EVM no persiste entre transacciones. No hace falta conocer la estructura interna del almacenamiento para plantear la pregunta práctica: ¿qué información pertenece al estado persistente del contrato y qué pruebas acreditan su valor resultante?
El gas mide el trabajo y acota su presupuesto
El gas mide el esfuerzo computacional necesario para ejecutar operaciones en Ethereum. El límite de gas de una transacción establece el presupuesto máximo de gas suministrado para ella. El gas es la unidad de medida; el límite acota el presupuesto disponible.
La documentación calcula la comisión a partir del gas consumido y de un coste por unidad. De esa relación y de la definición del límite se deduce que el presupuesto de gas y el precio por unidad son magnitudes distintas. Aquí interesa el presupuesto computacional, sin entrar en cálculos de comisiones ni precios de opcodes. Disponer de un presupuesto tampoco garantiza el resultado solicitado.
Gas intrínseco insuficiente: rechazo durante la validación
La documentación de Ethereum sobre gas distingue entre no disponer del gas intrínseco suficiente para superar la validación y agotar el gas durante la ejecución. En el primer caso, la transacción se rechaza antes de incluirse en un bloque y no consume gas.
La fuente lo ilustra con una transferencia simple de ETH cuyo límite queda por debajo del requisito de validación. Su ejemplo numérico no debe generalizarse a cualquier operación de contrato. La diferencia relevante es que el rechazo se produce antes de que prosiga la ejecución.
Agotamiento del gas una vez iniciada la ejecución
En el caso descrito por la fuente, donde la transacción agota su gas durante la ejecución, la EVM revierte los cambios de esa ejecución y consume todo el gas suministrado por el trabajo realizado.
Esta afirmación tiene un alcance concreto: el agotamiento del gas de la transacción durante la ejecución. No describe todos los fallos posibles ni establece cómo se tratan los fallos de llamadas internas individuales.
Ejemplo hipotético de un contador almacenado
Ejemplo hipotético: un contrato de un ejercicio de clase tiene un contador con valor 7 en su almacenamiento persistente. La operación prevista consiste en aumentarlo a 8. Tanto el contrato como estos valores son inventados para explicar el concepto.
- Identifica el programa: el contrato contiene bytecode compilado que se ejecuta mediante opcodes de la EVM cuando recibe una llamada.
- Identifica el estado inicial: el contador parte de 7 en el almacenamiento persistente.
- Identifica el resultado esperado: el ejercicio pretende obtener un contador con valor 8.
- Considera el presupuesto: si la transacción agota su gas durante la ejecución, sus cambios de ejecución se revierten y se consume todo el gas suministrado.
El ejemplo muestra por qué describir la actualización prevista resulta insuficiente. Hay que distinguir el valor inicial, la operación ejecutada y el valor finalmente almacenado. En la alternativa de agotamiento del gas, el mero inicio de la ejecución no acredita la actualización pretendida.
Ejecución y acuerdo de la red: qué comprobar
El cliente de ejecución de Ethereum ejecuta transacciones en la EVM. El cliente de consenso implementa el acuerdo mediante prueba de participación a partir de datos validados por el cliente de ejecución. La documentación sobre nodos y clientes establece esta distribución de responsabilidades.
La ejecución se ocupa de procesar instrucciones y estado; el consenso, del acuerdo de la red a partir de datos de ejecución validados. Puedes ampliar las funciones del software en la guía de nodos y clientes de Ethereum. Para las etapas de verificación, consulta cómo se verifica una transacción en Ethereum y qué demuestra.
Utiliza esta lista para evaluar una explicación de la EVM:
- Identifica el código compilado del contrato y la operación prevista.
- Precisa el estado inicial relevante y el almacenamiento persistente.
- Separa una transición conforme a las reglas de las pruebas del resultado pretendido.
- Distingue el presupuesto de gas del precio por unidad.
- Diferencia el rechazo por gas intrínseco insuficiente del agotamiento durante la ejecución.
- Mantén separadas la ejecución y el acuerdo de la red.
Estas preguntas ayudan a interpretar descripciones técnicas. Citar fuentes no demuestra, por sí solo, que un contrato concreto sea seguro.
Artículo educativo elaborado con ayuda de inteligencia artificial. El ejemplo es hipotético y sirve únicamente para explicar los conceptos.