El equipo de protocolo de Ethereum trabaja con el objetivo de diciembre de 2029 para hacer que las capas de ejecución, consenso y datos de la red sean resistentes a los ataques cuánticos, utilizando como supuesto de planificación que el “Q-day” —el momento en que los ordenadores cuánticos puedan romper la criptografía ampliamente utilizada— podría llegar en 2030.
El calendario situaría la capacidad poscuántica completa en una actualización conocida como L*, la quinta bifurcación dura después de Glamsterdam, cuyo despliegue en la red principal está previsto para diciembre de 2026. El equipo de protocolo de la Fundación Ethereum planea reevaluar los avances de la computación cuántica en enero de 2027, pero ha tratado el objetivo de 2029 como la fecha límite de ingeniería operativa, en lugar de considerarlo una meta de investigación lejana.
Este calendario deja a Ethereum intentando realizar varios cambios importantes de protocolo en paralelo. Entre Glamsterdam y L*, la red tendría que lanzar Hegotá, I*, J*, K* y L* con un intervalo medio de aproximadamente 7,2 meses. El equipo no ha fijado fechas concretas de lanzamiento en la red principal para las actualizaciones posteriores a Glamsterdam, y el orden de algunos trabajos cuánticos posteriores sigue en revisión.
Una ruta comprimida hacia un Ethereum resistente a la computación cuántica
Hegotá serviría como el primer punto de entrega del programa, aunque no está diseñado como una bifurcación dura poscuántica propiamente dicha. Los equipos de clientes esperan comenzar el trabajo inicial de implementación a finales de 2026, mientras que la investigación, las especificaciones técnicas, los prototipos y las pruebas de seguridad para las actualizaciones posteriores avanzarían al mismo tiempo.
La hoja de ruta divide la transición cuántica en etapas, en lugar de intentar sustituir todos los componentes criptográficos vulnerables en un solo lanzamiento. Se espera que I* introduzca un registro de claves públicas poscuánticas, ofreciendo a las cuentas una forma de registrar y utilizar claves resistentes a la computación cuántica. También es el punto en el que se está considerando el “consenso desacoplado” como dirección principal, junto con los primeros trabajos sobre cambios importantes en la estructura de estado de Ethereum y su proceso de migración.
Está previsto que J* introduzca una Capa 1 poscuántica mínima viable, o MV-PQ. El paquete combinaría un mecanismo de “latido” poscuántico para el consenso, un muestreo leanDA poscuántico para la capa de disponibilidad de datos de Ethereum y transacciones leanSPHINCS poscuánticas para la ejecución.
K* tiene asignadas actualmente pruebas de ejecución obligatorias. Según este diseño, los validadores pasarían a verificar pruebas criptográficas sucintas de la ejecución de los bloques, en lugar de volver a ejecutar completamente cada bloque por su cuenta. Este enfoque podría modificar el papel computacional de los validadores y, al mismo tiempo, preparar a Ethereum para un entorno de ejecución más orientado a las pruebas.
L* añadiría mensajes de atestación poscuánticos, completando la protección prevista para la capa de consenso de Ethereum. El orden no está decidido: los investigadores del protocolo están considerando trasladar las atestaciones resistentes a la computación cuántica a K* y posponer las pruebas de ejecución obligatorias a L*. Cualquiera de las dos secuencias mantendría L* como el punto objetivo para lograr una cobertura completa de los sistemas de ejecución, consenso y datos.
Hegotá limita su alcance inicial a dos propuestas obligatorias
El equipo del protocolo ha clasificado las 62 propuestas candidatas para Hegotá en grupos de prioridad. Dos pertenecen al nivel S obligatorio, 15 están clasificadas como trabajo de alta prioridad del nivel A, ocho se sitúan en el nivel B condicional, siete quedan por debajo del umbral de inclusión en el nivel C, 28 están marcadas como «no incluir en la bifurcación» y dos siguen sin decidirse.
Los dos elementos obligatorios de Hegotá son EIP-7805, listas de inclusión impuestas por la elección de bifurcación, o FOCIL, y EIP-8141, transacciones Frame.
FOCIL añadiría reglas de inclusión de transacciones impuestas por los validadores al proceso actual de construcción de bloques de Ethereum. En cada intervalo, un comité publicaría listas de transacciones visibles para sus miembros. El constructor del bloque del intervalo siguiente agregaría las listas e incluiría las transacciones que cumplieran los requisitos, mientras que los validadores que realizaran atestaciones comprobarían si el bloque propuesto cumplía las listas que hubieran recibido a tiempo.
Un bloque que omita transacciones incluidas en las listas y que cumplan los requisitos, sin un motivo permitido, podría seguir siendo válido según las reglas de ejecución de Ethereum, pero no recibir suficiente respaldo de atestaciones para pasar a formar parte de la cadena canónica. El diseño otorga a los validadores un papel más directo para resistir la censura de transacciones sin sustituir el flujo actual de producción de bloques.
EIP-8369 establece qué transacciones pueden optar a una inclusión al estilo de FOCIL. Distingue las transacciones convencionales de las transacciones Frame, cuya verificación programable puede requerir límites sobre el estado que leen y el cómputo que consumen.
Frames, propuestos en el marco de la EIP-8141, harían que la validación, la ejecución y el pago del gas de las transacciones fueran más programables a nivel del protocolo. La propuesta proporciona una base para la abstracción nativa de cuentas, permitiendo que las cuentas utilicen una lógica de validación personalizada en lugar de depender únicamente del modelo de firmas asociado a las cuentas controladas externamente.
Esa flexibilidad también forma parte de la estrategia de migración de Ethereum. La validación programable podría permitir que las cuentas adopten nuevos esquemas de firma a medida que cambien las condiciones criptográficas, reduciendo la necesidad de una bifurcación dura independiente cada vez que Ethereum necesite admitir un método de autenticación diferente.
La migración de cuentas y la resistencia a la censura convergen
Frames depende de dos propuestas de nivel A: EIP-8250, Keyed Nonces, y EIP-8272. Keyed Nonces permitiría que un emisor opere con múltiples canales de nonce independientes, reduciendo el riesgo de que una transacción retrasada bloquee actividad no relacionada de la misma cuenta. EIP-8272 permitiría que las transacciones hicieran referencia a estados recientes de la cadena que los validadores puedan verificar.
El equipo del protocolo vincula esa capacidad de referencia de estados con los esfuerzos por ampliar las garantías de inclusión a algunos diseños de transacciones orientados a la privacidad. En términos prácticos, Ethereum intenta combinar reglas más estrictas contra la censura con funciones de cuenta capaces de admitir una verificación de transacciones más compleja.
Varias otras propuestas de nivel A abordan la transición desde supuestos criptográficos que podrían dejar de ser seguros ante una computación cuántica suficientemente potente. EIP-8365 iniciaría una salida gradual de ciertas credenciales de retiro BLS. El trabajo podría comenzar antes de que Ethereum finalice su arquitectura de consenso poscuántica completa.
EIP-7906, EIP-8298 y EIP-8151 forman un conjunto adicional de seguridad de cuentas en torno a Frames. EIP-7906 introduciría las Aserciones de Transacción, permitiendo que una transacción exija determinadas condiciones antes de finalizarse. EIP-8298 permitiría que las cuentas reutilizaran código de contratos existente, dando a las cuentas delegadas una vía para convertirse en cuentas de contratos inteligentes con su propio código completo. EIP-8151 impediría que las direcciones que ya contienen código de cuenta siguieran utilizando la autenticación tradicional basada en ecRecover.
Los sistemas de prueba y la fijación de precios de los recursos siguen formando parte del equilibrio
La hoja de ruta también sitúa EIP-8025, las pruebas de ejecución opcionales, en el debate sobre Hegotá. La propuesta está vinculada al futuro trabajo sobre zkEVM y busca incluir los cambios necesarios en una especificación de ejecución compartida, evitando el mantenimiento a largo plazo de bifurcaciones del protocolo separadas para distintos proyectos de máquinas virtuales de conocimiento cero.
EIP-8279 y EIP-8131 establecerían precios mínimos para los bytes de las listas de acceso a bloques y una capa unificada de contenido de transacciones. Su objetivo es limitar los costes máximos de procesamiento de bloques provocados por un precio demasiado bajo del contenido de las transacciones. EIP-3298, que elimina el mecanismo de reembolso de gas de Ethereum, y EIP-5920, el opcode PAY para transferir ETH sin ejecutar el código del destinatario, también se encuentran en el nivel A.
Algunas ideas destacadas tienen una prioridad menor. EIP-8198, Quick Slots, que busca tiempos de slot más cortos, sigue condicionada a contar con especificaciones completas, prototipos, análisis del impacto posterior y pruebas de que no interferirá con la separación del consenso. Se espera que las decisiones sobre EIP-8368 y EIP-8372, relativas a los límites de gas y a la fijación de precios de los recursos de estado, dependan de los datos de la mainnet recopilados después de Glamsterdam.
La secuencia propuesta por Ethereum sitúa entregables a corto plazo, como FOCIL y Frames, junto a una migración de seguridad de cuatro años que abarca las responsabilidades de los validadores de la red, el modelo de transacciones y los fundamentos criptográficos. La reevaluación de enero de 2027 comprobará si el ritmo previsto del progreso cuántico —y la propia capacidad de Ethereum para implementar actualizaciones aproximadamente dos veces al año— sigue respaldando una finalización en diciembre de 2029.
Descubre cómo la hoja de ruta de Ethereum influye en el trading y la seguridad de la red: empieza a analizar los mercados de criptomonedas en tiempo real con Toobit Markets hoy.
Aviso legal: El contenido de esta página se proporciona únicamente con fines informativos generales y no representa las opiniones ni el asesoramiento financiero de Toobit. No garantizamos la exactitud ni la integridad de esta información y no asumimos responsabilidad por errores, omisiones o resultados derivados de su uso. Invertir en activos digitales implica riesgos; los usuarios deben evaluar de forma independiente su situación financiera y los riesgos involucrados. Para obtener más información, consulta nuestros Términos del servicio y Divulgación de riesgos.
