¿Qué es la EVM?

La Ethereum Virtual Machine (EVM), la máquina virtual de Ethereum, es un conjunto de reglas comunes para ejecutar contratos inteligentes. Los nodos de Ethereum implementan esas reglas en su propio software, calculan a partir de las mismas transacciones y del mismo estado inicial, y así obtienen un resultado que otros nodos pueden volver a revisar.

La EVM no es un servidor físico determinado, ni la única aplicación que una persona que desarrolla ve en su computadora. Se parece más a un instructivo de cálculo preciso: qué operaciones básicas puede ejecutar el código, dónde se colocan los datos, cuántos recursos de cómputo consume cada operación, y cómo se actualiza el estado de la blockchain cuando la ejecución tiene éxito o falla.

Del código fuente al bytecode ejecutable

Quienes desarrollan normalmente escriben contratos en un lenguaje de alto nivel como Solidity. El código fuente legible por personas necesita que un compilador lo convierta en bytecode que la EVM pueda ejecutar, es decir, una serie de instrucciones de máquina ordenadas en un formato fijo.

Al desplegar un contrato, la transacción de creación contiene el código que sirve para generarlo. Tras una ejecución exitosa, la red establece una dirección para el contrato y guarda el bytecode que se ejecutará cuando después reciba llamadas. El código de ejecución de un contrato ya desplegado no es la misma representación que los archivos fuente de quien desarrolla, así que un código fuente publicado todavía debe contrastarse con el bytecode en cadena antes de poder afirmar que ambos se corresponden.

La versión y la configuración del compilador pueden influir en el bytecode final. Dos archivos fuente de apariencia parecida pueden producir resultados distintos; ver el mismo nombre de contrato sustituye aún menos la revisión de la red y de la dirección del contrato.

La llamada aporta al contrato sus datos de ejecución

Cuando alguien llama a un contrato, envía a la dirección del contrato una transacción con datos. Esos datos normalmente indican a qué función se llama y adjuntan los parámetros en un formato convenido. Un contrato también puede llamar a otro contrato durante la ejecución, y pasar valores o datos más adelante.

La EVM parte del estado actual de la blockchain, lee quién llama, el destino, el valor adjunto, los datos de entrada y la información que el bloque actual permite usar, y después ejecuta instrucción por instrucción el bytecode del contrato de destino. Cada instrucción modifica, según las reglas, los datos temporales de este cálculo, o pide leer o escribir el estado persistente del contrato.

Un contrato no se inicia por su cuenta solo porque llegó cierto momento. Hace falta que una transacción o la llamada de otro contrato forme un punto de entrada de ejecución; una «ejecución automática» que aparece en una página web normalmente todavía requiere que algún servicio externo envíe una transacción cuando se cumplen las condiciones.

Los opcodes son las acciones básicas del bytecode

El bytecode de la EVM está compuesto por opcodes sucesivos. Un opcode se puede entender como la acción más pequeña que la máquina virtual reconoce: por ejemplo hacer aritmética, comparar valores, leer datos de la llamada, leer o escribir el almacenamiento, y llamar a otros contratos.

Los distintos opcodes tienen reglas definidas de entrada, de salida y de consumo de gas. Un nodo no necesita entender los nombres de negocio de un contrato: ejecutar en el orden de los opcodes alcanza para revisar si el resultado que dio otro nodo cumple el protocolo.

Una sola línea de un lenguaje de alto nivel puede compilarse en varios opcodes. A la inversa, mirar un opcode aislado no permite entender una intención de negocio completa, así que revisar un contrato normalmente implica además combinar código fuente, configuración de compilación, datos de la llamada y la dirección de despliegue real.

Datos temporales y estado persistente

No todos los datos que se usan durante la ejecución quedan escritos de forma permanente en la blockchain. Conviene distinguir primero tres ubicaciones:

• los datos de la llamada son la entrada de solo lectura que trae esta llamada;
• la memoria es un espacio de trabajo temporal que se usa durante esta ejecución y no se conserva al terminar;
• el almacenamiento pertenece a un contrato concreto y, una vez escrito con éxito, pasa a ser parte del estado de la blockchain para que llamadas posteriores lo lean.

La EVM además usa una estructura de cálculo temporal del tipo último en entrar, primero en salir, llamada pila. Los opcodes toman valores de la cima de la pila y vuelven a colocar el resultado después de calcular. Quien lee sin ser especialista no tiene que seguir cada paso a mano, pero sí necesita saber que «un cambio en memoria» y «el almacenamiento del contrato ya cambió» no son lo mismo.

Escribir en el almacenamiento persistente normalmente consume más gas que hacer solo un cálculo temporal. Borrar o cambiar el almacenamiento también está sujeto a las reglas del protocolo: el estado en cadena no es un archivo local que un programa común pueda sobrescribir a voluntad.

Los cambios de estado deben poder recalcularse

Las transacciones de un mismo bloque tienen un orden determinado. Partiendo del mismo estado previo al bloque y ejecutando en orden las mismas transacciones, los nodos deberían obtener el mismo estado posterior al bloque; si no, no pueden ponerse de acuerdo sobre un libro contable común.

Por eso un contrato de la EVM no puede, al ejecutarse, acceder directamente a cualquier página web, a la hora de un dispositivo o al resultado aleatorio de algún servidor. Cuando hace falta un precio, un dato del clima u otra información fuera de la cadena, una parte externa debe primero llevar ese dato a la cadena en forma de transacción. La EVM puede revisar cómo el código usa esa entrada, pero no puede probar automáticamente que el hecho fuera de la cadena correspondiente sea verdadero.

La información que aporta el bloque, como la hora o el número de bloque, también viene del entorno de ejecución que define el protocolo. Quienes desarrollan pueden leerla según las reglas, pero no deberían confundir esos valores con un reloj externo preciso ni con una fuente secreta de aleatoriedad ajena al proceso de propuesta de bloques.

El gas limita la carga de trabajo de cada ejecución

Cada operación de la EVM consume cierta cantidad de gas. El gas es una unidad de medida del trabajo de cómputo y de almacenamiento, no un token aparte; en la red principal de Ethereum, las comisiones de ejecución reales normalmente se pagan con el activo nativo de la red, ETH.

Quien envía una transacción fija el gas máximo que esa transacción puede consumir. Durante la ejecución, la EVM acumula gas según las operaciones realmente realizadas; si el gas restante no alcanza para completar el paso siguiente, la ejecución falla por agotamiento de gas.

El gas evita que bucles infinitos o llamadas anormalmente complejas ocupen sin costo los recursos de cómputo de todos los nodos. También implica que una misma función pueda consumir cantidades distintas según la entrada, el estado actual y el camino de ejecución. Una transacción de monto alto no necesariamente ejecuta más código que una de monto bajo.

Éxito, reversión y falla

Un contrato puede terminar con normalidad y devolver datos, puede revertir por decisión propia, o puede fallar por una operación inválida, por agotamiento de gas u otra causa. Al fallar, las modificaciones de estado que aún no se confirmaron en ese camino de llamada se revierten según las reglas, pero los recursos de cómputo que la transacción ya consumió todavía pueden generar comisión.

Una transacción puede desencadenar varios niveles de llamadas a contratos. Si una llamada interna falla, el contrato externo puede, según su código, elegir seguir procesando el resultado devuelto, o hacer que toda la transacción revierta. Por eso «algún paso interno falló» y «toda la transacción finalmente falló» se deben juzgar junto con los resultados de las llamadas.

Una reversión de estado tampoco deshace el hecho de que una transacción quedó incluida en un bloque. Un explorador de bloques puede mostrar una transacción fallida y el gas consumido; lo único que no surtió efecto son las modificaciones de estado esperadas del contrato.

Leer resultados y enviar transacciones

Una billetera o aplicación puede hacer que un nodo simule localmente una solicitud de solo lectura y devuelva el resultado de inmediato. Ese tipo de lectura no alcanza un nuevo consenso de toda la red ni modifica el estado en cadena, así que normalmente no requiere que la persona firme y pague una comisión en cadena.

En cambio, una operación que necesita cambiar el estado debe formar una transacción, ser firmada por una cuenta y difundirse, y luego ser ejecutada en conjunto por los nodos una vez que entra en un bloque. Simular antes de enviar puede ayudar a detectar fallas evidentes, pero el resultado final todavía puede verse afectado por el ordenamiento de transacciones, los cambios de estado, la configuración de gas y la red elegida.

Por eso, que la interfaz de una aplicación muestre «se espera que tenga éxito» no equivale a que la transacción ya esté confirmada. El resultado real en cadena requiere consultar, en la red correcta, el estado de la transacción, el resultado de ejecución y el estado del contrato.

La EVM y Ethereum no son el mismo concepto

La EVM solo describe parte de las reglas de ejecución de contratos inteligentes y de transición de estado. Ethereum también incluye los formatos de cuentas y transacciones, la propagación de bloques, el consenso por prueba de participación, la comunicación de red y otros componentes del protocolo.

Otras blockchains también pueden implementar la EVM o un entorno de ejecución muy parecido, para reutilizar herramientas de contratos y bytecode. Normalmente se las llama redes compatibles con la EVM, pero siguen teniendo su propio historial de bloques, sus propios arreglos de validación, su activo para comisiones y su frontera de seguridad.

Así, «poder ejecutar contratos de la EVM» no indica que algo sea Ethereum, ni garantiza que la misma dirección tenga desplegado el mismo código en redes distintas. Al usar una aplicación en varias redes, igual hay que revisar la red y su número de red, la dirección del contrato y el bytecode real.

La ejecución común no equivale a que un contrato sea seguro

Las reglas deterministas de la EVM permiten que los nodos vuelvan a revisar si un contrato se ejecutó conforme a su código, pero no permiten juzgar si ese código coincide con el resultado de negocio que la persona realmente quería. Permisos equivocados, un contrato externo que vuelve a llamar de forma repetida antes de que termine una operación anterior, problemas con las entradas de precio, el control de actualizaciones o una interfaz que induce a error pueden hacer, cada uno, que una transacción totalmente conforme a las reglas de la EVM produzca una consecuencia inesperada.

Una compilación exitosa, una ejecución exitosa en cadena o un código fuente publicado tampoco sustituyen, cada uno por su lado, una auditoría de seguridad. Juzgar un contrato concreto exige combinar el bytecode desplegado, el estado de inicialización, los permisos de administración, las dependencias externas y el camino de llamada real.

Preguntas frecuentes

¿La EVM es un servidor en la nube?

No. Es un conjunto de reglas de ejecución que el software de los nodos implementa en conjunto, y no corresponde a ninguna máquina fija en particular.

¿La EVM ejecuta directamente el código Solidity?

Normalmente no. El código fuente de Solidity primero lo convierte un compilador en bytecode de la EVM, y lo que los nodos ejecutan es el bytecode desplegado.

¿Leer un contrato siempre requiere pagar comisión de gas?

Una solicitud local de solo lectura normalmente no forma una transacción en cadena, así que no genera directamente una comisión en cadena. Si la lectura es parte de la ejecución de otra transacción que sí va a la cadena, las operaciones correspondientes igual se cuentan en el gas de esa transacción.

¿La EVM puede leer datos de internet directamente?

No. Los datos externos deben ser llevados a la cadena por algún participante o servicio mediante una transacción; la EVM solo puede procesar, según las reglas, una entrada ya provista.

¿Ser compatible con la EVM significa que un contrato se puede migrar sin modificaciones?

No está garantizado. El grado de compatibilidad, la versión del protocolo, los opcodes disponibles, las reglas de comisiones, los contratos de sistema y las dependencias externas pueden ser distintos, así que igual hace falta verificar y probar en la red de destino.

Conceptos relacionados

Continúa con Ethereum, contrato inteligente, comisión de gas y blockchain, o vuelve al glosario de criptomonedas.

Fuentes

• Ethereum.org: Ethereum Virtual Machine — la EVM, las transiciones de estado, el entorno de ejecución, la pila, la memoria y el almacenamiento.
• Ethereum.org: estructura de un contrato inteligente — código fuente, compilación, código desplegado y estructura de las llamadas a contratos.
• Ethereum.org: opcodes de la EVM — opcodes, parámetros y reglas de gas.
• Ethereum.org: gas y comisiones — medición del gas, límite de gas, comisiones de ejecución y consecuencia de agotar el gas.