Bitget App
Opera de forma inteligente
Comprar criptoMercadosTradingFuturosEarnCentralMás
La hoja de ruta de Ethereum para 2026 incluye este riesgo para los validadores que es mayor de lo que piensas

La hoja de ruta de Ethereum para 2026 incluye este riesgo para los validadores que es mayor de lo que piensas

CryptoSlateCryptoSlate2025/12/28 14:14
Show original
By:CryptoSlate

La hoja de ruta de Ethereum para 2026 se centra en dos vías: ampliar la capacidad de datos de rollup mediante blobs mientras se impulsa una mayor ejecución en la capa base a través de cambios en el límite de gas.

Estos cambios en el límite de gas dependen de que los validadores pasen de reejecutar bloques a verificar pruebas de ejecución ZK.

La primera vía ya está anclada por Fusaka, que fue lanzada el 3 de diciembre de 2025.

Fusaka

Según ethereum.org, establece PeerDAS más cambios solo en el parámetro de blob (BPO) que pueden aumentar el rendimiento de blobs en pasos medidos.

La segunda vía es menos mecanizada porque depende de EIPs en borrador, implementación de clientes y operaciones de validadores que deben mantenerse dentro de las restricciones de descentralización, incluyendo ancho de banda, propagación de bloques y estructura de mercado de pruebas.

PeerDAS se posiciona como la palanca más clara de “aumento de capacidad” porque está diseñado para escalar la disponibilidad de datos de rollup sin obligar a que cada nodo descargue cada blob.

Según ethereum.org, los objetivos de blobs no aumentan inmediatamente tras la activación, y luego pueden duplicarse cada pocas semanas hasta un objetivo máximo de 48 mientras los desarrolladores monitorean la salud de la red.

El equipo de Optimism enmarcó el caso de gama alta como “al menos 48 blobs objetivo por bloque”, acompañado de un movimiento de rendimiento en el rollup de aproximadamente 220 a unos 3,500 UOPS bajo ese objetivo.

Incluso en ese marco, la cuestión práctica para 2026 es si la demanda llega en forma de uso de blobs en lugar de aumentar las pujas por la ejecución en L1.

Otra pregunta abierta es si la estabilidad p2p y el ancho de banda de los nodos permanecen dentro de las tolerancias de los operadores a medida que el BPO incrementa el despliegue.

En el lado de la ejecución, Ethereum ya está probando un mayor rendimiento mediante coordinación en lugar de una bifurcación dura.

GasLimit.pics informó de un límite de gas más reciente de 60,000,000, con un promedio de 24 horas de aproximadamente 59,990,755 en el momento mostrado.

Este nivel importa porque proporciona un punto de referencia sobre lo que los validadores han aceptado en la práctica.

También expone el techo del “escalado social” antes de que la latencia, la carga de validación y la tensión en el mempool y en la canalización MEV se vuelvan vinculantes.

Una forma sencilla de traducir el discurso sobre el límite de gas en rangos de rendimiento es gas por segundo, utilizando el tiempo de intervalo de 12 segundos de Ethereum (gas por segundo es igual al límite de gas dividido por 12).

Las cifras a continuación mantienen las matemáticas explícitas y separan las transacciones EVM de la capa base de las afirmaciones de rendimiento de rollup.

Gas de Ethereum
Escenario Límite de gas Gas/seg (≈ gas/12) Tx/seg a 21k gas Tx/seg a 120k gas
Nivel de coordinación actual 60,000,000 5,000,000 ≈238 ≈42
Escenario de 2× límite de gas 120,000,000 10,000,000 ≈476 ≈83
Escenario de gama alta (requiere cambio de validación) 200,000,000 16,666,667 ≈793 ≈139

Glamsterdam

La actualización planificada para 2026 reúne varias ideas orientadas a la ejecución bajo el nombre de “Glamsterdam”, un conjunto resumido que se ha discutido en torno a la separación consagrada de proponente-constructor (ePBS, EIP-7732), Listas de Acceso a Nivel de Bloque (BALs, EIP-7928) y una nueva valoración general (EIP-7904).

Cada una permanece en forma de borrador, según las páginas EIP de EIP-7732, EIP-7928 y EIP-7904.

La nueva valoración está dirigida a desajustes en el esquema de gas que han persistido durante años.

Según EIP-7904, se argumenta que corregir el cálculo erróneo de la computación puede aumentar el rendimiento utilizable, reconociendo el riesgo de DoS y la realidad de los contratos que codifican supuestos de gas.

Las BALs se consideran como infraestructura para el paralelismo.

El EIP menciona lecturas paralelas de disco, validación paralela de transacciones, cálculo paralelo de la raíz de estado y “actualizaciones de estado sin ejecución”, estimando un tamaño promedio comprimido de BAL de aproximadamente 70 a 72 KiB como sobrecarga, según EIP-7928.

En la práctica, esas ganancias solo se materializan si los clientes adoptan la concurrencia en los verdaderos cuellos de botella.

También dependen de si los datos y pasos de verificación adicionales evitan convertirse en su propio impuesto de latencia.

ePBS está en el centro de las discusiones tanto de MEV como de rendimiento porque busca desacoplar la validación de la ejecución de la validación de consenso en el tiempo, según EIP-7732.

Esa flexibilidad temporal también es donde pueden aparecer nuevos modos de fallo.

Un artículo académico sobre el “problema de la opción gratuita” para ePBS estima el ejercicio de opciones en aproximadamente el 0,82% de los bloques en promedio bajo una ventana de opción de 8 segundos, llegando al 6% en días de alta volatilidad en sus condiciones modeladas, según arXiv.

Ethereum en 2026

Para la planificación de 2026, esa investigación dirige la atención hacia la vivacidad bajo estrés, no solo los resultados de tarifas en estado estable.

La apuesta más estructural detrás de los límites de gas “muy altos” es la adopción de pruebas ZK por parte de los validadores.

La hoja de ruta “Realtime Proving” de la Ethereum Foundation describe un camino escalonado donde un pequeño conjunto de validadores primero ejecuta clientes ZK en producción.

Luego, solo después de que una supermayoría de participaciones esté cómoda, los límites de gas pueden aumentar a niveles donde la verificación de pruebas reemplace la reejecución para la validación práctica en hardware razonable, según la publicación de la fundación del 10 de julio de 2025 en blog.ethereum.org.

La misma publicación establece restricciones que importan para la viabilidad más que para la narrativa, incluyendo un objetivo de seguridad de 128 bits (con 100 bits aceptados temporalmente), tamaño de prueba menor a 300 KiB y evitar depender de envoltorios recursivos con configuraciones confiables, según blog.ethereum.org.

La implicación de escalabilidad está ligada a los mercados de pruebas: el suministro de pruebas en tiempo real debe ser barato y creíble sin concentrarse en un conjunto reducido de probadores que recreen las dependencias actuales tipo relay en otra capa del stack.

Después de Glamsterdam, “Hegota” se posiciona como una franja con nombre para finales de 2026 que todavía trata más sobre el proceso que sobre el alcance.

La Ethereum Foundation publicó una línea de tiempo principal con una ventana de propuestas del 8 de enero al 4 de febrero, seguida de una discusión y finalización del 5 al 26 de febrero, y luego una ventana para propuestas no principales, según blog.ethereum.org.

Existe un meta-EIP de Hegotá como borrador (EIP-8081) que enumera elementos como considerados en lugar de fijados, incluyendo FOCIL (EIP-7805) como actualmente considerado, según EIP-8081.

El valor de reporte a corto plazo en ese cronograma es que crea puntos de decisión con fecha que los inversores y desarrolladores pueden rastrear sin inferir compromisos a partir de nombres en clave.

El primero es que las propuestas principales de Hegota se cierran el 4 de febrero.

La publicación La hoja de ruta de Ethereum para 2026 incluye este riesgo de validadores que es mayor de lo que piensas apareció primero en CryptoSlate.

0
0

Disclaimer: The content of this article solely reflects the author's opinion and does not represent the platform in any capacity. This article is not intended to serve as a reference for making investment decisions.

PoolX: Haz staking y gana nuevos tokens.
APR de hasta 12%. Gana más airdrop bloqueando más.
¡Bloquea ahora!
© 2025 Bitget