Cuenta atrás hacia 2029: la carrera de Ethereum por la resistencia cuántica arranca con Hegotá

Autor original: KarenZ, Foresight News

Los ordenadores cuánticos aún no han llamado a la puerta de la blockchain, pero la Fundación Ethereum ya ha marcado una fecha en el calendario: diciembre de 2029.

Es el plazo de ingeniería que el equipo de protocolo de la Fundación Ethereum se ha fijado: prepararse para un escenario en el que la amenaza cuántica podría materializarse antes de lo previsto, con el objetivo de completar la adaptación de la capa 1 de Ethereum a la resistencia cuántica antes de que el riesgo sea inminente.

La planificada Hegotá, aunque no convertirá directamente a Ethereum en una blockchain totalmente resistente a los cuánticos, determinará si los planes posteriores pueden avanzar según lo previsto.

La EF fija un plazo de 2029 para el «Q-day»

El «Q-day» se utiliza habitualmente para referirse a un momento hipotético: la aparición de ordenadores cuánticos con capacidad real de ataque, lo que supondría una amenaza sustancial para los sistemas criptográficos de clave pública actuales.

Nadie puede predecir con exactitud cuándo llegará. La Fundación Ethereum reconoce explícitamente que la mayoría de las predicciones fiables sitúan el Q-day después de 2030, posiblemente mucho más tarde, e incluso existe la posibilidad de que no llegue nunca.

El equipo de protocolo de la Fundación Ethereum adopta una hipótesis de ingeniería conservadora: la capa 1 de Ethereum debe prepararse con antelación para la posibilidad de que el Q-day llegue ya en 2030.

Para ello, el equipo de protocolo se ha fijado un objetivo: lograr que la ejecución, el consenso y los datos de la capa 1 de Ethereum tengan plena resistencia cuántica antes de diciembre de 2029.

Este objetivo no es inamovible. El equipo de protocolo planea reevaluar el desarrollo de la computación cuántica en enero de 2027, incorporando la opinión de expertos externos. Hasta entonces, el plazo de 2029 se tratará como un objetivo de trabajo que no debe cederse fácilmente.

La adaptación a la resistencia cuántica requiere años de preparación porque Ethereum no utiliza una única técnica criptográfica, ni la migración se resuelve cambiando un solo algoritmo de firma. La forma en que las cuentas de usuario demuestran la autorización de transacciones, cómo participan los validadores en el consenso y cómo se verifican los datos implican estructuras criptográficas diferentes. Cualquier modificación exige diseño de especificaciones, implementación en clientes, auditorías de seguridad, pruebas en redes de desarrollo y coordinación en la red principal; no se puede esperar a que la amenaza ya esté presente para empezar a actuar.

Hegotá no es una «actualización de resistencia cuántica», pero es el primer examen de todo el plan

Según la hoja de ruta de referencia publicada actualmente por el equipo de protocolo de la Fundación Ethereum, la actualización de red Glamsterdam está prevista para la red principal en diciembre de 2026, y la plena resistencia cuántica se asigna a la quinta bifurcación dura después de Glamsterdam, L*, con fecha objetivo de diciembre de 2029. De Glamsterdam a L* solo hay tres años; si hay que completar Hegotá, I*, J*, K* y L* en orden, el intervalo medio entre actualizaciones es de solo unos 7,2 meses.

Se trata de un calendario bastante agresivo. Por ahora, la Fundación Ethereum no ha publicado fechas concretas de lanzamiento en la red principal para Hegotá, I*, J* y K*. Lo que sí es seguro es que los equipos de clientes esperan empezar a implementar Hegotá como muy pronto a finales del cuarto trimestre de 2026, y que la investigación, las especificaciones y las pruebas de varias versiones posteriores deben avanzar en paralelo.

Según la hoja de ruta actual, las principales disposiciones de cada fase son las siguientes:

• Hegotá: situada en el punto de partida de esta hoja de ruta. La definición oficial es muy clara: Hegotá en sí no es una actualización de resistencia cuántica, pero determinará si las actualizaciones posteriores de resistencia cuántica pueden avanzar a tiempo.
• I*: despliegue de un registro de claves públicas resistentes a cuánticos, sentando las bases del protocolo para el registro y uso de claves públicas resistentes a cuánticos por parte de las cuentas; al mismo tiempo, el desacoplamiento del consenso es actualmente la dirección candidata principal de esta versión, y se espera que los trabajos de diseño y migración de estructuras de estado de mayor envergadura comiencen también en I*.
• J*: establecimiento de una capa 1 «mínimamente viable resistente a cuánticos», es decir, MV-PQ. Sus componentes clave incluyen un mecanismo de heartbeat resistente a cuánticos en la capa de consenso, muestreo leanDA poscuántico en la capa de datos y transacciones leanSPHINCS poscuánticas en la capa de ejecución.
• K*: según la ordenación de referencia actual, introducción de pruebas de ejecución obligatorias. Para entonces, la dirección de los validadores será verificar pruebas de ejecución concisas, en lugar de que cada validador vuelva a ejecutar bloques completos.
• L*: según la ordenación de referencia actual, incorporación de los mensajes de prueba resistentes a cuánticos necesarios para lograr un consenso plenamente resistente a cuánticos, es decir, post-quantum attestations, y consecución del objetivo de plena resistencia cuántica en las capas de ejecución, consenso y datos en diciembre de 2029.

No obstante, el orden de las tareas de K* y L* aún no está definitivamente cerrado. El equipo de protocolo está evaluando una alternativa: adelantar los mensajes de prueba resistentes a cuánticos de L* a K*, de modo que la plena resistencia cuántica se alcance antes, y retrasar las pruebas de ejecución obligatorias de K* a L*. Si se adopta esta opción, las responsabilidades concretas de K* y L* y el ritmo de las actualizaciones cambiarían en consecuencia. Por tanto, la afirmación más precisa en esta fase es: diciembre de 2026 es el objetivo actual de Glamsterdam para la red principal, y diciembre de 2029 es el objetivo de L* y de la plena resistencia cuántica en la hoja de ruta de referencia; la ordenación interna de K* y L* aún puede ajustarse.

Investigadores, desarrolladores de clientes, auditores de seguridad y equipos de pruebas deben completar Hegotá y, al mismo tiempo, preparar con antelación especificaciones y prototipos para I*, J*, K* y L*. Si Hegotá incorpora demasiadas funciones que interactúan entre sí, no solo podría retrasar su propio lanzamiento, sino también ocupar a los equipos necesarios para el trabajo posterior de resistencia cuántica.

Por ello, el equipo de protocolo de la Fundación Ethereum ha clasificado las propuestas candidatas de Hegotá en los niveles S (2), A (15), B (8), C (7), DFI (28) y TBD (2), con un total de 62 propuestas candidatas. El nivel S significa entrega obligatoria; el nivel A, alta prioridad y entrega prevista; el nivel B requiere además cumplir condiciones de especificación, prototipo o confirmación del responsable; el nivel C queda por debajo del umbral de inclusión por ahora; DFI significa que no se recomienda su inclusión en esta actualización; y TBD significa pendiente de determinar.

Los dos niveles S de Hegotá: FOCIL y Frames

En la clasificación de Hegotá publicada por el equipo de protocolo, solo dos EIP alcanzan el nivel S: EIP-7805 FOCIL en la capa de consenso y EIP-8141 Frame Transactions en la capa de ejecución.

Abordan respectivamente dos cuestiones clave del ciclo de vida de las transacciones: si una transacción elegible puede entrar en un bloque y de qué manera una cuenta puede verificar y ejecutar transacciones.

FOCIL (EIP-7805) son las siglas de «Fork-choice enforced Inclusion Lists» (listas de inclusión impuestas por la regla de elección de bifurcación). Su objetivo es mejorar las garantías de inclusión de transacciones en Ethereum.

Actualmente, los constructores de bloques profesionales dominan la generación de bloques. Esta división del trabajo contribuye a la eficiencia de la construcción de bloques, pero si la producción de bloques se concentra a largo plazo en unos pocos constructores, estos podrían adquirir una gran capacidad de filtrado de transacciones. FOCIL añade, por tanto, una capa adicional de restricciones de inclusión procedentes de los validadores al margen del proceso normal de construcción de bloques.

Según el diseño de FOCIL, en cada slot se elige un conjunto de validadores que forman el «comité de listas de inclusión» (IL committee). Los miembros del comité elaboran y difunden listas de inclusión basadas en las transacciones pendientes que ven. El constructor del bloque del siguiente slot recopila estas listas e incluye en el bloque las transacciones que cumplen las condiciones de ejecución. Los validadores encargados de atestar el nuevo bloque también guardan las listas de inclusión que han recibido a tiempo y comprueban si el bloque cumple los requisitos correspondientes.

Si un bloque omite sin causa justificada transacciones de las listas guardadas por los validadores, los atestadores no votarán por ese bloque. Un bloque así, aunque siga siendo válido a nivel de ejecución, no podrá obtener el respaldo de consenso necesario para entrar en la cadena canónica. Ese es el sentido de FOCIL: no se trata de que los miembros del comité modifiquen directamente el bloque, sino de condicionar las elecciones del constructor mediante el voto de los validadores.

El EIP-8369 complementario describe con más detalle qué transacciones son aptas para recibir la garantía de inclusión forzosa de FOCIL. Las razones de omisión de las transacciones ordinarias son relativamente fáciles de verificar; las transacciones Frames permiten una verificación programable, cuyo coste de evaluación es mayor, por lo que requieren limitar adicionalmente el rango de estado que se puede leer y el presupuesto de verificación.

En términos sencillos, FOCIL no consiste en que los validadores arrebaten el trabajo a los constructores de bloques, sino en añadir una regla de la capa de consenso para los constructores: puedes seguir organizando la mayoría de las transacciones del bloque, pero no puedes ignorar de forma continuada, sin causa razonable, las transacciones elegibles incluidas en las listas del comité.

Frame Transactions (EIP-8141) aborda el problema a nivel de cuenta. Pretende hacer más programables a nivel de protocolo la verificación de transacciones, la ejecución y el pago de gas, sentando las bases para la abstracción de cuentas nativa. Vitalik es uno de los coautores del EIP-8141.

Actualmente, la mayoría de las cuentas ordinarias de Ethereum dependen de firmas con claves privadas de tipo fijo. Frames pretende que las cuentas utilicen lógica de verificación más flexible, por ejemplo adoptando nuevos esquemas de firma, combinando múltiples condiciones de autorización o permitiendo que otras cuentas paguen las comisiones de transacción. También puede admitir la agregación de firmas y permitir la introducción futura de nuevos esquemas de firma sin necesidad de una bifurcación dura para cada uno de ellos.

Pero Frames no es en sí mismo un esquema de firma resistente a cuánticos completo, ni eliminará de inmediato las claves existentes tras el lanzamiento de Hegotá. Lo que ofrece es «agilidad criptográfica»: si en el futuro es necesario cambiar de esquema de firma, las cuentas podrán migrar mediante verificación programable, en lugar de quedar bloqueadas permanentemente en un único sistema de claves.

Frames requiere además dos propuestas de nivel A como complementos esenciales. EIP-8250 Keyed Nonces permite que un mismo remitente utilice canales de nonce mutuamente independientes, de modo que transacciones distintas no se bloqueen entre sí por compartir un orden estricto; EIP-8272 permite que las transacciones utilicen estado reciente en cadena que los validadores puedan comprobar, de modo que las transacciones privadas relacionadas también puedan obtener la garantía de inclusión que ofrece FOCIL.

Por tanto, FOCIL y Frames no son dos funciones sin relación entre sí. La primera cambia qué transacciones elegibles debe incluir un bloque; la segunda cambia la propia estructura de verificación de las transacciones. Que ambas puedan coordinarse de forma segura es una de las tareas de prueba más importantes de Hegotá.

Además del nivel S, ¿qué otros EIP merecen atención?

Las propuestas de nivel S definen la línea principal de Hegotá, pero varias propuestas de nivel A también influirán en la seguridad de las cuentas, la migración a la resistencia cuántica, las pruebas de ejecución y la tarificación de recursos de Ethereum en el futuro.

En primer lugar, EIP-8365. Planea iniciar la retirada progresiva de parte de las credenciales de retirada BLS, porque siguen dependiendo de técnicas criptográficas que podrían perder seguridad ante un ataque cuántico suficientemente potente. El equipo de protocolo considera que esta migración puede empezar con antelación, sin esperar a que se defina el diseño completo del consenso resistente a cuánticos.

En cuanto a la seguridad de las cuentas, EIP-7906, EIP-8298 y EIP-8151 se consideran un conjunto de extensiones de Frames.

EIP-7906 introduce un mecanismo de aserciones de transacción (Transaction Assertions) que permite a una transacción comprobar, antes de su envío definitivo, si se ha producido un resultado especificado. El objetivo es reducir las pérdidas causadas por contratos maliciosos que drenan activos de los monederos y por ciertos comportamientos de MEV. No obstante, el alcance concreto de lectura de esta propuesta sigue en estudio y acotación, por lo que el diseño actual no debe considerarse una especificación final cerrada.

EIP-8298 permite que las cuentas reutilicen código de contrato existente, de modo que las cuentas delegadas puedan transformarse en cuentas de contrato inteligente con código completo. EIP-8151 restringe que las direcciones con código de cuenta existente sigan dependiendo de la autenticación tradicional ecRecover.

Con la combinación de estas dos propuestas, las cuentas podrían dejar de utilizar realmente la antigua clave secp256k1 como credencial de control suprema, estableciendo una vía completa para abandonar en el futuro el antiguo sistema de claves.

EIP-8025 (pruebas de ejecución opcionales) está relacionado con la futura hoja de ruta zkEVM. Planea incorporar los cambios necesarios para las pruebas de ejecución opcionales a una especificación de ejecución unificada, reduciendo el problema de que distintos proyectos zkVM mantengan a largo plazo versiones bifurcadas entre sí.

EIP-8279 (capa de bytes de listas de acceso de bloques) y EIP-8131 (capa unificada de contenido de transacciones) son un par de propuestas de seguridad de ejecución. Ambas establecen estándares mínimos de tarificación para las listas de acceso de bloques y el contenido de las transacciones, respectivamente, con el objetivo de limitar que los atacantes aprovechen contenidos con precios infravalorados para generar cargas extremas de recursos. En primer lugar, resuelven el coste de procesamiento de bloques en el peor de los casos, no anuncian directamente un aumento de la capacidad de la red. La decisión de aprovechar el margen de seguridad resultante para ampliar la capacidad deberá tomarse por separado más adelante.

EIP-3298 planea eliminar por completo el mecanismo de reembolso de gas, reduciendo casos especiales en la medición, implementación y pruebas; EIP-5920 (PAY Opcode) permite que los contratos transfieran ETH sin ejecutar el código del destinatario, separando claramente «transferir valor» de «llamar a un contrato».

Al mismo tiempo, algunas propuestas que han despertado interés siguen en el nivel B.

Por ejemplo, EIP-8198 (Quick Slots) pretende acortar el tiempo de slot, pero el equipo de protocolo exige que primero complete una especificación que cubra los cambios centrales del protocolo, un prototipo completo, una evaluación del impacto en los sistemas dependientes y demuestre que no interferirá con el diseño posterior de desacoplamiento del consenso. La razón es que el tiempo de slot no solo afecta a la velocidad de producción de bloques, sino también a la propagación por la red, a las decisiones de consenso y a las suposiciones temporales de las aplicaciones.

Además, EIP-8368 y EIP-8372 figuran como «TBD» (pendientes de determinar). Ambas propuestas afectan al límite de gas y a la tarificación de recursos de estado; el equipo de protocolo ha decidido esperar a los datos de la red principal tras el lanzamiento de Glamsterdam en diciembre de 2026 antes de juzgar si es necesario recalibrar.

El número final de EIP que se incluyan en Hegotá no es el único criterio para medir el éxito de esta actualización.

Más importante es si puede entregar FOCIL, Frames y sus complementos esenciales sin sacrificar la seguridad ni la calidad de las pruebas, dejando al mismo tiempo suficientes recursos de investigación y desarrollo para el registro de claves públicas y el desacoplamiento del consenso de I*, la resistencia cuántica mínimamente viable de J*, y las pruebas de ejecución y el consenso plenamente resistente a cuánticos de K* y L*.

Según los objetivos actuales, Glamsterdam iniciará este ciclo de actualizaciones tan ajustado en diciembre de 2026, y L*, en la hoja de ruta de referencia, llegará a su meta en diciembre de 2029. Ninguna actualización intermedia puede limitarse a completar sus propias funciones; todas deben garantizar que la siguiente fase pueda seguir avanzando.

Nadie puede dar una respuesta definitiva sobre si la amenaza cuántica se materializará antes de 2030. Pero la elección actual de Ethereum ya es clara: fijar primero un plazo para el riesgo y, después, dejar que cada propuesta demuestre con especificaciones, prototipos y pruebas que reúne las condiciones para entrar en la red principal.

Referencias del artículo:

https://blog.ethereum.org/2026/09/07/protocol-hegota-eips

https://blog.ethereum.org/2026/09/07/protocol-priorities

https://x.com/VitalikButerin/status/2073459000398463446