EVM y criptografía para smart contracts

La Ethereum Virtual Machine (EVM) es el motor que ejecuta cada contrato inteligente en Ethereum, y entender cómo funciona junto con las primitivas criptográficas es lo que separa a un developer Web2 de uno que escribe código seguro en Web3. Si te dedicas a smart contracts, conocer la EVM no es opcional: los incentivos para explotar errores son altísimos.

Esta guía recorre el modelo de ejecución de la EVM, cómo Solidity se traduce a bytecode y qué primitivas criptográficas conviven en el ecosistema Ethereum.

Qué es la Ethereum Virtual Machine y por qué importa

Piensa en la EVM como una máquina física virtualizada: una caja negra a la que le das cuerda y procesa instrucciones de forma secuencial. No tiene nada de esotérico, es software con reglas muy particulares [9:35].

Cuando compilas un contrato en Solidity, el resultado es bytecode: una secuencia de bytes que la EVM lee uno por uno mediante un program counter. Cada par de caracteres hexadecimales representa un byte, y cada byte puede ser un opcode (operación) o un parámetro [11:00].

¿Qué es el bytecode en Ethereum? Es el código de bajo nivel resultado de compilar Solidity. Está formado por bytes donde cada uno corresponde a un opcode o un parámetro que la EVM ejecuta secuencialmente.

La analogía útil aquí es Java y la Java Virtual Machine: así como Java se traduce a JVM, Solidity se traduce a EVM. Tus usuarios no interactúan con tu código de Solidity, interactúan con el bytecode desplegado en la red [9:00].

Cómo funciona el modelo de ejecución de un smart contract

Toda llamada a un contrato ocurre dentro de un entorno de ejecución. Cuando envías una transacción desde MetaMask hacia un contrato, ese mensaje entra al contexto de ejecución del contrato y el program counter empieza a leer el código asociado a esa dirección [4:30].

Dentro del entorno de ejecución conviven varios componentes clave:

• El stack, donde la EVM coloca información temporal durante la ejecución.
• La memoria volátil, que se borra al terminar el contexto.
• El storage, que es no volátil y vive fuera del contexto de ejecución, por eso las variables persisten entre transacciones.
• El gas, que representa el costo computacional de cada operación.

Cada operación cuesta gas, igual que darle vueltas a una máquina física consume energía. Si ejecutas el mismo programa 100 veces, las 100 tendrán el mismo costo computacional, pero el precio en ETH varía según cuánto está dispuesto a pagar el usuario por unidad de cómputo [10:50].

Cómo se traducen las funciones de Solidity a la EVM

La EVM no entiende de funciones. Lo que hace Solidity es construir un switch basado en el selector de función, que son los primeros 4 bytes derivados del hash del nombre y los parámetros de la función. La EVM compara el selector entrante contra cada caso del switch y salta al bloque de código correspondiente [7:30].

¿Y si el selector no coincide con ninguna función? Ahí entra el fallback: una pieza de código por defecto que se ejecuta cuando no hay match. Esto puede ser una puerta a vulnerabilidades si el fallback permite ejecución de código arbitrario al recibir llamadas externas.

¿Qué es un selector de función en Solidity? Son los primeros 4 bytes del hash Keccak256 de la firma de la función. La EVM los usa para identificar qué función ejecutar al recibir una llamada.

Cómo se organizan storage, stack y memoria en la EVM

Cada slot de storage en la EVM mide 32 bytes. Solidity aprovecha estos espacios empaquetando variables: si tienes un address (20 bytes) seguido de un bool (1 byte) y un uint48 (6 bytes), todo cabe en un solo slot [13:20].

Entender este layout importa porque define el costo de gas de tus contratos y abre la puerta a trucos como acceder a variables private desde otro contrato leyendo directamente el storage slot.

La EVM también permite salir del entorno de ejecución mediante opcodes como call, delegatecall y staticcall. Cada uno tiene implicaciones distintas: delegatecall ejecuta código de otro contrato en el contexto del llamador, lo cual es poderoso pero peligroso si no entiendes qué storage estás tocando [14:30].

Qué primitivas criptográficas usa Ethereum

La palabra cripto en blockchain viene de criptografía, no de "encriptado". La blockchain es pública, no secreta; lo que usa son primitivas criptográficas para garantizar integridad y autenticación [16:40].

Estas primitivas se agrupan en cuatro categorías:

• Sin llave: funciones de hash como Keccak256 y generadores de números aleatorios.
• Con llave simétrica: cifrados donde la misma llave encripta y desencripta.
• Con llave asimétrica: firmas digitales y curvas elípticas, lo más usado en Ethereum.
• Pruebas: como zero knowledge proofs, que demuestran conocimiento sin revelar el dato.

Cómo funcionan las funciones de hash y las firmas digitales

Una función de hash es de una sola vía: tomas un input y obtienes un output determinista del que no puedes deducir el original. Keccak256 es la función estándar en Ethereum y sostiene desde la minería de Bitcoin hasta la verificación de datos en IPFS y los Merkle trees [19:00].

Las firmas digitales usan criptografía asimétrica con curvas elípticas. La analogía mental: tú das una caja fuerte que solo tú puedes abrir; quien quiera mandarte algo deposita el mensaje y lo cierra. En firmas, usas tu llave privada para firmar y cualquiera con tu llave pública verifica que fuiste tú [21:30].

¿Qué diferencia hay entre zk-SNARKs y zk-STARKs? Ambos son pruebas de conocimiento cero no interactivas. Los SNARKs requieren un trusted setup con un número aleatorio de un tercero; los STARKs son transparentes y no necesitan ese tercero, pero el tiempo de prueba es mayor.

Qué habilidades necesita un buen Solidity developer

Desarrollar contratos seguros depende de dos pilares: conocimiento profundo del lenguaje y de la EVM por un lado, y capacidad de analizar implicaciones criptográficas por el otro. No necesitas un máster en criptografía, pero sí saber qué garantías ofrece cada primitiva [8:50].

Un ejemplo concreto: si tu función store solo puede ser llamada por owner, su seguridad depende de la probabilidad de colisión de una address, que es de 1 entre 2^160. Pero si el owner es otro contrato, las asunciones cambian: ese contrato podría tener un multisig o lógica que degrade la seguridad original.

En matemáticas, lo recomendable es álgebra básica, factorización de polinomios y notación de matemáticas discretas, suficiente para leer la jerga del ecosistema sin perderte.

¿Te animas a resolver puzzles de EVM para practicar lo aprendido? Cuéntanos en los comentarios qué opcode te resultó más confuso al leer bytecode por primera vez.