La esencia de Ethereum es una máquina de estados basada en transacciones. En informática, una máquina de estados puede leer una serie de entradas y, en función de ellas, transformarse en un nuevo estado.
La máquina de estados de Ethereum parte de un estado génesis vacío (genesis state) y, a medida que las transacciones la impulsan, pasa de un estado a otro.
Cada estado de Ethereum contiene una gran cantidad de información sobre transacciones, que se agrupa en un bloque. Un bloque contiene una serie de transacciones y cada bloque está enlazado con el bloque anterior.
Para que una transacción se considere válida, debe incluirse en un bloque y la red debe llegar a un consenso sobre ella. Antes de «la Fusión» (The Merge), en septiembre de 2022, Ethereum utilizaba, al igual que Bitcoin, la prueba de trabajo (PoW), en la que los mineros competían mediante su potencia de cálculo para incluir bloques. Después de la Fusión, Ethereum pasó oficialmente a la prueba de participación (PoS).
Con el mecanismo PoS, los «mineros» que consumen potencia de cálculo desaparecen y son reemplazados por los validadores (Validator). Los validadores deben poner en staking 32 ethers (Ether) como garantía. Se les selecciona mediante un algoritmo seudorrandómico para proponer nuevos bloques, que luego son atestiguados (Attestation) por un comité formado por otros validadores. Si los validadores actúan honestamente, reciben ethers como recompensa; si se comportan de forma maliciosa o se desconectan, se les confisca parte de sus ethers en staking (Slashing).
1.2 Selección de bifurcaciones y mecanismo de consenso (Gasper)
Como se mencionó anteriormente, Ethereum es una máquina de estados compartida por nodos de todo el mundo, y su estado debe ser único. Tener múltiples estados (o múltiples cadenas) destruiría el sistema. Si la cadena se bifurcara, podrías tener 10 monedas en una cadena, 20 en otra y 40 en una tercera. En una situación así, sería imposible determinar cuál es la cadena más «válida».
Siempre que se generan varios caminos, aparece una «bifurcación». Por lo general, queremos evitar las bifurcaciones, porque perjudican al sistema y obligan a la gente a elegir en qué cadena confía.
En la era PoW, Ethereum utilizaba el protocolo GHOST (Greedy Heaviest Observed Subtree) para elegir el camino en el que se había realizado la mayor cantidad de trabajo computacional y evitar la aparición de múltiples cadenas. Tras «la Fusión» de 2022, la responsabilidad de decidir cuál es la cadena principal pasó a los validadores y Ethereum adoptó un mecanismo de consenso llamado Gasper.
Gasper combina dos componentes:
Regla de selección de bifurcaciones LMD-GHOST: los nodos siempre eligen como cadena principal la rama que cuenta con el mayor peso de votos de los validadores (es decir, la que tiene más participación en staking).
Mecanismo de finalidad Casper FFG: garantiza que, una vez que la red confirma definitivamente un bloque, este tiene una «finalidad absoluta» y no puede revertirse ni alterarse. De esta manera, se elimina el riesgo de reorganizaciones de la cadena que existía potencialmente en la antigua era PoW.
2 Cuentas
Una cuenta de Ethereum es una entidad que tiene un saldo de ether (ETH) y puede enviar transacciones en Ethereum. Puede estar controlada por un usuario o implementarse como un contrato inteligente.
Hay dos tipos de cuentas en Ethereum:
Cuenta externa: controlada por una clave privada y sin ningún código asociado.
Cuenta de contrato: controlada por el código de su contrato y con código asociado.
Ambos tipos de cuentas pueden recibir, mantener y enviar ETH y tokens, así como interactuar con contratos inteligentes desplegados.
Una cuenta externa puede enviar mensajes a otra cuenta externa o a una cuenta de contrato. Un mensaje transferido entre dos cuentas externas es una simple transferencia de valor. En cambio, un mensaje enviado desde una cuenta externa a una cuenta de contrato activa el código de esta última y le permite realizar distintas acciones (como transferir tokens, escribir en el almacenamiento interno, acuñar un token, realizar cálculos, crear otro contrato, etc.). Una cuenta de contrato no puede iniciar una transacción por sí sola. Por lo tanto, cualquier acción en Ethereum siempre se inicia mediante una transacción activada por una cuenta externa.
Las cuentas de Ethereum tienen cuatro campos:
nonce: contador que indica el número de transacciones enviadas desde la cuenta, lo que garantiza que cada transacción se procese una sola vez. En una cuenta de contrato, este número representa la cantidad de contratos creados por esa cuenta.
balance: cantidad de Wei que posee esta dirección. Wei es la unidad de Ether: 1 Ether = 10^18 Wei.
storageRoot: también conocido como hash de almacenamiento, es el hash del nodo raíz del árbol Merkle Patricia.
codeHash: hash del código EVM de esta cuenta. En una cuenta de contrato, el código se procesa mediante un hash que se guarda como codeHash. En una cuenta externa, el campo codeHash es el hash de una cadena vacía.
Durante mucho tiempo, Ethereum distinguió estrictamente entre las cuentas externas (EOA) y las cuentas de contrato. Sin embargo, esto imponía una barrera muy alta a los usuarios: debían proteger cuidadosamente sus claves privadas y tener ETH para pagar las comisiones de Gas. El estándar ERC-4337, implementado en 2023, introdujo la «abstracción de cuentas», que permite que la cuenta de un usuario sea, de forma nativa, un contrato inteligente.
Esto ha dado lugar a una mejora revolucionaria de la experiencia: admite la recuperación social (si se pierde la clave privada, se puede recuperar la cuenta con ayuda de amigos), permite pagar las comisiones de Gas con tokens como USDT e incluso procesar transacciones por lotes (autorizar y realizar un intercambio con un solo clic). La actualización Pectra de mayo de 2025 permitió además, mediante EIP-7702, que las EOA tradicionales configuren temporalmente una delegación de código y ejecuten lógica como un contrato inteligente, llevando las capacidades de abstracción de cuentas a las cuentas existentes. La abstracción de cuentas está difuminando los límites entre las EOA y las cuentas de contrato, y es una infraestructura clave para que Ethereum llegue a una adopción masiva de Web3.
3 Bloques
Todas las transacciones se agrupan en un «bloque». Una cadena de bloques contiene una serie de bloques enlazados entre sí.
3.1 Encabezado del bloque
Cada bloque tiene un «encabezado» que contiene los siguientes campos:
parentHash: hash del encabezado del bloque padre (esto es lo que convierte a los bloques en una cadena de bloques)
beneficiary (ahora llamado comúnmente feeRecipient): dirección de la cuenta que recibe la comisión de prioridad de este bloque
stateRoot: hash del nodo raíz del árbol de estado
transactionsRoot: hash del nodo raíz del árbol de Merkle que contiene todas las transacciones de este bloque
receiptsRoot: hash del nodo raíz del árbol de Merkle que contiene los recibos de todas las transacciones de este bloque
logsBloom: filtro de Bloom formado a partir de la información de los registros
prevRandao: número aleatorio proporcionado por la Beacon Chain (tras la Fusión, reemplazó a mixHash, utilizado en la era de PoW)
number: número del bloque actual (el bloque génesis tiene el número 0, y el número aumenta en 1 con cada bloque posterior)
gasLimit: límite de gas actual de cada bloque
gasUsed: cantidad total de gas utilizada por las transacciones de este bloque
timestamp: marca de tiempo Unix de la creación de este bloque
baseFeePerGas: tarifa base por unidad de gas de este bloque (introducida con la actualización London / EIP-1559 de 2021)
withdrawalsRoot: hash del nodo raíz del árbol de Merkle que contiene los datos de retiro de las participaciones de los validadores (introducido con la actualización Shanghai de 2023)
blobGasUsed / excessBlobGas: registra el uso de datos Blob (introducido con la actualización Cancun de 2024)
parentBeaconBlockRoot: hash raíz del bloque padre de la Beacon Chain, que permite que la EVM acceda al estado de la Beacon Chain (introducido con la actualización Cancun)
requestsHash: hash de varios tipos de solicitudes de la capa de ejecución (depósitos, retiros y consolidaciones de validadores) (introducido con la actualización Pectra de 2025)
extraData: datos adicionales relacionados con este bloque
Nota: tras la Fusión, algunos campos de la era PoW quedaron obsoletos: prevRandao sustituyó a mixHash; ommerHash, difficulty y nonce se mantienen como marcadores de posición en el protocolo, pero están fijados como constantes y ya no tienen ninguna función práctica. El diagrama clásico del encabezado de bloque que aparece abajo sigue la disposición antigua y no refleja estos cambios.
Cada bloque contiene tres estructuras de árbol, que corresponden a:
Estado (stateRoot)
Transacciones (transactionsRoot)
Recibos (receiptsRoot)
3.2 Árbol MPT
Ethereum utiliza una estructura de datos llamada Merkle Patricia Tree (MPT) para almacenar información. MPT es una estructura de datos mejorada que combina las ventajas de los árboles de Merkle y los árboles de prefijos. En Ethereum es una estructura importante para administrar los datos de las cuentas y generar hashes de conjuntos de transacciones.
La eficiencia con la que el MPT almacena información resulta muy útil para los «clientes ligeros» y los «nodos ligeros» de Ethereum. En términos generales, Ethereum tiene dos tipos de nodos: nodos completos y nodos ligeros.
Los nodos completos se sincronizan descargando toda la cadena, desde el bloque génesis hasta el bloque actual, y ejecutando todas las transacciones que contiene. Los validadores suelen ejecutar nodos completos, ya que tanto la validación como la producción de bloques requieren datos de estado completos.
En lugar de descargar y almacenar toda la cadena y ejecutar todas sus transacciones, los nodos ligeros solo descargan los encabezados de la cadena, desde el bloque génesis hasta el actual, y no ejecutan ninguna transacción ni consultan ningún estado asociado. Como pueden acceder a los encabezados de los bloques, que contienen los hashes raíz de los tres árboles MPT, los nodos ligeros pueden generar y recibir fácilmente respuestas verificables sobre transacciones, eventos, saldos y otros datos.
Esto funciona porque, en un árbol MPT, los hashes se propagan hacia arriba: si un usuario malicioso intenta sustituir una transacción en la base del árbol MPT por una falsa, cambiará el hash de los nodos superiores. Ese cambio también modificará el hash del siguiente nodo superior, y así sucesivamente hasta llegar al nodo raíz del árbol.
En resumen, la ventaja de utilizar árboles MPT es que el hash del nodo raíz de la estructura depende de los datos almacenados en el árbol, y ese hash raíz puede servir como identificador seguro de dichos datos. Como el encabezado del bloque contiene los hashes raíz del árbol de estado, el árbol de transacciones y el árbol de recibos, cualquier nodo puede verificar una pequeña parte del estado de Ethereum sin tener que almacenar todo el estado, que puede ser enorme.
Aunque los árboles MPT han funcionado muy bien durante los últimos años, a medida que los datos de estado de Ethereum han crecido hasta alcanzar cientos de GB, las pruebas MPT se han vuelto demasiado grandes, lo que eleva cada vez más los requisitos de hardware para ejecutar un nodo completo. Para resolver este problema, la fase «The Verge» de la hoja de ruta de Ethereum prevé migrar la estructura de datos del MPT a los árboles Verkle (Verkle Trees).
Los árboles Verkle combinan las ventajas de los compromisos vectoriales (Vector Commitments) y los árboles de Merkle, y pueden reducir el tamaño de las pruebas criptográficas (witness) en más de un orden de magnitud. Esto permitirá que incluso los teléfonos móviles y los ordenadores de muy baja potencia ejecuten fácilmente «clientes sin estado» (Stateless Clients) de Ethereum, haciendo realidad una descentralización extrema. Cabe señalar que, a fecha de 2026, la migración a Verkle sigue en fase de desarrollo y aún no se ha incluido en ningún plan confirmado de bifurcación dura.
3.3 Tiempo de producción de bloques y ritmo (Slots y Epochs)
En la era de la prueba de trabajo (PoW), el tiempo de producción de bloques era probabilístico (en promedio, unos 13–15 segundos) y se ajustaba dinámicamente según la dificultad de minado. Con el mecanismo actual de prueba de participación (PoS), el paso del tiempo en Ethereum es tan preciso como un reloj.
Ethereum divide el tiempo en unidades fijas:
Slot: cada slot dura exactamente 12 segundos. Es la ventana de tiempo en la que el sistema intenta crear un bloque nuevo. En cada slot, el sistema selecciona seudorrandómicamente a un validador para proponer un bloque, mientras que los demás validadores lo atestiguan (Attestation).
Epoch: cada epoch consta de 32 slots, es decir, 6,4 minutos. Un epoch es el ciclo básico en el que el sistema liquida las recompensas y sanciones de los validadores, los reorganiza (redistribuye sus funciones) y alcanza la «finalidad» de los bloques.
Este diseño de ritmo fijo hace que el funcionamiento de la red Ethereum sea más predecible: las funciones rotativas de los validadores, los tiempos de confirmación de las transacciones y la liquidación de las recompensas y confiscaciones siguen un ritmo definido.
4 Gas y comisiones
Uno de los conceptos importantes de Ethereum son las comisiones. Cada operación computacional que se produce a raíz de una transacción en la red Ethereum genera una comisión, que se paga en Gas.
Gas es la unidad que se utiliza para medir el costo de una operación computacional concreta. Wei es la unidad más pequeña de Ether: 1 Ether = 10^18 Wei. El precio del gas suele expresarse en gwei: 1 gwei = 10^9 Wei.
Tras la actualización London de 2021 (EIP-1559), el mercado de comisiones de Ethereum cambió de forma fundamental. Ahora, las comisiones de las transacciones constan de dos partes:
Tarifa base (Base Fee): el protocolo la calcula automáticamente según el nivel de congestión del bloque anterior, y se aplica por igual a todas las transacciones de un mismo bloque. Esta parte no se paga a los validadores, sino que la red la destruye directamente (Burned).
Comisión de prioridad (Priority Fee / Tip): propina que el usuario paga voluntariamente al proponente del bloque (validador) para incentivarlo a incluir su transacción antes que otras.
Por lo tanto, al enviar una transacción, los usuarios ya no establecen un único gasPrice, sino maxFeePerGas (el precio total máximo que están dispuestos a pagar por cada unidad de gas) y maxPriorityFeePerGas (la propina máxima que están dispuestos a ofrecer). Además, cada transacción sigue teniendo que establecer un gasLimit, que representa la cantidad máxima de gas que el remitente está dispuesto a pagar para ejecutar la transacción.
Por ejemplo, supongamos que el remitente establece un gasLimit de 50,000 y un maxFeePerGas de 20 gwei. Esto significa que está dispuesto a pagar como máximo 50,000 × 20 gwei = 1,000,000,000,000,000 Wei = 0.001 Ether para ejecutar esta transacción.
El precio que se paga realmente por la transacción es min(maxFeePerGas, Base Fee + maxPriorityFeePerGas). Si el saldo de la cuenta del usuario es suficiente para cubrir la comisión máxima, no hay problema; al finalizar la transacción, se devuelve al remitente todo el gas que no se haya utilizado.
Si el remitente no proporciona suficiente gas para ejecutar la transacción, esta se queda «sin gas» durante la ejecución y se considera inválida. En ese caso, se interrumpe el procesamiento de la transacción y se revierten todos los cambios de estado, con lo que se vuelve al estado exacto anterior a la transacción, como si nunca hubiera ocurrido. Como la máquina ya ha realizado cálculos antes de quedarse sin gas, en teoría no se devuelve nada de gas al remitente.
¿Adónde va exactamente el dinero de estas comisiones de gas?
Tarifa base: se destruye permanentemente (Burned) y se elimina del suministro total de ETH. Cuando la actividad en la cadena es elevada, la cantidad destruida puede incluso hacer que ETH entre en estado deflacionario.
Comisión de prioridad: se paga al validador que propuso correctamente el bloque (es decir, al antiguo «minero»). Como el proponente incurre en costos de computación y ancho de banda al incluir, ejecutar y validar transacciones, recibe esta recompensa a cambio.
Por lo general, cuanto más alta sea la comisión de prioridad que esté dispuesto a pagar el remitente, más valor obtiene el validador de esa transacción y más incentivos tiene para incluirla antes. Los validadores pueden elegir libremente qué transacciones validar o ignorar; la comisión de prioridad es una oferta por ese derecho de elección.
¿Qué utilidad tienen las comisiones de Ethereum?
En primer lugar, un aspecto importante del funcionamiento de Ethereum es que todos los nodos completos de la red ejecutan repetidamente las mismas operaciones. Sin embargo, las operaciones computacionales son muy costosas en la máquina virtual de Ethereum. Por eso, lo más conveniente es que los contratos inteligentes de Ethereum realicen tareas sencillas, como ejecutar una lógica empresarial simple o validar firmas y otros objetos criptográficos, en lugar de operaciones complejas, como el almacenamiento de archivos, el correo electrónico o el aprendizaje automático, que presionarían la red. Por lo tanto, cobrar comisiones evita que la red se sobrecargue.
En segundo lugar, el lenguaje de los contratos inteligentes de Ethereum es Turing completo (en pocas palabras, una máquina de Turing puede simular cualquier algoritmo informático), lo que significa que el código puede contener bucles. Si no hubiera comisiones, un actor malicioso podría paralizar la red ejecutando una transacción con un bucle infinito. Por lo tanto, cobrar comisiones también protege la red de ataques deliberados.
En tercer lugar, Gas no solo sirve para pagar el costo de las operaciones computacionales, sino también el del almacenamiento. El costo total de almacenamiento es proporcional al tamaño de los datos, lo que incentiva a los usuarios a reducir al mínimo la cantidad de datos almacenados. Esto se debe a que ampliar la capacidad de almacenamiento aumenta el tamaño de la base de datos del estado de Ethereum en todos los nodos, un costo que debe asumir toda la red.
5 Transacciones y mensajes
Ethereum es una máquina de estados basada en transacciones. En otras palabras, las transacciones entre distintas cuentas son las que hacen que el estado global de Ethereum pase de un estado a otro.
Una transacción es una instrucción firmada criptográficamente, creada y serializada por una cuenta externa y luego enviada a la cadena de bloques. Hay dos tipos: llamadas a mensajes (message calls) y creación de contratos (contract creations).
Todas las transacciones incluyen los siguientes componentes, independientemente de su tipo:
nonce: contador del número de transacciones que ha enviado el remitente
gasPrice: cantidad de Wei que el remitente está dispuesto a pagar por cada unidad de gas necesaria para ejecutar la transacción. Desde EIP-1559, se ha ido sustituyendo por maxFeePerGas y maxPriorityFeePerGas (consulta la sección 4 para obtener más información).
gasLimit: cantidad máxima de gas que el remitente está dispuesto a pagar para ejecutar la transacción. Este valor se deduce por adelantado antes de que se complete cualquier cálculo.
to: dirección del destinatario. En las transacciones de creación de contratos, la cuenta del contrato aún no existe, por lo que se utiliza un valor vacío.
value: cantidad de Wei transferida del remitente al destinatario. En una transacción de creación de contrato, value es el saldo inicial de la nueva cuenta del contrato.
v, r, s: se utilizan para generar la firma que identifica al remitente de la transacción
init: solo está presente en las transacciones de creación de contratos y contiene el fragmento de código EVM que inicializa la nueva cuenta del contrato. El valor init se ejecuta una vez y después se descarta. Cuando init se ejecuta por primera vez, devuelve el cuerpo de código de la cuenta: el código que queda asociado permanentemente a la cuenta del contrato.
data: campo opcional que solo está presente en la comunicación mediante mensajes; contiene los datos de entrada del mensaje (es decir, los parámetros). Por ejemplo, si el contrato inteligente es un servicio de registro de nombres de dominio, la llamada al contrato podría esperar los siguientes parámetros de entrada: el nombre de dominio y la dirección IP.
Tanto las llamadas a mensajes como la creación de contratos son activadas por cuentas externas y enviadas a la cadena de bloques. Dicho de otro modo, las transacciones son el puente entre el mundo exterior y el estado interno de Ethereum.
Sin embargo, esto no significa que un contrato no pueda comunicarse con otro. Los contratos que forman parte del estado global de Ethereum pueden comunicarse entre sí. Lo hacen mediante «mensajes» o «transacciones internas». Cuando un contrato envía una transacción interna a otro, se ejecuta el código asociado a la cuenta del contrato destinatario.
Es importante tener en cuenta que las transacciones internas o los mensajes no incluyen un gasLimit, porque el límite de gas lo determina el creador externo de la transacción original (es decir, la cuenta externa). El gasLimit establecido por la cuenta externa debe ser lo bastante alto para completar la transacción, incluidas las «ejecuciones secundarias» que esta genere, como los mensajes entre contratos.
A medida que Ethereum consolida su estrategia de escalabilidad «centrada en los Rollups (redes de capa 2)», las Layer 2 necesitan publicar grandes cantidades de datos en la red principal para garantizar la seguridad. Antes, estos datos solo podían incluirse en las costosas transacciones convencionales (ocupando calldata).
La actualización Cancun de marzo de 2024 introdujo un nuevo tipo de transacción: las transacciones Blob (Type 3 Transaction). Blob (Binary Large Object) es un espacio de almacenamiento temporal diseñado específicamente para transportar grandes bloques de datos. Su característica principal es que los datos solo permanecen en la cadena durante unos 18 días, después de lo cual los nodos los descartan automáticamente y no aumentan de forma permanente la carga de estado de Ethereum. Esta innovación redujo en más de un 90 % las comisiones por transacción de Layer 2 y marcó la entrada oficial de Ethereum en la era de las aplicaciones de bajo costo.
La actualización Fusaka de diciembre de 2025 introdujo PeerDAS (muestreo de disponibilidad de datos entre pares), que aumentó aproximadamente en un orden de magnitud la capacidad de datos Blob y redujo aún más los costos de Layer 2.
6 Máquina virtual de Ethereum
El protocolo de Ethereum existe únicamente para que esta máquina de estados especial funcione de forma continua, ininterrumpida e inmutable.
La máquina virtual de Ethereum es el entorno del que dependen todas las cuentas y los contratos inteligentes de Ethereum. En cualquier bloque de la cadena, Ethereum tiene un único estado «canónico», y la máquina virtual de Ethereum define las reglas para calcular un nuevo estado válido de un bloque al siguiente.
Para describir cadenas de bloques como Bitcoin, suele utilizarse la analogía de un «libro mayor distribuido». Ethereum también tiene su propia criptomoneda nativa (ETH), que sigue reglas prácticamente idénticas, pero además admite una función más potente: los contratos inteligentes. Por eso, Ethereum no es solo un libro mayor distribuido; es, más precisamente, una máquina de estados distribuida.
El estado de Ethereum es una enorme estructura de datos llamada árbol MPT. No solo guarda todas las cuentas y sus saldos, sino también un estado de máquina que puede cambiar de un bloque a otro según un conjunto predefinido de reglas y ejecutar cualquier código de máquina. Las reglas concretas para cambiar el estado en un bloque están definidas por la EVM.
La EVM funciona como una máquina de pila con una profundidad de 1024 elementos. Cada elemento es una palabra de 256 bits; se eligió este tamaño para facilitar el uso de la criptografía de 256 bits.
La EVM tiene memoria, cuyas entradas son matrices de bytes direccionadas por palabra (word-addressed byte arrays). La memoria es volátil y no persiste de una transacción a otra.
La EVM también tiene almacenamiento. A diferencia de la memoria, el almacenamiento no es volátil y se conserva como parte del estado del sistema. La EVM almacena el código del programa de forma independiente en una ROM virtual, a la que solo se puede acceder mediante instrucciones especiales. Esto diferencia a la EVM de la arquitectura típica de von Neumann, en la que el código del programa se encuentra en la memoria o el almacenamiento.
La EVM también tiene su propio lenguaje: el bytecode de la EVM. Cuando los programadores escriben contratos inteligentes para Ethereum, suelen utilizar lenguajes de alto nivel, como Solidity. Después, el código se puede compilar a bytecode de la EVM para que la EVM pueda entenderlo y ejecutarlo.
El bytecode compilado de los contratos inteligentes se ejecuta mediante una serie de opcodes de la EVM, que realizan operaciones estándar de pila como XOR, AND, ADD y SUB, entre otras. La EVM también implementa algunas operaciones de pila específicas de la cadena de bloques, como ADDRESS, BALANCE y BLOCKHASH.
Aunque la EVM ha tenido un éxito enorme, el formato de su bytecode subyacente apenas ha recibido optimizaciones estructurales desde su creación. Esto hace que el análisis del código sea poco eficiente y propenso a vulnerabilidades. Los desarrolladores de Ethereum están trabajando en la actualización EOF (EVM Object Format), que introduciría una estructura de «contenedor» explícita para los contratos inteligentes y separaría las secciones de código, datos y tipos. Esto no solo reduciría el consumo de Gas al desplegar contratos, sino que también eliminaría de raíz ciertos tipos de vulnerabilidades relacionadas con los saltos y haría más seguras las auditorías. Sin embargo, debido al amplio alcance de los cambios, EOF, cuya implementación estaba prevista inicialmente para la actualización Fusaka de finales de 2025, acabó retirándose por los riesgos asociados al calendario. A fecha de 2026, aún no se ha implementado en ninguna bifurcación dura.
Además, aunque Solidity sigue siendo el lenguaje dominante, el ecosistema EVM es cada vez más diverso. El lenguaje Vyper, que prioriza la seguridad, y las iniciativas para ejecutar código compilado de Rust/C++ mediante la arquitectura RISC-V están ampliando continuamente los límites de la máquina virtual de Ethereum.
Sígueme para no perderte el próximo resumen rápido del mercado.