Después de Pectra, llega Fusaka: el paso más clave de Ethereum hacia la "expansión infinita"

La bifurcación dura Fusaka, programada para activarse el 3 de diciembre de 2025, es una importante actualización de red de Ethereum tras Pectra, marcando otro paso significativo de este gigante cripto hacia la escalabilidad.

Las EIP de la actualización Pectra se centran en mejorar el rendimiento, la seguridad y las herramientas para desarrolladores. Las EIP de Fusaka, en cambio, ponen el foco en la escalabilidad, la actualización de códigos de operación y la seguridad de la ejecución.

PeerDAS (EIP-7594) mejora la disponibilidad de datos permitiendo que los nodos verifiquen blobs sin descargar todos los datos. Varias actualizaciones también refuerzan la seguridad de la ejecución, incluyendo la limitación de ModExp (EIP-7823), el límite de gas por transacción (EIP-7825) y la actualización del costo de gas de ModExp (EIP-7883). Además, la actualización Fusaka mejora la generación de bloques mediante un mecanismo determinista de previsualización de proponentes (EIP-7917) y mantiene la estabilidad de las tarifas de blobs mediante un “precio de reserva” vinculado al costo de ejecución (EIP-7918).

Otras mejoras incluyen el límite al tamaño de bloques en formato RLP (EIP-7934), la adición de un nuevo código de operación CLZ para acelerar operaciones de bits (EIP-7939), y la introducción de la precompilación secp256r1 (EIP-7951) para una mejor compatibilidad con la criptografía moderna y llaves de seguridad de hardware.

Fusaka es una combinación de Fulu (capa de ejecución) y Osaka (capa de consenso). Representa otro paso de Ethereum hacia un futuro altamente escalable y rico en datos, donde los rollups de Layer 2 pueden operar a menor costo y mayor velocidad.

Este artículo analiza en profundidad las 9 EIP centrales de la bifurcación dura Fusaka.

EIP-7594: PeerDAS — Muestreo de disponibilidad de datos por nodos

Ethereum necesita esta propuesta porque la red busca ofrecer mayor disponibilidad de datos a los usuarios, especialmente a los usuarios de rollups.

Sin embargo, bajo el diseño actual de EIP-4844, cada nodo aún debe descargar grandes cantidades de datos de blobs para verificar si han sido publicados. Esto genera problemas de escalabilidad, ya que si todos los nodos deben descargar todos los datos, aumentan los requisitos de ancho de banda y hardware de la red, y se reduce la descentralización. Para resolver esto, Ethereum necesita un método que permita a los nodos confirmar la disponibilidad de datos sin descargar todo el contenido.

El muestreo de disponibilidad de datos (DAS) resuelve este problema permitiendo que los nodos verifiquen solo una pequeña cantidad de datos aleatorios.

Pero Ethereum también necesita un método DAS compatible con la red Gossip existente y que no sobrecargue a los productores de bloques con cálculos pesados. PeerDAS fue creado para satisfacer estas necesidades y aumentar de forma segura el rendimiento de blobs manteniendo bajos los requisitos para los nodos.

PeerDAS es un sistema de red que permite a los nodos descargar solo pequeños fragmentos de datos para verificar si el conjunto completo ha sido publicado. Los nodos no descargan todos los datos, sino que usan la red gossip para compartir datos, descubrir qué nodos tienen partes específicas y solicitar solo una pequeña muestra. La idea central es que, descargando solo una pequeña parte aleatoria de los datos, los nodos aún pueden estar seguros de la existencia del fragmento completo. Por ejemplo, un nodo podría descargar solo 1/8 de los datos, en vez de los 256 KB completos de un blob; pero como muchos nodos muestrean diferentes partes, cualquier dato faltante se detecta rápidamente.

Para lograr el muestreo, PeerDAS utiliza un código de borrado básico para expandir cada fragmento de datos en EIP-4844. Un código de borrado es una técnica que añade datos redundantes, permitiendo recuperar la información original incluso si faltan fragmentos, como un rompecabezas que puede completarse aunque falten piezas.

El blob se convierte en una “fila” que contiene los datos originales y algunos datos codificados extra para poder reconstruirlos después. Luego, esta fila se divide en pequeños bloques llamados “celdas”, que son la unidad mínima de verificación asociada a los compromisos KZG. Todas las “filas” se reorganizan en “columnas”, cada una conteniendo la celda de la misma posición de todas las filas. Cada columna se asigna a una subred gossip específica.

Los nodos almacenan ciertas columnas según su ID de nodo y muestrean algunas columnas de sus pares en cada slot. Si un nodo recolecta al menos el 50% de las columnas, puede reconstruir todos los datos. Si recolecta menos del 50%, debe solicitar las columnas faltantes a sus pares. Esto asegura que, si los datos realmente fueron publicados, siempre se puedan reconstruir. En resumen, si hay 64 columnas en total, un nodo solo necesita unas 32 para reconstruir el blob completo. Guarda algunas columnas y descarga otras de sus pares. Mientras exista la mitad de las columnas en la red, el nodo puede reconstruir todo, incluso si faltan algunas.

Además, EIP-7594 introduce una regla importante: ninguna transacción puede contener más de 6 blobs. Esta restricción debe aplicarse durante la verificación de transacciones, la propagación gossip, la creación y el procesamiento de bloques. Esto ayuda a reducir casos extremos en los que una sola transacción sobrecarga el sistema de blobs.

PeerDAS añade una función llamada “prueba KZG de celda”. Esta prueba demuestra que el compromiso KZG realmente coincide con una celda específica del blob. Así, los nodos pueden descargar solo la celda que desean muestrear. Esto es esencial para el muestreo de disponibilidad de datos, ya que permite obtener el blob completo garantizando la integridad de los datos.

Sin embargo, generar todas estas pruebas de celda es costoso. Los productores de bloques deben calcular repetidamente estas pruebas para muchos blobs, lo que ralentiza el proceso. Pero la verificación de las pruebas es muy barata, por lo que EIP-7594 exige que el remitente de la transacción de blob genere previamente todas las pruebas de celda y las incluya en el envoltorio de la transacción.

Por eso, el gossip de transacciones (PooledTransactions) ahora utiliza un envoltorio modificado:

rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs])

En el nuevo envoltorio, cell_proofs es una lista con todas las pruebas de cada celda de cada blob (por ejemplo: [cell_proof_0, cell_proof_1, ...]). Los demás campos, tx_payload_body, blobs y commitments, son idénticos a los de EIP-4844. La diferencia es que el campo “proofs” original se elimina y se reemplaza por la nueva lista cell_proofs, y se añade el campo wrapper_version para indicar el formato actual del envoltorio.

PeerDAS permite a Ethereum aumentar la disponibilidad de datos sin incrementar la carga de trabajo de los nodos. Hoy, un nodo solo necesita muestrear aproximadamente 1/8 del total de datos. En el futuro, esta proporción podría bajar incluso a 1/16 o 1/32, mejorando la escalabilidad de Ethereum. El sistema funciona bien porque cada nodo tiene muchos pares; si un par no puede proporcionar los datos requeridos, el nodo puede solicitarlos a otros pares. Esto crea un mecanismo de redundancia natural y mejora la seguridad, ya que los nodos pueden optar por almacenar más datos de los necesarios, reforzando aún más la seguridad de la red.

Los nodos validadores asumen más responsabilidad que los nodos completos normales. Como los validadores operan con hardware más potente, PeerDAS les asigna una carga de almacenamiento de datos proporcional a su número total. Esto asegura que siempre haya un grupo estable de nodos para almacenar y compartir más datos, aumentando la confiabilidad de la red. En resumen, si hay 900,000 validadores, a cada uno se le puede asignar una pequeña parte del total de datos para almacenar y servir. Dado que los validadores tienen máquinas más potentes, la red puede confiar en que garantizarán la disponibilidad de los datos.

PeerDAS utiliza muestreo por columnas en vez de por filas porque así se simplifica mucho la reconstrucción de datos. Si los nodos muestrearan filas completas (todo el blob), habría que crear “blobs extendidos” adicionales que no existen originalmente, lo que ralentizaría a los productores de bloques.

Con el muestreo por columnas, los nodos pueden preparar previamente los datos de filas adicionales, y es el remitente de la transacción (no el productor de bloques) quien calcula las pruebas necesarias. Así se mantiene la velocidad y eficiencia en la creación de bloques. Por ejemplo: si un blob es una cuadrícula de 4×4 celdas, el muestreo por filas implica tomar las 4 celdas de una fila, pero algunas filas extendidas aún no están listas, por lo que el productor de bloques debe generarlas en el momento; el muestreo por columnas implica tomar una celda de cada fila (cada columna), y las celdas adicionales necesarias pueden prepararse de antemano, permitiendo a los nodos verificar los datos sin ralentizar la generación de bloques.

EIP-7594 es totalmente compatible con EIP-4844, por lo que no rompe ninguna funcionalidad existente en Ethereum. Todas las pruebas y reglas detalladas están incluidas en las especificaciones de consenso y ejecución.

El principal riesgo de seguridad de cualquier sistema DAS es el “ataque de ocultamiento de datos”, donde el productor de bloques finge que los datos están disponibles, pero en realidad oculta parte de ellos. PeerDAS previene esto usando muestreo aleatorio: los nodos revisan partes aleatorias de los datos. Cuantos más nodos muestrean, más difícil es para un atacante hacer trampa. EIP-7594 incluso proporciona una fórmula para calcular la probabilidad de éxito de este tipo de ataque según el número total de nodos (n), el total de muestras (m) y el número de muestras por nodo (k). En la red principal de Ethereum, con unos 10,000 nodos, la probabilidad de éxito es extremadamente baja, por lo que PeerDAS se considera seguro.

EIP-7823: Límite de 1024 bytes para MODEXP

Esta propuesta es necesaria porque el mecanismo precompilado MODEXP de Ethereum ha causado numerosas vulnerabilidades de consenso durante años. La mayoría de estos problemas surgen porque MODEXP permite entradas de tamaño extremadamente grande e irreal, obligando a los clientes a manejar innumerables casos excepcionales.

Como cada nodo debe procesar todas las entradas proporcionadas por la transacción, la ausencia de un límite hace que MODEXP sea más difícil de probar, más propenso a errores y más probable que se comporte de manera diferente en distintos clientes. Las entradas demasiado grandes también dificultan la previsibilidad de la fórmula de costos de gas, ya que es difícil establecer precios cuando los datos pueden crecer indefinidamente. Estos problemas también complican la futura sustitución de MODEXP por código a nivel EVM usando herramientas como EVMMAX, ya que sin un límite fijo, los desarrolladores no pueden crear rutas de ejecución seguras y optimizadas.

Para reducir estos problemas y mejorar la estabilidad de Ethereum, EIP-7823 impone un límite estricto al tamaño de las entradas de MODEXP, haciendo el proceso precompilado más seguro, fácil de probar y predecible.

EIP-7823 introduce una regla simple: los tres campos de longitud usados por MODEXP (base, exponente y módulo) deben ser menores o iguales a 8192 bits, es decir, 1024 bytes. La entrada de MODEXP sigue el formato definido en EIP-198: <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS>, por lo que esta EIP solo limita los valores de longitud. Si alguna longitud supera los 1024 bytes, la precompilación se detiene de inmediato, devuelve un error y consume todo el gas.

Por ejemplo, si alguien intenta proporcionar una base de 2000 bytes, la llamada fallará antes de que comience cualquier trabajo. Estos límites siguen cubriendo todos los casos de uso prácticos. La verificación RSA suele usar claves de 1024, 2048 o 4096 bits, todas dentro del nuevo límite. Las operaciones de curvas elípticas usan tamaños de entrada aún menores, normalmente menos de 384 bits, por lo que tampoco se ven afectadas.

Estos nuevos límites también ayudan a futuras actualizaciones. Si en el futuro MODEXP se reescribe como código EVM usando EVMMAX, los desarrolladores pueden añadir rutas optimizadas para tamaños de entrada comunes (por ejemplo, 256, 381 o 2048 bits) y usar rutas de retroceso más lentas para casos raros. Al fijar un tamaño máximo de entrada, incluso pueden añadir tratamientos especiales para módulos muy comunes. Antes, como el tamaño de entrada no tenía límite, el espacio de diseño era demasiado grande para gestionarlo de forma segura, así que esto no era posible.

Para confirmar que este cambio no rompe transacciones pasadas, el autor analizó todos los usos de MODEXP desde el bloque 5,472,266 (20 de abril de 2018) hasta el bloque 21,550,926 (4 de enero de 2025). El resultado muestra que ninguna llamada exitosa a MODEXP en la historia usó entradas de más de 513 bytes, muy por debajo del nuevo límite de 1024 bytes. La mayoría de las llamadas reales usaron longitudes menores, como 32, 128 o 256 bytes.

Existen algunas llamadas inválidas o corruptas, como entradas vacías, entradas con bytes repetidos, y una entrada muy grande pero inválida. Estas llamadas también serán inválidas bajo el nuevo límite, ya que ya eran inválidas de por sí. Por lo tanto, aunque EIP-7823 es técnicamente un cambio importante, en la práctica no altera el resultado de ninguna transacción pasada.

Desde el punto de vista de la seguridad, reducir el tamaño permitido de las entradas no introduce nuevos riesgos. Al contrario, elimina casos extremos innecesarios que antes causaban errores e inconsistencias entre clientes. Al limitar las entradas de MODEXP a un rango razonable, EIP-7823 hace el sistema más predecible, reduce casos extremos extraños y disminuye la probabilidad de errores entre implementaciones. Estos límites también ayudan a prepararse para futuras actualizaciones (como EVMMAX) que introduzcan rutas de ejecución optimizadas, permitiendo una transición más fluida.

EIP-7825: Límite de gas de 16.7 millones por transacción

Ethereum también necesita esta propuesta porque actualmente una sola transacción puede consumir casi todo el límite de gas de un bloque.

Esto genera varios problemas: una transacción puede consumir la mayor parte de los recursos del bloque, causando demoras similares a ataques DoS; operaciones que consumen mucho gas aceleran demasiado las actualizaciones de estado de Ethereum; la validación de bloques se vuelve más lenta y los nodos tienen dificultades para mantenerse al día.

Si un usuario envía una transacción que consume casi todo el gas del bloque (por ejemplo, una transacción que usa 38 millones de gas en un bloque de 40 millones), otras transacciones normales no pueden entrar en ese bloque, y cada nodo debe dedicar tiempo extra para verificarlo. Esto amenaza la estabilidad y descentralización de la red, ya que la validación lenta hace que los nodos menos potentes se queden atrás. Para resolver esto, Ethereum necesita un límite seguro de gas por transacción, haciendo que la carga de los bloques sea más predecible, reduciendo el riesgo de ataques DoS y equilibrando la carga entre nodos.

EIP-7825 introduce una regla estricta: ninguna transacción puede consumir más de 16,777,216 (2²⁴) gas. Este es un límite a nivel de protocolo, aplicable a todos los niveles: envío de transacciones, verificación en el pool de transacciones y empaquetado por validadores en bloques. Si alguien envía una transacción con un límite de gas superior, el cliente debe rechazarla de inmediato y devolver un error como MAX_GAS_LIMIT_EXCEEDED.

Este límite es completamente independiente del límite de gas por bloque. Por ejemplo, aunque el bloque tenga un límite de 40 millones de gas, ninguna transacción individual puede superar los 16.7 millones. El objetivo es asegurar que cada bloque pueda contener varias transacciones, evitando que una sola acapare todo el espacio.

Para entenderlo mejor, supongamos que un bloque puede contener 40 millones de gas. Sin este límite, alguien podría enviar una transacción de 35 a 40 millones de gas, monopolizando el bloque y dejando fuera a las demás, como si una persona alquilara todo un colectivo y nadie más pudiera subir. El nuevo límite de 16.7 millones hará que los bloques contengan varias transacciones, evitando este abuso.

La propuesta también exige que los clientes verifiquen este límite. Si una transacción supera los 16,777,216 gas, el pool debe rechazarla, por lo que ni siquiera entra en la cola. Si un bloque contiene una transacción que supera el límite, el bloque debe ser rechazado.

El número 16,777,216 (2²⁴) se eligió porque es una potencia de 2 clara, fácil de implementar, y sigue siendo lo suficientemente grande para la mayoría de las transacciones reales. Por ejemplo, para despliegues de contratos inteligentes, interacciones DeFi complejas o llamadas a contratos de varios pasos. Este valor es aproximadamente la mitad del tamaño típico de un bloque, lo que significa que incluso las transacciones más complejas pueden ajustarse fácilmente.

Esta EIP mantiene la compatibilidad con el mecanismo de gas existente. La mayoría de los usuarios no notarán el cambio, ya que casi todas las transacciones actuales usan mucho menos de 16 millones de gas. Los validadores y creadores de bloques aún pueden crear bloques con más de 16.7 millones de gas en total, siempre que cada transacción respete el nuevo límite.

Las únicas transacciones afectadas son aquellas que intentaban usar más gas que el nuevo límite. Ahora deberán dividirse en varias operaciones más pequeñas, como dividir un archivo grande en dos más pequeños para subirlo. Técnicamente, este cambio no es retrocompatible para estas transacciones extremas, pero se espera que sean muy pocas.

En cuanto a seguridad, el límite de gas hace que Ethereum sea más resistente a ataques DoS basados en gas, ya que los atacantes no pueden forzar a los validadores a procesar transacciones enormes. También ayuda a mantener la previsibilidad del tiempo de validación de bloques, facilitando la sincronización de los nodos. El único caso extremo es que algunos despliegues de contratos muy grandes no podrán ajustarse al límite y deberán rediseñarse o dividirse en varios pasos.

En general, EIP-7825 busca fortalecer la red contra abusos, mantener razonables los requisitos para los nodos, mejorar la equidad en el uso del espacio de bloques y asegurar que, al aumentar el límite de gas, la blockchain siga funcionando rápida y estable.

EIP-7883: Aumento del costo de gas de ModExp

Ethereum necesita esta propuesta porque el precio de la precompilación ModExp (para operaciones de exponenciación modular) ha sido históricamente bajo en comparación con los recursos que realmente consume.

En algunos casos, la cantidad de cálculo requerido por ModExp supera ampliamente lo que los usuarios pagan actualmente. Esta desproporción es riesgosa: si las llamadas complejas a ModExp son demasiado baratas, pueden convertirse en un cuello de botella, dificultando el aumento seguro del límite de gas por bloque, ya que los productores de bloques podrían verse obligados a procesar operaciones muy pesadas a bajo costo.

Para resolver esto, Ethereum necesita ajustar la fórmula de precios de ModExp para que el gas consumido refleje con precisión el trabajo real realizado por los clientes. Por eso, EIP-7883 introduce nuevas reglas, aumentando el costo mínimo de gas, el costo total y haciendo que las operaciones con grandes volúmenes de datos (especialmente exponentes, bases o módulos de más de 32 bytes) sean mucho más caras, alineando el precio del gas con el costo computacional real.

La propuesta incrementa el costo en varios aspectos, modificando el algoritmo de precios de ModExp definido originalmente en EIP-2565.

Primero, el consumo mínimo de gas sube de 200 a 500, y el consumo total de gas ya no se divide por 3, lo que triplica el costo total. Por ejemplo, si antes una llamada a ModExp costaba 1200 gas, ahora costará unos 3600 gas.

Segundo, las operaciones con exponentes mayores a 32 bytes duplican su costo, ya que el multiplicador pasa de 8 a 16. Por ejemplo, si el exponente tiene 40 bytes, EIP-2565 aumentaba las iteraciones en 8 × (40 − 32) = 64; EIP-7883 ahora usa 16 × (40 − 32) = 128, duplicando el costo.

Tercero, el precio ahora asume un tamaño mínimo de base/módulo de 32 bytes, y cuando estos valores superan los 32 bytes, el costo computacional aumenta drásticamente. Por ejemplo, si el módulo es de 64 bytes, la nueva regla aplica una complejidad doble (2 × words²), en vez de la fórmula más simple anterior, reflejando el costo real de las operaciones con números grandes. Estos cambios aseguran que las operaciones ModExp pequeñas paguen un mínimo razonable y que las grandes y complejas tengan un costo ajustado a su tamaño.

La propuesta define una nueva función de cálculo de gas, actualizando las reglas de complejidad e iteraciones. La complejidad multiplicativa ahora usa el valor por defecto 16 para bases/módulos de hasta 32 bytes, y para entradas mayores, cambia a la fórmula 2 × words², donde “words” es el número de bloques de 8 bytes. Las iteraciones también se actualizan: exponentes de 32 bytes o menos usan la longitud en bits para determinar la complejidad, y exponentes mayores reciben una penalización de gas mayor.

Esto asegura que las operaciones con exponentes enormes, que realmente consumen muchos recursos, ahora tengan un costo de gas mucho mayor. Importante: el costo mínimo de gas se fija en 500, en vez de 200, haciendo que incluso las llamadas más simples sean más razonables.

El motivo de estos aumentos es un benchmark que mostró que el precio de ModExp era demasiado bajo en muchos casos. La fórmula revisada incrementa el costo de gas de operaciones pequeñas en un 150%, las típicas en un 200%, y las grandes o desbalanceadas mucho más, a veces más de 80 veces, según el tamaño del exponente, base o módulo.

El objetivo no es cambiar el funcionamiento de ModExp, sino asegurar que incluso en los casos más extremos de consumo de recursos, no amenace la estabilidad de la red ni impida futuros aumentos del límite de gas por bloque. Como EIP-7883 cambia la cantidad de gas requerida por ModExp, no es retrocompatible, pero la revalorización del gas ya ha ocurrido varias veces en Ethereum y es bien comprendida.

Las pruebas muestran que el aumento de gas es muy significativo. Aproximadamente el 99,69% de las llamadas históricas a ModExp ahora requerirán 500 gas (antes 200) o el triple del precio anterior. Pero en algunos casos de prueba de alta carga, el gas sube mucho más. Por ejemplo, en una prueba “intensiva en exponentes”, el consumo de gas pasa de 215 a 16,624, unas 76 veces más, porque ahora el precio para exponentes enormes es más realista.

En cuanto a seguridad, la propuesta no introduce nuevas vías de ataque ni reduce el costo de ninguna operación. Al contrario, previene un riesgo importante: que operaciones ModExp subvaloradas permitan a un atacante llenar bloques con cálculos pesados a bajo costo. El único posible inconveniente es que algunas operaciones ModExp sean ahora demasiado caras, pero esto es preferible a que sean demasiado baratas. La propuesta no introduce cambios de interfaz ni nuevas funciones, por lo que el comportamiento aritmético y los vectores de prueba existentes siguen siendo válidos.

EIP-7917: Predicción precisa del próximo proponente

Ethereum necesita esta propuesta porque la programación de proponentes para el próximo epoch no es completamente predecible. Incluso si en el epoch N se conoce la semilla RANDAO del epoch N+1, la lista real de proponentes puede cambiar debido a actualizaciones del saldo efectivo (EB) dentro del epoch N.

Estos cambios de EB pueden deberse a penalizaciones, castigos, recompensas superiores a 1 ETH, fusiones de validadores o nuevos depósitos, especialmente después de EIP-7251, que eleva el saldo efectivo máximo por encima de 32 ETH. Esta incertidumbre es problemática para sistemas que dependen de conocer con antelación el próximo proponente (por ejemplo, protocolos basados en preconfirmaciones), que necesitan un calendario estable y predecible para funcionar correctamente. Incluso los validadores podrían intentar “manipular” su saldo efectivo para influir en el proponente del próximo epoch.

Por estos motivos, Ethereum necesita un método para que el calendario de proponentes sea completamente determinista para los próximos epochs, sin que los cambios de EB de último momento lo alteren, y que sea fácilmente accesible para la capa de aplicación.

Para lograr esto, EIP-7917 introduce un mecanismo determinista de previsualización de proponentes: al inicio de cada epoch, se calcula y almacena por adelantado la programación de proponentes para los próximos MIN_SEED_LOOKAHEAD + 1 epochs. En otras palabras, el estado del beacon ahora incluye una lista llamada `prosoperer_lookahead`, que siempre cubre dos ciclos completos de proponentes (64 slots en total).

Por ejemplo, al comenzar el epoch N, la lista ya contiene los proponentes de cada slot de los epochs N y N+1. Cuando la red entra en el epoch N+1, la lista avanza: se eliminan las entradas del epoch N, se mueven las del N+1 al frente y se añaden las del N+2 al final. Así, la programación es fija, predecible y los clientes pueden leerla directamente sin recalcular el proponente en cada slot.

Para mantener la actualización, la lista avanza en cada cambio de epoch: se eliminan los datos del epoch anterior y se calculan los índices de proponentes para el próximo epoch, añadiéndolos al final. El proceso usa las mismas reglas de semilla y saldo efectivo que antes, pero ahora la programación se calcula antes, evitando que los cambios de saldo efectivo posteriores a la determinación de la semilla la afecten. El primer bloque tras la bifurcación también rellenará todo el rango de previsualización para asegurar que todos los epochs futuros tengan la programación correctamente inicializada.

Supongamos que cada epoch tiene 8 slots en vez de 32 (por simplicidad). Sin esta EIP, durante el epoch 5, aunque se conozca la semilla del epoch 6, si un validador es penalizado o recibe suficientes recompensas para cambiar su saldo efectivo durante el epoch 5, el proponente real del slot 2 del epoch 6 aún podría cambiar. Con EIP-7917, Ethereum calcula por adelantado todos los proponentes de los epochs 5, 6 y 7 al inicio del epoch 5 y los almacena en `prosopers_lookahead`. Así, aunque el saldo cambie al final del epoch 5, la lista de proponentes del epoch 6 permanece fija y predecible.

EIP-7917 corrige un defecto de diseño de larga data en la beacon chain. Garantiza que, una vez disponible la RANDAO del epoch anterior, la selección de validadores para los epochs futuros no pueda cambiar. También previene el “balance brushing”, donde los validadores intentan ajustar su saldo tras ver la RANDAO para influir en la lista de proponentes del próximo epoch. El mecanismo determinista elimina este vector de ataque y simplifica mucho el análisis de seguridad. Además, permite a los clientes de consenso conocer con antelación quién propondrá los próximos bloques, lo que facilita la implementación y permite a la capa de aplicación verificar fácilmente el calendario de proponentes mediante pruebas de Merkle del beacon root.

Antes de esta propuesta, los clientes solo calculaban el proponente del slot actual. Con EIP-7917, ahora calculan de una vez la lista de proponentes de todos los slots del próximo epoch durante cada transición de epoch. Esto añade un pequeño trabajo extra, pero calcular los índices de proponentes es muy liviano, principalmente implica muestrear la lista de validadores usando la semilla. Sin embargo, los clientes deben hacer benchmarks para asegurarse de que este cálculo adicional no cause problemas de rendimiento.

EIP-7918: Tarifa base de blobs limitada por el costo de ejecución

Ethereum necesita esta propuesta porque el sistema actual de tarifas de blobs (derivado de EIP-4844) falla cuando el gas de ejecución se convierte en el principal costo para los rollups.

Actualmente, la mayoría de los rollups pagan mucho más en gas de ejecución (el costo de incluir la transacción de blob en el bloque) que en la tarifa real de blobs. Esto genera un problema: aunque Ethereum siga bajando la tarifa base de blobs, el costo total para los rollups no cambia, ya que la parte más cara sigue siendo el gas de ejecución. Así, la tarifa base de blobs sigue bajando hasta llegar al mínimo absoluto (1 wei), momento en el que el protocolo ya no puede usar la tarifa de blobs para controlar la demanda. Luego, cuando el uso de blobs sube de golpe, la tarifa tarda muchos bloques en volver a niveles normales. Esto hace que el precio sea inestable y difícil de predecir para los usuarios.

Por ejemplo, si un rollup quiere publicar sus datos, debe pagar unos 25,000,000 gwei en gas de ejecución (1,000,000 gas a 25 gwei), mientras que la tarifa de blobs es solo de unos 200 gwei. El costo total es de unos 25,000,200 gwei, casi todo por el gas de ejecución, no por la tarifa de blobs. Si Ethereum sigue bajando la tarifa de blobs, de 200 a 50, luego a 10, y finalmente a 1 gwei, el costo total apenas cambia, sigue siendo unos 25,000,000 gwei.

EIP-7918 resuelve esto introduciendo un “precio de reserva” mínimo basado en el costo de ejecución, evitando que el precio de blobs baje demasiado y haciendo que la tarifa de blobs para los rollups sea más estable y predecible.

La idea central de EIP-7918 es simple: el precio de los blobs nunca debe ser inferior a cierta cantidad de gas de ejecución (llamado BLOB_BASE_COST). El valor de calc_excess_blob_gas() se fija en 2¹³, y el mecanismo se implementa con una pequeña modificación a la función calc_excess_blob_gas().

Normalmente, esta función aumenta o reduce la tarifa base de blobs según si el blob gas usado por el bloque supera o no el objetivo. Según esta propuesta, si el precio de blobs se vuelve “demasiado bajo” respecto al gas de ejecución, la función deja de deducir el objetivo de blob gas. Así, el exceso de blob gas crece más rápido, evitando que la tarifa base de blobs siga bajando. Por tanto, la tarifa base de blobs ahora tiene un valor mínimo igual a BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB.

Para entender por qué esto es necesario, veamos la demanda de blobs. Los rollups se fijan en el costo total: costo de ejecución más costo de blobs. Si el gas de ejecución es muy caro, por ejemplo 20 gwei, aunque la tarifa de blobs baje de 2 a 0.2 gwei, el costo total apenas cambia. Esto significa que bajar la tarifa base de blobs no aumenta la demanda. En economía, esto se llama “falta de elasticidad de precio”. La curva de demanda es casi vertical: bajar el precio no aumenta la demanda.

En este caso, el mecanismo de tarifa base de blobs se vuelve ciego: sigue bajando el precio aunque la demanda no reaccione. Por eso, la tarifa base de blobs suele caer a 1 gwei. Luego, cuando la demanda sube, el protocolo necesita casi una hora de bloques llenos para que la tarifa vuelva a niveles razonables. EIP-7918 soluciona esto estableciendo un precio de reserva vinculado al gas de ejecución, asegurando que la tarifa de blobs siga teniendo sentido incluso cuando el costo de ejecución domina.

Otra razón para añadir este precio de reserva es que los nodos deben hacer mucho trabajo extra para verificar las pruebas KZG de los datos de blobs. Estas pruebas garantizan que los datos del blob coinciden con su compromiso. Bajo EIP-4844, los nodos solo verifican una prueba por blob, lo que es barato. Pero en EIP-7918, los nodos deben verificar muchas más pruebas, porque en EIP-7594 (PeerDAS), los blobs se dividen en muchas celdas, cada una con su propia prueba, aumentando mucho el trabajo de verificación.

A largo plazo, EIP-7918 también ayuda a Ethereum a prepararse para el futuro. A medida que la tecnología avanza, el costo de almacenar y compartir datos baja, y se espera que Ethereum permita almacenar más datos de blobs con el tiempo. Cuando aumente la capacidad de blobs, la tarifa de blobs (en ETH) bajará naturalmente. Esta propuesta lo apoya, ya que el precio de reserva se vincula al precio del gas de ejecución, no a un valor fijo, por lo que puede ajustarse al crecimiento de la red.

Al expandirse el espacio de blobs y el espacio de bloques de ejecución, su relación de precios se mantiene equilibrada. Solo en casos muy raros, si Ethereum aumenta mucho la capacidad de blobs pero no la de gas de ejecución, el precio de reserva podría ser demasiado alto. En ese caso, la tarifa de blobs podría superar la necesaria. Pero Ethereum no planea expandirse así: el espacio de blobs y el de bloques de ejecución crecerán juntos. Por eso, el valor elegido (BLOB_BASE_COST = 2¹³) se considera seguro y equilibrado.

Cuando el gas de ejecución sube de golpe, hay un detalle a tener en cuenta. Como el precio de blobs depende de la tarifa base de ejecución, un aumento repentino del gas de ejecución puede hacer que la tarifa de blobs quede temporalmente dominada por el costo de ejecución. Por ejemplo, si el gas de ejecución sube de 20 a 60 gwei en un bloque, el precio de blobs no puede bajar del nuevo nivel más alto. Si los blobs siguen usándose, su tarifa crecerá normalmente, pero el protocolo no permitirá que baje hasta que iguale el nuevo costo de ejecución. Esto significa que durante algunos bloques, la tarifa de blobs puede subir más lento que el costo de ejecución. Este pequeño retraso no es dañino: en realidad, ayuda a evitar oscilaciones bruscas y hace el sistema más estable.

El autor también analizó la actividad real de bloques entre noviembre de 2024 y marzo de 2025, aplicando la regla del precio de reserva. En periodos de tarifas de ejecución altas (promedio 16 gwei), el umbral de reserva elevó notablemente la tarifa base de los bloques respecto al mecanismo anterior. En periodos de tarifas bajas (promedio 1.3 gwei), la tarifa casi no cambió, salvo cuando la tarifa base calculada era inferior al precio de reserva. Comparando miles de bloques, el autor muestra que el nuevo mecanismo crea precios más estables y sigue respondiendo a la demanda. El histograma de tarifas de cuatro meses muestra que el precio de reserva evita que la tarifa caiga a 1 gwei, reduciendo la volatilidad extrema.

En cuanto a seguridad, este cambio no introduce riesgos. La tarifa base de bloque siempre será igual o superior al costo unitario de BLOB_BASE_COST de gas de ejecución. Esto es seguro porque el mecanismo solo eleva el precio mínimo, y fijar un piso de precios no afecta la corrección del protocolo. Solo asegura un funcionamiento económico saludable.

EIP-7934: Límite al tamaño de bloques de ejecución RLP

Antes de EIP-7934, Ethereum no tenía un límite estricto al tamaño de los bloques de ejecución codificados en RLP. En teoría, si un bloque contenía muchas transacciones o datos muy complejos, su tamaño podía ser enorme. Esto generaba dos problemas principales: inestabilidad de la red y riesgo de ataques de denegación de servicio (DoS).

Si un bloque es demasiado grande, los nodos tardan más en descargarlo y verificarlo, lo que ralentiza la propagación de bloques y aumenta la probabilidad de forks temporales en la blockchain. Peor aún, un atacante podría crear un bloque enorme para sobrecargar los nodos, causando demoras o incluso desconexiones, un ataque DoS típico. Además, el protocolo gossip de la capa de consenso (CL) de Ethereum ya rechaza bloques de más de 10MB, por lo que los bloques de ejecución demasiado grandes no se propagarían, causando fragmentación o desacuerdos entre nodos. Por estos riesgos, Ethereum necesita una regla clara a nivel de protocolo para evitar bloques demasiado grandes y mantener la red estable y segura.

EIP-7934 resuelve esto introduciendo un límite al tamaño de los bloques de ejecución codificados en RLP. El tamaño máximo permitido (MAX_BLOCK_SIZE) se fija en 10 MiB (10,485,760 bytes), pero como los bloques beacon también ocupan espacio (SAFETY_MARGIN), Ethereum añade un margen de seguridad de 2 MiB (2,097,152 bytes).

Esto significa que el tamaño máximo real permitido para bloques de ejecución RLP es MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN. Si el bloque codificado supera este límite, se considera inválido y los nodos deben rechazarlo. Con esta regla, los productores de bloques deben verificar el tamaño codificado de cada bloque que construyen, y los validadores deben comprobar este límite al validar bloques. Este límite es independiente del límite de gas, así que aunque un bloque esté “por debajo del límite de gas”, si su tamaño codificado es demasiado grande, será rechazado. Así se asegura que se respeten tanto el uso de gas como el límite de bytes reales.

El límite de 10 MiB se eligió a propósito porque coincide con el límite existente en el protocolo gossip de la capa de consenso. Cualquier dato mayor a 10 MiB no se propaga en la red, así que esta EIP alinea el límite de la capa de ejecución con el de la capa de consenso. Esto asegura coherencia entre componentes y evita que bloques de ejecución válidos sean “invisibles” por rechazo de la CL.

Este cambio no es retrocompatible para bloques mayores al nuevo límite, por lo que mineros y validadores deben actualizar sus clientes para cumplir la regla. Sin embargo, los bloques enormes ya eran problemáticos y poco comunes en la práctica, así que el impacto es mínimo.

En cuanto a seguridad, EIP-7934 refuerza la capacidad de Ethereum para resistir ataques DoS basados en bloques de gran tamaño, asegurando que ningún participante pueda crear bloques que paralicen la red. En resumen, EIP-7934 añade un límite de seguridad importante, mejora la estabilidad, unifica el comportamiento de la capa de ejecución (EL) y la CL, y previene varios ataques relacionados con la creación y propagación de bloques enormes.

EIP-7939: Código de operación CLZ para contar ceros a la izquierda

Antes de esta EIP, Ethereum no tenía un código de operación incorporado para contar los ceros a la izquierda en un número de 256 bits. Los desarrolladores debían implementar la función CLZ manualmente en Solidity, usando muchas operaciones de desplazamiento y comparación.

Esto era un gran problema porque las implementaciones personalizadas son lentas, costosas y ocupan mucho bytecode, aumentando el consumo de gas. Para los sistemas de pruebas de conocimiento cero, el costo es aún mayor, ya que las pruebas de desplazamiento a la derecha son muy caras, y operaciones como CLZ ralentizan mucho los circuitos de pruebas. Como CLZ es una función de bajo nivel muy común, usada en bibliotecas matemáticas, algoritmos de compresión, bitmaps, esquemas de firmas y muchas tareas criptográficas o de procesamiento de datos, Ethereum necesita una forma más rápida y económica de calcularla.

EIP-7939 resuelve esto añadiendo un nuevo código de operación llamado CLZ (0x1e). Este código lee un valor de 256 bits de la pila y devuelve el número de ceros a la izquierda. Si el número es cero, devuelve 256, ya que un cero de 256 bits tiene 256 ceros a la izquierda.

Esto es igual que en muchas arquitecturas de CPU como ARM y x86, donde CLZ es una operación nativa. Añadir CLZ reduce mucho el costo de muchos algoritmos: lnWad, powWad, LambertW, funciones matemáticas, comparación de cadenas de bytes, escaneo de bitmaps, compresión/descompresión de calldata y esquemas de firmas post-cuánticas se benefician de una detección de ceros a la izquierda más rápida.

El costo de gas de CLZ se fija en 5, igual que ADD, y un poco más alto que el de MUL, para evitar que sea demasiado barato y cause ataques DoS. Los benchmarks muestran que CLZ requiere un cálculo similar a ADD, y en entornos de pruebas SP1 rv32im, el costo de prueba de CLZ es incluso menor que el de ADD, reduciendo el costo de las pruebas de conocimiento cero.

EIP-7939 es totalmente retrocompatible, ya que introduce un nuevo código de operación y no modifica ningún comportamiento existente.

En resumen, EIP-7939 hace que Ethereum sea más rápido, barato y amigable para los desarrolladores al añadir una primitiva simple y eficiente ya soportada por CPUs modernas, reduciendo el gas, el tamaño del bytecode y el costo de pruebas de conocimiento cero para muchas operaciones comunes.

EIP-7951: Firmas compatibles con hardware moderno

Antes de esta EIP, Ethereum no tenía una forma segura y nativa de verificar firmas digitales creadas con la curva secp256r1 (P-256).

Esta curva es estándar en dispositivos modernos como Apple Secure Enclave, Android Keystore, HSM, TEE y llaves de seguridad FIDO2/WebAuthn. Por falta de soporte, aplicaciones y billeteras no podían usar fácilmente la seguridad de hardware a nivel de dispositivo para firmar. Hubo un intento previo (RIP-7212), pero tenía dos graves fallos de seguridad relacionados con el manejo del punto en el infinito y la comparación incorrecta de firmas. Estos problemas podían causar errores de verificación e incluso fallos de consenso. EIP-7951 corrige estos problemas y añade una precompilación segura y nativa, permitiendo que Ethereum soporte de forma segura y eficiente las firmas de hardware moderno.

EIP-7951 añade un nuevo contrato precompilado llamado P256VERIFY en la dirección 0x100, que realiza la verificación de firmas ECDSA usando la curva secp256r1. Esto hace que la verificación de firmas sea más rápida y barata que implementarla directamente en Solidity.

EIP-7951 también define reglas estrictas de validación de entradas. Si hay algún caso inválido, la precompilación devuelve fallo sin revertir, consumiendo el mismo gas que una llamada exitosa. El algoritmo de verificación sigue el estándar ECDSA: calcula s⁻¹ mod n, reconstruye el punto de la firma R', si R' es el punto en el infinito lo rechaza, y finalmente verifica si la coordenada x de R' coincide con r (mod n). Esto corrige el error de RIP-7212, que comparaba r' directamente en vez de reducirlo módulo n.

El costo de gas de esta operación se fija en 6900 gas, más alto que la versión de RIP-7212, pero acorde con el rendimiento real de la verificación secp256r1. Importante: la interfaz es totalmente compatible con las redes Layer 2 que ya desplegaron RIP-7212 (misma dirección y formato de entrada/salida), así que los contratos inteligentes existentes seguirán funcionando sin cambios. La única diferencia es el comportamiento corregido y el mayor costo de gas.

Desde el punto de vista de la seguridad, EIP-7951 restaura el comportamiento correcto de ECDSA, elimina problemas de maleabilidad a nivel de precompilación (dejando los chequeos opcionales a la aplicación) y aclara que la precompilación no necesita ejecución en tiempo constante. La curva secp256r1 ofrece 128 bits de seguridad y ha sido ampliamente analizada y confiable, por lo que es segura para Ethereum.

En resumen, EIP-7951 busca introducir de forma segura la autenticación soportada por hardware moderno en Ethereum, corrigiendo los problemas de seguridad de propuestas anteriores y proporcionando una forma fiable y estandarizada de verificar firmas P-256 en todo el ecosistema.

Resumen

La siguiente tabla resume qué clientes de Ethereum deben actualizarse para cada EIP de Fusaka. Una marca en la columna de clientes de consenso indica que la EIP requiere actualización del cliente de consenso, mientras que una marca en la columna de clientes de ejecución indica que la actualización afecta al cliente de ejecución. Algunas EIP requieren actualización en ambas capas, otras solo en una.

En resumen, estos son los EIP clave incluidos en la bifurcación dura Fusaka. Aunque la actualización abarca múltiples mejoras en los clientes de consenso y ejecución —desde ajustes de gas y actualización de códigos de operación hasta nuevas precompilaciones— el núcleo de la actualización es PeerDAS, que introduce el muestreo de disponibilidad de datos punto a punto, permitiendo un manejo más eficiente y descentralizado de los datos de blobs en toda la red.