La batalla final de 2029: la carrera más urgente de Ethereum contra la tecnología cuántica

No es una actualización contra cuántica, pero determina el éxito o fracaso: entiende Hegotá.

Escrito por: 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 establecido por el equipo de protocolo de la Fundación Ethereum para prepararse ante la amenaza cuántica, buscando completar la transformación cuántica de la red de capa uno de Ethereum antes de que el riesgo se vuelva inminente.

Hegotá, que se está planificando, no convertirá a Ethereum en una blockchain completamente resistente a la cuántica, pero determinará si los planes posteriores pueden avanzar a tiempo.

La Fundación Ethereum establece un plazo de 2029 para el "Día Q"

"Día Q" se utiliza comúnmente para referirse a un punto en el tiempo hipotético: la aparición de ordenadores cuánticos con capacidad de ataque real, lo que representa una amenaza sustancial para los sistemas de criptografía de clave pública existentes.

No hay forma de predecir cuándo llegará. La Fundación Ethereum también ha reconocido que la mayoría de las predicciones confiables sugieren que el Día Q ocurrirá después de 2030, e incluso podría tardar mucho más, o podría no llegar nunca.

El equipo de protocolo de la Fundación Ethereum adopta una hipótesis de ingeniería conservadora: la capa uno de Ethereum debe prepararse para la posibilidad de que el Día Q llegue antes de 2030.

Para ello, el equipo de protocolo ha establecido un objetivo: completar la capacidad cuántica de la capa uno de Ethereum en ejecución, consenso y datos 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, en consulta con expertos externos. Hasta entonces, el plazo de 2029 se considerará un objetivo de trabajo que no se puede ceder fácilmente.

La necesidad de prepararse con varios años de antelación para la transformación cuántica se debe a que Ethereum no utiliza solo un tipo de tecnología criptográfica, y no se puede completar la migración simplemente cambiando un algoritmo de firma. Cómo los usuarios demuestran la autorización de transacciones, cómo los validadores participan en el consenso y cómo se valida la información, involucra diferentes estructuras criptográficas. Cualquier modificación debe pasar por un diseño normativo, implementación en cliente, revisión de seguridad, pruebas en red de desarrollo y coordinación en la red principal, no se puede esperar a que la amenaza ya esté presente para comenzar a abordar el problema.

Hegotá no es una "actualización contra cuántica", pero es la primera prueba de todo el plan

Según la hoja de ruta base publicada actualmente por el equipo de protocolo de la Fundación Ethereum, la actualización de la red Glamsterdam está programada para lanzarse en la red principal en diciembre de 2026, y la capacidad cuántica completa está programada para la quinta bifurcación dura L* después de Glamsterdam, con un objetivo de tiempo para diciembre de 2029. Solo hay tres años entre Glamsterdam y L*, y si se completan sucesivamente Hegotá, I*, J*, K* y L*, habrá aproximadamente 7.2 meses entre cada actualización.

Este es un cronograma bastante agresivo. Actualmente, la Fundación Ethereum no ha publicado tiempos de lanzamiento específicos para Hegotá, I*, J* y K* en la red principal. Lo que se puede confirmar es que el equipo de cliente espera implementar Hegotá a más tardar en el cuarto trimestre de 2026, y que la investigación, normalización y pruebas de múltiples versiones posteriores deben avanzar en paralelo.

Según la hoja de ruta actual, los principales arreglos en cada etapa son los siguientes:

• Hegotá: se encuentra en el punto de partida de esta ruta. La posición oficial es muy clara: Hegotá en sí no es una actualización contra cuántica, pero decidirá si las actualizaciones contra cuántica posteriores pueden avanzar a tiempo.
• I*: desplegar un registro de claves públicas cuánticas, estableciendo la base del protocolo para el registro y uso de claves públicas cuánticas; al mismo tiempo, desacoplar el consenso es la dirección principal de este versión, y se espera que el diseño y la migración de estructuras de estado de gran escala comiencen desde I*.
• J*: establecer una capa de "mínima viabilidad cuántica", es decir, MV-PQ. Sus componentes clave incluyen un mecanismo de latido cuántico en la capa de consenso, muestreo leanDA post-cuántico en la capa de datos, y transacciones leanSPHINCS post-cuánticas en la capa de ejecución.
• K*: según el orden de referencia actual, introducir pruebas de ejecución obligatorias. En ese momento, la dirección de desarrollo de los validadores será validar pruebas de ejecución simplificadas, en lugar de que cada validador ejecute nuevamente bloques completos.
• L*: según el orden de referencia actual, completar los mensajes de prueba cuántica necesarios para lograr un consenso cuántico completo, es decir, atestaciones post-cuánticas, y alcanzar los objetivos cuánticos completos en la capa de ejecución, consenso y datos para diciembre de 2029.

Sin embargo, el orden de las tareas de K* y L* aún no se ha determinado. El equipo de protocolo está evaluando un plan de intercambio: adelantar los mensajes de prueba cuántica de L* a K*, para lograr la capacidad cuántica completa antes; al mismo tiempo, retrasar las pruebas de ejecución obligatorias de K* a L*. Si se adopta este plan, las responsabilidades específicas de K* y L* y el ritmo de actualización cambiarán en consecuencia. Por lo tanto, la afirmación más precisa en esta etapa es: diciembre de 2026 es el objetivo actual de la red principal de Glamsterdam, y diciembre de 2029 es el objetivo de la ruta base para L* y la capacidad cuántica completa; el orden interno de K y L* aún puede ajustarse.

Investigadores, desarrolladores de clientes, revisores de seguridad y equipos de prueba deben completar Hegotá y, al mismo tiempo, preparar normas y prototipos para I*, J*, K* y L*. Si Hegotá incluye demasiadas funciones interdependientes, no solo podría retrasar su lanzamiento, sino que también ocuparía al equipo necesario para el trabajo cuántico posterior.

Por lo tanto, el equipo de protocolo de la Fundación Ethereum ha clasificado las propuestas candidatas de Hegotá en niveles S (2 elementos), A (15 elementos), B (8 elementos), C (7 elementos), DFI (28 elementos) y TBD (2 elementos), un total de 62 propuestas candidatas. El nivel S representa entregas obligatorias; el nivel A representa alta prioridad, se espera que se entregue; el nivel B aún debe cumplir con condiciones como normas, prototipos o confirmaciones de responsables; el nivel C está temporalmente por debajo de la línea de inclusión; DFI indica que no se recomienda incluir en esta actualización; TBD significa que está pendiente.

Los dos S de Hegotá: FOCIL y Frames

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

Ambos abordan dos problemas clave en el ciclo de vida de las transacciones: si una transacción válida puede entrar en un bloque y cómo una cuenta puede verificar y ejecutar una transacción.

FOCIL (EIP-7805) significa "Listas de Inclusión Impuestas por Reglas de Selección de Fork". Su objetivo es mejorar la garantía de inclusión de transacciones en Ethereum.

Actualmente, los constructores de bloques profesionales dominan la generación de bloques. Esta división del trabajo ayuda a mejorar la eficiencia de construcción de bloques, pero si la producción de bloques se concentra en unos pocos constructores durante mucho tiempo, también pueden obtener una fuerte capacidad de filtrado de transacciones. Por lo tanto, FOCIL añade una capa de restricciones de inclusión de los validadores fuera del flujo normal de construcción de bloques.

Según el diseño de FOCIL, cada Slot seleccionará un grupo de validadores para formar un "Comité de Lista de Inclusión" (IL committee). Los miembros del comité crean y transmiten listas de inclusión basadas en las transacciones pendientes que ven. El constructor de bloques del siguiente Slot recopila estas listas y añade las transacciones que cumplen con los criterios de ejecución al construir el bloque. Los validadores responsables de probar el nuevo bloque también guardarán las listas de inclusión que recibieron a tiempo y verificarán si el bloque cumple con los requisitos correspondientes.

Si un bloque omite sin justificación las transacciones de la lista guardada por los validadores, el probador no votará a favor de ese bloque. Tal bloque, aunque siga siendo un bloque válido a nivel de ejecución, no podrá obtener el apoyo de consenso necesario para entrar en la cadena normativa. Este es el significado de FOCIL: no permite que los miembros del comité modifiquen directamente el bloque, sino que restringe la elección del constructor de bloques a través de si los validadores votan o no.

El EIP-8369 complementario describe más a fondo qué transacciones son adecuadas para obtener la garantía de inclusión obligatoria de FOCIL. Las razones para omitir transacciones normales son relativamente fáciles de verificar; las transacciones de Frames permiten una verificación programable, lo que aumenta el costo de juicio, por lo que se requiere limitar adicionalmente el rango de estado que se puede leer y el presupuesto de verificación.

En términos simples, FOCIL no permite que los validadores se apoderen del trabajo de los constructores de bloques, sino que añade una regla de capa de consenso para los constructores: aún puedes organizar la mayoría de las transacciones en el bloque, pero no puedes ignorar continuamente las transacciones calificadas enumeradas por el comité sin una razón válida.

Frame Transactions (EIP-8141) aborda problemas a nivel de cuenta. Planea hacer que la verificación de transacciones, la ejecución de transacciones y el pago de Gas sean más programables a nivel de protocolo, proporcionando una base para la abstracción de cuentas nativas. Vitalik es uno de los coautores de EIP-8141.

Actualmente, la mayoría de las cuentas normales de Ethereum dependen de un tipo fijo de firma de clave privada. Frames espera permitir que las cuentas utilicen lógicas de verificación más flexibles, como adoptar nuevos esquemas de firma, combinar múltiples condiciones de autorización, o permitir que otras cuentas paguen las tarifas de transacción. También puede soportar la agregación de firmas y permitir la introducción de nuevos esquemas de firma en el futuro, sin necesidad de realizar una bifurcación dura para cada uno de ellos.

Pero Frames en sí no es un esquema de firma cuántica completo, ni eliminará inmediatamente las claves existentes después de que Hegotá se implemente. Proporciona "agilidad criptográfica": en el futuro, si es necesario cambiar el esquema de firma, la cuenta podrá completar la migración a través de la verificación programable, en lugar de quedar permanentemente bloqueada por un sistema de claves.

Frames también requiere dos propuestas de nivel A como soporte central. EIP-8250 Keyed Nonces permite que el mismo remitente use canales nonce independientes, de modo que diferentes transacciones no se bloqueen entre sí debido a compartir un orden estricto; EIP-8272 permite que las transacciones utilicen el estado reciente en la cadena que los validadores pueden verificar, lo que permite que las transacciones de privacidad relacionadas también obtengan la garantía de inclusión proporcionada por FOCIL.

Por lo tanto, FOCIL y Frames no son dos funciones no relacionadas. La primera cambia qué transacciones calificadas deben incluirse en el bloque, mientras que la segunda cambia la estructura de verificación de las transacciones en sí. La capacidad de ambos para trabajar juntos de manera segura es una de las tareas de prueba más importantes de Hegotá.

Además de los 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 afectarán la seguridad de las cuentas de Ethereum en el futuro, la migración cuántica, las pruebas de ejecución y la valoración de recursos.

Primero está EIP-8365. Planea iniciar un trabajo de salida gradual para algunos certificados de retiro BLS, ya que estos certificados aún dependen de tecnologías criptográficas que podrían perder seguridad ante ataques cuánticos suficientemente fuertes. El equipo de protocolo considera que esta migración puede comenzar antes, sin esperar a que se determine el diseño completo del consenso cuántico.

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

EIP-7906 introduce un mecanismo de Afirmaciones de Transacción (Transaction Assertions), que permite que las transacciones verifiquen si se produce un resultado específico antes de ser enviadas. Este mecanismo tiene como objetivo reducir las pérdidas causadas por contratos maliciosos que retiran activos de billeteras y ciertos comportamientos de MEV. Sin embargo, el alcance específico de esta propuesta aún se está investigando y acotando, por lo que no se puede considerar el diseño actual como una norma final ya bloqueada.

EIP-8298 permite que las cuentas reutilicen el código de contratos existentes, permitiendo que las cuentas delegadas se conviertan en cuentas de contratos inteligentes con código completo. EIP-8151 limita la dirección de los códigos de cuentas existentes para seguir dependiendo de la autenticación tradicional ecRecover.

Solo después de combinar estas dos propuestas, las cuentas podrán dejar de depender de las antiguas claves secp256k1 como el principal medio de control, estableciendo un camino completo para salir del antiguo sistema de claves en el futuro.

EIP-8025 (pruebas de ejecución opcionales) está relacionado con la futura ruta de zkEVM. Planea incluir los cambios necesarios para las pruebas de ejecución opcionales en una norma de ejecución unificada, reduciendo los problemas de mantenimiento a largo plazo de versiones bifurcadas entre diferentes proyectos de zkVM.

EIP-8279 (lista de acceso a bloques en capas de bytes) y EIP-8131 (capa de contenido de transacciones unificada) son un conjunto de propuestas de seguridad de ejecución. Ambos establecen estándares mínimos de valoración para la lista de acceso a bloques y el contenido de las transacciones, con el objetivo de limitar la carga de recursos extrema que los atacantes pueden crear utilizando contenido con precios demasiado bajos. Primero abordan el costo de procesamiento de bloques en el peor de los casos, en lugar de anunciar directamente un aumento en la capacidad de la red. La decisión de utilizar el margen de seguridad generado para ampliar la capacidad deberá tomarse por separado en el futuro.

EIP-3298 planea eliminar completamente el mecanismo de reembolso de Gas, reduciendo las excepciones en la medición, implementación y pruebas; EIP-5920 (PAY Opcode) permite que los contratos transfieran ETH sin ejecutar el código del receptor, separando claramente "transferir valor" y "llamar a contratos".

Mientras tanto, algunas propuestas de interés aún están en el nivel B.

Por ejemplo, EIP-8198 (Slots Rápidos) espera acortar el tiempo de Slot, pero el equipo de protocolo exige que complete primero la norma que cubre los cambios en el protocolo central, un prototipo completo, una evaluación de impacto descendente y demostrar que no interferirá con el diseño de consenso desacoplado posterior. La razón es que el tiempo de Slot no solo afecta la velocidad de creación de bloques, sino también la propagación de la red, el juicio de consenso y las suposiciones de tiempo de las aplicaciones.

Además, EIP-8368 y EIP-8372 se han clasificado como "TBD" (pendiente). Ambas propuestas involucran límites de Gas y valoración de recursos de estado, y el equipo de protocolo ha decidido esperar los datos de la red principal después del lanzamiento de Glamsterdam en diciembre de 2026 para determinar si es necesario recalibrar.

Cuántos EIP se incluirán finalmente en Hegotá no es el único estándar para medir el éxito de esta actualización.

Más importante aún, si puede entregar FOCIL, Frames y su soporte central sin sacrificar la seguridad y la calidad de las pruebas, al mismo tiempo que deja suficientes recursos de desarrollo para el registro de claves públicas y el consenso desacoplado de I*, la capacidad cuántica mínima viable de J*, así como las pruebas de ejecución y el consenso cuántico completo de K* y L*.

Según los objetivos actuales, Glamsterdam comenzará este apretado ciclo de actualizaciones en diciembre de 2026, y la L* de la ruta base llegará a su fin en diciembre de 2029. Cada actualización intermedia no puede centrarse solo en completar su propia función, sino que también debe garantizar que la siguiente fase pueda continuar avanzando.

Nadie puede dar una respuesta definitiva sobre si la amenaza cuántica se convertirá en realidad antes de 2030. Pero la elección actual de Ethereum es clara: primero establecer un plazo para el riesgo, y luego permitir que cada propuesta demuestre su capacidad para entrar en la red principal a través de normas, prototipos y pruebas.

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