## Ethereum enfrenta una encrucijada crítica en su hoja de ruta 2026: el desafío oculto para los validadores

La estrategia de escalabilidad de Ethereum para 2026 se bifurca en dos caminos simultáneos. Por un lado, se amplía la capacidad de datos mediante blobs; por otro, se busca elevar el rendimiento de la capa base ajustando los parámetros de gas. La complejidad radica en que ambos objetivos dependen de cambios fundamentales en cómo los validadores procesan y verifican información. Esta transición silenciosa esconde riesgos operacionales mayores de lo que sugieren los titulares técnicos.

## El debut de Fusaka: primer paso en la hoja de ruta

Fusaka, lanzada el 3 de diciembre de 2025, marca el hito inicial. Esta actualización implementa PeerDAS junto con ajustes granulares en los parámetros de blob (BPO). A diferencia de los cambios radicales, este enfoque permite aumentar el rendimiento por etapas medidas, permitiendo que la red se adapte progresivamente.

PeerDAS es la palanca más directa para incrementar capacidad: permite que los rollups accedan a mayor disponibilidad de datos sin obligar a cada nodo a descargar todos los blobs. Inicialmente, los objetivos de blobs no se elevan de inmediato tras la activación. Posteriormente, pueden duplicarse cada pocas semanas hasta alcanzar un máximo objetivo de 48 blobs por bloque, siempre bajo supervisión de la salud de la red.

Los datos del equipo Optimism proyectan un rendimiento en rollups que se multiplicaría: aproximadamente de 220 a cerca de 3,500 UOPS bajo ese objetivo de 48 blobs. No obstante, una pregunta práctica persiste para 2026: ¿llegará la demanda real en forma de uso de blobs, o las pujas por ejecución en L1 seguirán dominando? Además, la estabilidad P2P y el consumo de ancho de banda de los nodos deben mantenerse dentro de tolerancias operacionales mientras BPO aumenta.

## El techo del escalado social: métricas de gas que importan

En paralelo, Ethereum experimenta con mayor rendimiento mediante coordinación en lugar de bifurcaciones duras. El registro más reciente muestra un límite de gas de 60,000,000, con un promedio de 24 horas cercano a 59,990,755. Este nivel actúa como punto de referencia de lo que los validadores han aceptado practicar. También expone el límite del "escalado social" antes de que latencia, carga de validación, tensión en mempool y competencia MEV se vuelvan limitantes.

Convertir estas cifras de gas a rendimiento utiliza el intervalo de bloques de 12 segundos de Ethereum. La tabla de escenarios revela:

**Escenario Actual de Coordinación**: 60,000,000 de límite de gas = ~5,000,000 gas/segundo = ~238 transacciones/segundo (a 21k gas) o ~42 transacciones/segundo (a 120k gas).

**Escenario 2× límite de gas**: 120,000,000 de límite = ~10,000,000 gas/segundo = ~476 tx/s (a 21k) o ~83 tx/s (a 120k).

**Escenario de rendimiento máximo** (requiere cambio de validación): 200,000,000 de límite = ~16,666,667 gas/segundo = ~793 tx/s (a 21k) o ~139 tx/s (a 120k).

Estas escalas representan el espectro teórico, pero cada nivel introduce complejidades operacionales que los validadores deben absorber.

## Glamsterdam: la convergencia de tres frentes de ejecución

El nombre clave "Glamsterdam" agrupa múltiples propuestas orientadas a optimizar ejecución bajo una sombrilla conceptual. Tres elementos clave permanecen en estado de borrador según sus respectivas páginas EIP:

**ePBS (EIP-7732) — Proposición-Construcción Separadas Encriptadas**: Desacopla temporalmente la validación de ejecución de la validación de consenso. Esta flexibilidad temporal, aunque poderosa para el rendimiento, es precisamente donde pueden gestarse nuevos modos de fallo. Investigación académica sobre el "problema de la opción gratuita" estima que los validadores ejercerían opciones en aproximadamente el 0,82% de los bloques bajo condiciones normales, pero este porcentaje salta al 6% durante días de alta volatilidad. Estos episodios de ejercicio de opción representan momentos donde la red experimenta presión no lineal.

**BALs (EIP-7928) — Listas de Acceso a Nivel de Bloque**: Se posicionan como infraestructura para paralelismo. La propuesta contempla lecturas paralelas de disco, validación concurrente de transacciones, cálculo paralelo de raíz de estado y "actualizaciones de estado sin ejecución". El overhead promedio estimado es de 70-72 KiB comprimido por bloque. La brecha entre teoría y práctica es significativa: estas ganancias solo materializan si los clientes implementan verdadera concurrencia en los cuellos de botella reales. Además, los datos y pasos de verificación adicionales no pueden convertirse en su propio impuesto de latencia.

**Revaluación General (EIP-7904)**: Aborda desajustes crónicos en el esquema de gas que han persistido años. La corrección de cálculos erróneos de computación podría aumentar el rendimiento utilizable, pero conlleva riesgos de ataques de negación de servicio y la realidad de contratos que codifican supuestos de gas específicos.

## El riesgo verdadero: la carga sobre los validadores

Aquí está el riesgo que supera lo evidente: la transición desde reejecutar bloques hacia verificar pruebas ZK no es solo un cambio técnico, sino una transformación operacional profunda para los validadores.

La hoja de ruta "Realtime Proving" de la Ethereum Foundation describe un despliegue escalonado donde primero un pequeño grupo de validadores ejecuta clientes ZK en producción. Solo después de que una supermayoría de stake se sienta cómoda, los límites de gas pueden elevarse a niveles donde la verificación de pruebas reemplace la reejecución como mecanismo práctico en hardware razonable.

Las restricciones técnicas importan más que la narrativa: objetivo de seguridad de 128 bits (con 100 bits aceptados temporalmente), tamaño de prueba menor a 300 KiB, y evitar dependencias de envoltorios recursivos con configuraciones de confianza. Más críticamente, la escalabilidad vinculada a mercados de pruebas requiere que el suministro de pruebas sea económico y creíble sin concentrarse en un pequeño conjunto de probadores que recrearían dependencias tipo relay en otra capa del stack.

## Hegota: cronograma visible para decisiones cruciales

Tras Glamsterdam, "Hegota" emerge como una etiqueta para finales de 2026, aunque su alcance sigue siendo procesual más que definido. La Ethereum Foundation estableció un cronograma explícito: ventana de propuestas principales del 8 de enero al 4 de febrero, seguida de discusión y finalización del 5 al 26 de febrero, con una ventana posterior para propuestas no principales.

El meta-EIP de Hegota (EIP-8081) en estado borrador enumera elementos "considerados" en lugar de fijados, incluyendo FOCIL (EIP-7805) actualmente bajo consideración. El valor inmediato reside en crear puntos de decisión con fecha que inversores y desarrolladores pueden rastrear sin inferir compromisos de nombres en clave. El primer hito crítico: las propuestas principales de Hegota se cierran el 4 de febrero.

## La conclusión: una hoja de ruta que demanda adaptación operacional

La hoja de ruta de Ethereum para 2026 no presenta solo cambios técnicos, sino una reconfiguración del rol del validador. La transición desde coordinación de rendimiento social hacia dependencia de pruebas ZK, combinada con aumentos de gas y mayor procesamiento paralelo, crea una ventana de vulnerabilidad operacional. Los validadores no solo necesitan nueva infraestructura; deben confiar en mercados de pruebas que aún no existen a escala. Esta es la premisa silenciosa que hace que los riesgos sean mayores de lo que aparentan en retrospectiva técnica.