Ethereum podría operar pronto al doble de su velocidad actual, tras una propuesta del desarrollador principal, Barnabé Monnot, de reducir el tiempo de ranura de la red a la mitad, de 12 a 6 segundos. La Propuesta de Mejora Ethereum (EIP) 7782 podría incorporarse en la próxima actualización "Glamsterdam", prevista para 2026.
Según un artículo Ethereum Magicians , escrito por Monnot, si se implementa el cambio de horario, podría reducir el tiempo que tarda la Ethereum en finalizar transacciones y añadir nuevos bloques a la red principal. Esto mejorará el rendimiento y la usabilidad de la blockchain para aplicaciones descentralizadas (dApps), billeteras y protocolos defi
Reducir a la mitad el tiempo de espera para aumentar la velocidad de confirmación
Ethereum opera actualmente con un ciclo de ranura de 12 segundos. Con el cambio propuesto, este se reduciría a tan solo 6 segundos, duplicando la cantidad de bloques producidos por minuto.
Monnot afirma que esta aceleración podría mejorar la experiencia del usuario al ofrecer datos más actualizados y confirmaciones más rápidas , con claras ventajas para defi , como ventanas de arbitraje más pequeñas, tarifas comerciales reducidas y mayor liquidez.
En los mercados de pruebas, el trabajo puede paralelizarse en gran medida, de modo que un solo probador lógico podría obtener subpruebas de muchos otros probadores. Aun así, reducir el tiempo de ranura significa ofrecer más oportunidades por unidad de tiempo para competir por el derecho a proporcionar la prueba de un bloque , escribió.
El ajuste de red propuesto divide el intervalo de 6 segundos en tres subprocesos más pequeños: 3 segundos para propuestas de bloques, 1,5 segundos para atestaciones y 1,5 segundos para agregación. Esto preservaría la funcionalidad total del intervalo y, al mismo tiempo, aumentaría el rendimiento en la capa de protocolo.
El desarrollador de Ether reiteró que el cambio no afectaría la emisión total a los validadores. En cambio, los stakers recibirían recompensas menores, pero más frecuentes, debido a una menor varianza de las recompensas y a la reducción de incentivos para los pools de staking. Añadió que esto favorecerá a los stakers individuales o a los operadores domésticos que se enfrentan a rendimientos impredecibles en el sistema actual.
Compensaciones y obstáculos técnicos
Monnot mencionó que los tiempos de procesamiento más cortos obligarán a los desarrolladores a implementar lógica condicional dentro de los clientes Ethereum y la infraestructura relacionada para lograr compatibilidad con versiones anteriores.
Dado que la red ha funcionado con intervalos de 12 segundos desde su transición a Prueba de Participación, debe reproducir bloques antiguos con una sincronización constante. Algunos podrían necesitar pasar del tracen segundos a milisegundos, como se hizo en la cadena Gnosis.
Algunos clientes empiezan a construir bloques desde el principio de un turno. Con solo tres segundos para la fase de propuesta, cualquier retraso podría reducir el tiempo de producción , explicó.
Aun así, Monnot señaló que la proporción relativa del tiempo de producción de bloques dentro de una ranura en realidad aumenta, de 4 de 12 segundos actualmente, a 3 de 6 segundos con el nuevo modelo.
Escalabilidad versus velocidad y preconfirmaciones
La comunidad de desarrollo de Ethereumdebate las ventajas de aumentar el rendimiento de la Capa 1 frente a optimizar la velocidad de finalización. Monnot admitió que las ranuras más cortas no escalan directamente el rendimiento del gas, pero pueden mejorar la capacidad de respuesta de la cadena. También citó evidencia de la preferencia de los usuarios por confirmaciones más rápidas en lugar de tamaños de bloque más escalables.
Los mecanismos de preconfirmación, soluciones de una confirmación provisional más rápida fuera del protocolo central, son una opción, pero Monnot afirmó que los desarrolladores prefieren cambios dentro del protocolo como EIP-7782.
Una de las tareas más complejas en la ejecución de la propuesta implica actualizar el software del cliente y las herramientas de infraestructura, como los exploradores de bloques. Estas herramientas deben adaptarse tanto a la antigua duración de 12 segundos como a la nueva de 6 segundos. Los desarrolladores deberán asegurarse de que los clientes apliquen la lógica correcta según procesen bloques históricos o nuevos. Al momento de la publicación, aún no se había completado el análisis completo de estos cambios.
