Fusaka: El salto evolutivo de Ethereum hacia la escalabilidad infinita después de Pectra

Tras el éxito de la actualización Pectra, la comunidad de Ethereum se prepara para el próximo gran paso. El 3 de diciembre de 2025 llegará Fusaka, un hard fork que encarna la visión de la red de alcanzar una escalabilidad prácticamente ilimitada. El propio nombre refleja esta ambición: Fusaka combina “Fulu” (capa de ejecución) y “Osaka” (capa de consenso), simbolizando la integración de los dos pilares del protocolo.

Por qué Fusaka es crucial para el futuro de los Layer 2

Los últimos años han mostrado cómo los Rollup Layer 2 se han convertido en la solución principal para los altos costes en Ethereum mainnet. Sin embargo, estos protocolos aún enfrentan obstáculos significativos: las tarifas siguen siendo demasiado altas en periodos de congestión, y la arquitectura de la red no está aún optimizada para manejar volúmenes masivos de datos. Fusaka aborda directamente estos problemas mediante nueve propuestas de mejora (EIP), cada una diseñada para potenciar un aspecto específico de la red.

PeerDAS (EIP-7594): Cómo Ethereum verificará los datos sin sobrecargar los nodos

La introducción de EIP-4844 ha revolucionado la disponibilidad de datos, pero ha creado una nueva restricción: cada nodo debe descargar enormes cantidades de datos blob para verificar su autenticidad. Esto pone en peligro la descentralización de la red. Los requisitos de banda aumentan, el nivel de descentralización disminuye, y los validadores pequeños tienen dificultades para mantenerse al día.

PeerDAS (EIP-7594) resuelve este dilema permitiendo a los nodos verificar la integridad de los datos descargando solo fragmentos aleatorios, en lugar de todo el conjunto de datos. El mecanismo funciona dividiendo cada blob en pequeñas unidades llamadas “celdas”, organizadas en columnas. Cada nodo es responsable de algunas columnas específicas y toma muestras de otras de los pares. Si un nodo recopila al menos el 50% de las columnas totales (por ejemplo, 32 de 64), puede reconstruir completamente el blob gracias a un código de eliminación que añade redundancia a los datos.

Este enfoque crea un equilibrio: los validadores, con hardware más potente, pueden almacenar volúmenes mayores y actuar como puntos de anclaje de la red. Los nodos ordinarios permanecen como participantes activos sin soportar toda la carga computacional. ¿El resultado? Ethereum puede aumentar significativamente la capacidad de blobs manteniendo bajos los requisitos de hardware para los participantes.

Una regla importante acompaña esta novedad: ninguna transacción puede contener más de 6 blobs. Este límite protege el sistema de abusos y distribuye mejor la carga en la red.

Repricing del gas: MODEXP y los límites de seguridad

Tres EIP abordan el delicado tema del precio del gas, cada uno enfrentando problemas específicos en el mecanismo de precompilada MODEXP.

EIP-7823: Poner freno a los datos MODEXP

La precompilada MODEXP de Ethereum ha aceptado históricamente entradas de tamaño teóricamente ilimitado. Esto ha causado numerosas vulnerabilidades de consenso: cada cliente implementaba la función de manera diferente, las pruebas se volvían imposibles, y la fórmula de precios era impredecible.

EIP-7823 introduce una regla simple pero fundamental: la base, el exponente y el módulo no pueden superar los 1024 bytes (8192 bits). Este límite es seguro para todas las aplicaciones prácticas—la criptografía RSA usa claves de hasta 4096 bits, las curvas elípticas aún menos. Analizando la historia de la blockchain desde 2018 hasta enero de 2025, ninguna llamada a MODEXP exitosa ha superado los 513 bytes. Por lo tanto, el cambio no invalida transacciones históricas ni introduce nuevos riesgos, sino que elimina casos patológicos que amenazaban la estabilidad de la red.

EIP-7825: El límite máximo de gas por transacción

Otra vulnerabilidad estructural: una sola transacción puede consumir casi todo el gas disponible en un bloque (40 millones). Si alguien envía una transacción de 38 millones de gas, el bloque se vuelve prácticamente inutilizable para otras transacciones, creando un efecto similar a un ataque de denegación de servicio.

EIP-7825 fija un límite riguroso de 16.777.216 de gas (2²⁴) por transacción, independientemente del límite total del bloque. Esto asegura que cada bloque contenga naturalmente más transacciones, previniendo el monopolio de una sola operación. La elección de 2²⁴ no es arbitraria: es una potencia de 2 (fácil de implementar), lo suficientemente grande para contratos complejos, y aproximadamente la mitad del tamaño típico de un bloque.

El impacto en la comunidad es mínimo—casi todas las transacciones actuales consumen mucho menos de 16 millones de gas. Solo operaciones extremas deberán dividirse en múltiples pasos.

EIP-7883: Recalcular el coste real de MODEXP

Las operaciones MODEXP han sido históricamente subvaloradas respecto a su coste computacional real. Esto crea un cuello de botella: los productores de bloques procesan cálculos pesados por recompensas irrisorias, y los atacantes pueden llenar bloques con operaciones costosas sin gastar mucho.

Usando una fórmula empírica actualizada, EIP-7883 aumenta el coste mínimo de 200 a 500 gas y triplica los costes generales, con penalizaciones aún mayores para operaciones con entradas superiores a 32 bytes. El coste de operaciones con números grandes puede aumentar hasta 76-80 veces. El 99,69% de las llamadas históricas verá al menos un aumento triple. Esto no cambia el funcionamiento de MODEXP, sino que alinea el precio con el trabajo real requerido.

Estabilidad de los blobs y previsión de los proponentes

EIP-7918: Vincular la tarifa de los blobs al coste de ejecución

Las tarifas de los blobs (introducidas por EIP-4844) fluctúan salvajemente. Cuando el gas de ejecución domina el coste total para los Rollup, reducir la tarifa base de los blobs no aumenta la demanda—un fenómeno económico llamado demanda inelástica. El protocolo continúa bajando el precio hasta 1 gwei (el mínimo absoluto), momento en el que el mecanismo deja de funcionar.

EIP-7918 introduce un “precio de reserva” mínimo calculado como BLOB_BASE_COST × tarifa_base_por_gas ÷ GAS_POR_BLOB. Esto garantiza que la tarifa base de los blobs mantenga siempre una relación sensata con el coste de ejecución, creando estabilidad previsible para los Rollup. Un análisis empírico de cuatro meses de datos blockchain confirma que el nuevo mecanismo previene caídas a 1 gwei y reduce drásticamente la volatilidad.

EIP-7917: Hacer que la planificación de los proponentes sea completamente determinista

La selección de validadores proponentes para epoch futuros no es actualmente predecible. Incluso conociendo la semilla RANDAO, cambios en los saldos efectivos (EB) durante un epoch pueden alterar la lista de proponentes del siguiente epoch. Esto crea problemas para los protocolos de pre-confirmación y abre espacios a manipulaciones.

EIP-7917 resuelve el problema introduciendo un mecanismo determinista que calcula y almacena la planificación de los proponentes para los próximos dos epochs completos al inicio de cada epoch. Una vez determinada, la lista no cambia más debido a actualizaciones EB tardías. Esta previsibilidad es esencial para la estabilidad de Layer 2 y previene el “balance brushing”—intentos de los validadores de manipular sus saldos tras ver el RANDAO.

Seguridad y eficiencia de la red

EIP-7934: Un límite al tamaño de los bloques

Sin límites en el tamaño RLP de los bloques, un atacante puede crear bloques gigantes que paralizan los nodos y ralentizan la propagación. EIP-7934 fija el límite máximo en 10 MiB (con un margen de seguridad de 2 MiB), alineándose con el límite ya vigente en el protocolo gossip de la capa de consenso. Esto elimina incoherencias entre las capas y previene ataques DoS basados en tamaños excesivos.

EIP-7939: El opcode CLZ para operaciones rápidas en bits

Los desarrolladores han tenido que implementar manualmente funciones de conteo de ceros iniciales en Solidity, consumiendo gas excesivo y bytecode voluminoso. EIP-7939 introduce un nuevo opcode nativo CLZ (0x1e) a un coste de 5 gas, igual que ADD. Esto acelera librerías matemáticas, algoritmos de compresión, bitmap, esquemas de firma y operaciones criptográficas, reduciendo tarifas y costes de las pruebas de conocimiento cero.

EIP-7951: Soporte nativo para firmas hardware modernas

Apple Secure Enclave, Android Keystore, FIDO2/WebAuthn y dispositivos de seguridad hardware usan la curva secp256r1 (P-256). EIP-7951 introduce una precompilada P256VERIFY en la dirección 0x100, permitiendo a Ethereum verificar firmas ECDSA en la curva P-256 de forma segura y nativa, a un coste de 6900 gas. Esto corrige vulnerabilidades de seguridad de la propuesta anterior (RIP-7212) y finalmente permite a los usuarios acceder a wallets soportados por hardware moderno con la misma sencillez de Ethereum.

Conclusión: La infraestructura escalable del mañana

Fusaka no es un cambio revolucionario único, sino una serie coordinada de mejoras que abordan restricciones específicas de la red. PeerDAS habilita la escalabilidad de datos, los repricing del gas aseguran estabilidad económica, la previsibilidad de los proponentes refuerza la predictibilidad, y las nuevas primitivas optimizan la eficiencia.

El resultado es una Ethereum preparada para el futuro: los Layer 2 Rollup podrán operar a menores costes y mayor velocidad, los nodos permanecen descentralizados gracias a los mecanismos de muestreo, y la seguridad de la red se cimenta en límites e incentivos bien calibrados. Cuando Fusaka se active el 3 de diciembre de 2025, marcará formalmente la transición hacia la infraestructura de escalabilidad infinita que Ethereum siempre ha prometido.