La Fundación Ethereum establece una fecha límite para 2029 en las actualizaciones resistentes a la computación cuántica

Autor original: KarenZ, Foresight News

La computación cuántica aún no ha golpeado la puerta de la blockchain, pero la Fundación Ethereum ya ha marcado una fecha en el calendario: 12 de diciembre de 2029.

Es el plazo de ingeniería que el equipo de protocolo de la Ethereum Foundation se ha fijado: prepararse para el escenario en el que las amenazas cuánticas puedan aparecer antes, y completar la transformación cuánticamente resistente de la capa uno de Ethereum antes de que el riesgo se haga real.

Hegotá, actualmente en planificación, aunque no transformará directamente Ethereum en una blockchain completamente resistente a la computación cuántica, determinará si los planes posteriores pueden avanzar según lo programado.

El «Q-day» se utiliza comúnmente para referirse a un punto temporal hipotético: la aparición de una computadora cuántica con capacidad de ataque real, lo que pone en peligro sustancial los sistemas de criptografía de clave pública actuales.

Nadie puede predecir con precisión cuándo llegará. La Fundación Ethereum también reconoce explícitamente que la mayoría de las predicciones confiables indican que el Q-day ocurrirá después de 2030, e incluso podría retrasarse mucho más, o bien nunca llegar.

El equipo de protocolo de la Ethereum Foundation adopta una suposición de ingeniería conservadora: la capa uno de Ethereum debe prepararse con anticipación para el caso de que el Q-day ocurra lo antes posible en 2030.

Para ello, el equipo del protocolo ha establecido como objetivo lograr que, antes de diciembre de 2029, las tres componentes de Ethereum Layer 1 —ejecución, consenso y datos— posean una resistencia cuántica completa.

Este objetivo también puede ajustarse en el futuro. El equipo del protocolo planea reevaluar el avance de la computación cuántica en enero de 2027, incorporando la opinión de expertos externos. Antes de eso, la fecha límite de 2029 se considerará un objetivo de trabajo que no se cederá fácilmente.

La preparación para la resistencia cuántica requiere años de anticipación porque Ethereum no utiliza solo una tecnología criptográfica, y la migración no se logra simplemente cambiando un algoritmo de firma. La forma en que las cuentas de usuario demuestran autorización para las transacciones, cómo los validadores participan en el consenso y cómo se verifican los datos implica diferentes estructuras criptográficas. Cualquier modificación debe pasar por el diseño normativo, la implementación en clientes, revisión de seguridad, pruebas en redes de desarrollo y coordinación en la red principal; no es posible esperar hasta que la amenaza ya haya surgido para comenzar a abordarla.

Según la hoja de ruta de referencia publicada actualmente por el equipo de la Ethereum Foundation, la actualización de la red Glamsterdam está programada para lanzarse en la mainnet en diciembre de 2026, mientras que la capacidad completa de resistencia cuántica está planificada para la quinta hard fork después de Glamsterdam, denominada L*, con una fecha objetivo de diciembre de 2029. Solo hay tres años entre Glamsterdam y L*, y si se deben completar secuencialmente Hegotá, I*, J*, K* y L*, el promedio entre cada actualización sería de aproximadamente 7.2 meses.

Este es un calendario bastante agresivo. Actualmente, la Fundación Ethereum no ha anunciado fechas confirmadas para el lanzamiento en mainnet de Hegotá, I*, J* y K*. Se puede confirmar que los equipos de clientes esperan comenzar a implementar Hegotá a finales del cuarto trimestre de 2026 como mínimo, y que la investigación, la especificación y las pruebas de múltiples versiones posteriores deben avanzar en paralelo.

Según la ruta actual, los principales planes para cada fase son los siguientes:

• Hegotá: ubicado en el punto inicial de esta ruta. La definición oficial es muy clara: Hegotá no es una actualización resistente a la computación cuántica, pero determinará si las actualizaciones futuras resistentes a la computación cuántica pueden avanzar según lo programado.
• I*: Implement a post-quantum public key registry to establish a protocol foundation for account registration and usage of post-quantum public keys; at the same time, decoupling consensus is currently the leading core direction for this version, and significant state structure design and migration efforts are also expected to begin with I*.
• J*: Establecer una capa de "antirresistencia cuántica mínimamente viable", es decir, MV-PQ. Sus componentes clave incluyen el mecanismo de heartbeat antirresistencia cuántica en la capa de consenso, la muestra leanDA post-cuántica en la capa de datos y las transacciones leanSPHINCS post-cuánticas en la capa de ejecución.
• K*: Según el ordenamiento actual del基准, se introduce la prueba de ejecución obligatoria. En ese momento, la dirección de desarrollo de los validadores será verificar pruebas de ejecución concisas, en lugar de que cada validador vuelva a ejecutar bloques completos.
• L*: Según el ordenamiento actual del基准, completar los mensajes de prueba cuánticamente resistente, es decir, post-quantum attestations, necesarios para lograr un consenso completamente resistente a la computación cuántica, y alcanzar el objetivo completo de resistencia cuántica en las capas 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 definido definitivamente. El equipo del protocolo está evaluando una propuesta de intercambio: anticipar el mensaje de prueba cuántica resistente de L* a K* para lograr una capacidad cuántica completa más temprano, y posponer la prueba de ejecución forzada de K* a L*. Si se adopta este enfoque, las responsabilidades específicas de K* y L*, así como 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 lanzamiento en mainnet para Glamsterdam, y diciembre de 2029 es el objetivo en la ruta base para L* y la capacidad cuántica completa; el orden interno de K y L* aún podría ajustarse.

Los investigadores, desarrolladores de clientes, revisores de seguridad y el equipo de pruebas deben completar Hegotá y, al mismo tiempo, preparar con anticipación las especificaciones y prototipos para I*, J*, K* y L*. Si Hegotá incorpora demasiadas funciones interdependientes, no solo podría retrasar su propio lanzamiento, sino también desviar recursos del equipo necesarios para los trabajos posteriores de resistencia cuántica.

Por lo tanto, el equipo de protocolo de la Ethereum Foundation clasificó las 62 propuestas candidatas en las siguientes categorías: S (2), A (15), B (8), C (7), DFI (28) y TBD (2). La categoría S indica que deben ser entregadas; la categoría A indica alta prioridad y se espera su entrega; la categoría B requiere cumplir con condiciones adicionales, como especificaciones, prototipos o confirmación del responsable; la categoría C está temporalmente por debajo del umbral de inclusión; DFI indica que no se recomienda incluirlas en esta actualización; y TBD significa que está pendiente de definición.

En la clasificación Hegotá publicada por el equipo del protocolo, solo dos EIP alcanzaron la categoría S: EIP-7805 FOCIL en la capa de consenso y EIP-8141 Frame Transaction en la capa de ejecución.

They address two key issues in the transaction lifecycle: whether a qualifying transaction can be included in a block, and how an account can verify and execute a transaction.

FOCIL (EIP-7805) significa "Listas de inclusión impuestas por la regla de selecció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 de tareas ayuda a mejorar 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 también podrían adquirir una fuerte capacidad de selección de transacciones. Por ello, FOCIL añade una capa adicional de restricciones de inclusión provenientes de los validadores, fuera del proceso normal de construcción de bloques.

Según el diseño de FOCIL, cada Slot selecciona un grupo de validadores para formar el "Comité de lista de inclusión" (IL committee). Los miembros del comité crean y transmiten sus propias listas de inclusión según las transacciones pendientes que ven. El constructor del bloque del siguiente Slot recopila estas listas e incluye en el bloque las transacciones que cumplan con los criterios de ejecución. Los validadores responsables de probar el nuevo bloque también guardan las listas de inclusión que recibieron a tiempo y verifican si el bloque cumple con los requisitos correspondientes.

Si un bloque omite sin justificación las transacciones guardadas por el validador, los proofers no votarán por ese bloque. Aunque dicho bloque siga siendo válido a nivel de ejecución, no obtendrá el apoyo de consenso necesario para ingresar a la cadena canonical. Ese es precisamente el propósito de FOCIL: no permite que los miembros del comité modifiquen directamente los bloques, sino que restringe las opciones de los block builders mediante el voto o no voto de los validadores.

El EIP-8369 complementario describe con mayor detalle qué transacciones son adecuadas para recibir la garantía de inclusión obligatoria de FOCIL. Las razones para la omisión de transacciones normales son relativamente fáciles de verificar; las transacciones de Frames permiten verificación programable, pero el costo de juicio es mayor, por lo que se requieren restricciones adicionales sobre el rango de estados que se pueden leer y el presupuesto de verificación.

En términos sencillos, FOCIL no le quita a los validadores el trabajo de construir bloques, sino que añade una regla de la capa de consenso a los constructores: aún puedes organizar la mayoría de las transacciones en el bloque, pero no puedes ignorar de forma continua las transacciones calificadas listadas por el comité sin una razón válida.

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

Actualmente, la mayoría de las cuentas estándar de Ethereum dependen de firmas de clave privada de tipo fijo. Frames busca permitir que las cuentas utilicen lógicas de verificación más flexibles, como nuevos esquemas de firma, combinación de múltiples condiciones de autorización o que otras cuentas paguen las tarifas 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 realizar un hard fork separado para cada uno.

Sin embargo, Frames en sí mismo no es un esquema de firma resistente a la computación cuántica completo, ni reemplazará inmediatamente las claves actuales tras el lanzamiento de Hegotá. Proporciona "agilidad criptográfica": en el futuro, si es necesario cambiar el esquema de firma, las cuentas podrán migrar mediante verificación programable, en lugar de quedar permanentemente atadas a un solo sistema de claves.

Frames aún requiere dos propuestas de nivel A como complemento principal. EIP-8250 Keyed Nonces permite que un mismo remitente utilice canales de nonce independientes entre sí, haciendo que diferentes transacciones no se bloqueen mutuamente por compartir un orden estricto; EIP-8272 permite que las transacciones utilicen el estado en cadena reciente verificable por los validadores, permitiendo 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 independientes. La primera cambia qué transacciones elegibles deben incluirse en el bloque, y la segunda modifica la estructura de validación de las transacciones en sí. Su capacidad para funcionar juntas de forma segura es uno de los tests más importantes de Hegotá.

La propuesta de nivel S define la línea principal de Hegotá, pero varias propuestas de nivel A también afectarán la seguridad de cuentas futuras de Ethereum, la migración cuántica resistente, la prueba de ejecución y la valoración de recursos.

En primer lugar, EIP-8365. Planea iniciar el proceso gradual de retiro para ciertos credenciales de retiro BLS, ya que estos aún dependen de tecnologías criptográficas que podrían perder su seguridad frente a ataques cuánticos suficientemente potentes. El equipo del protocolo considera que este cambio puede iniciarse antes, sin necesidad de esperar la finalización del diseño completo de consenso resistente a la computación cuántica.

En términos de seguridad de la cuenta, EIP-7906, EIP-8298 y EIP-8151 se consideran una combinación de extensiones para Frames.

EIP-7906 introduce el mecanismo de afirmaciones de transacción (Transaction Assertions), que permite verificar si se ha producido un resultado especificado antes de enviar finalmente la transacción. Este mecanismo tiene como objetivo reducir las pérdidas causadas por contratos maliciosos que extraen activos de billeteras y ciertos comportamientos de MEV. Sin embargo, el alcance exacto de lectura de esta propuesta aún se encuentra en investigación y refinamiento, por lo que no se puede considerar el diseño actual como una especificación final y fijada.

EIP-8298 permite la reutilización del código de contrato existente por parte de las cuentas, permitiendo que las cuentas delegadas se conviertan aún más en cuentas de contrato inteligente con código completo. EIP-8151 restringe que las direcciones de cuentas existentes sigan dependiendo de la autenticación tradicional ecRecover.

Solo después de combinar estas dos propuestas, la cuenta podrá dejar de usar la clave secp256k1 antigua como credencial de control principal, estableciendo un camino completo para salir del antiguo sistema de claves.

EIP-8025 (Proof of Execution Optional) está relacionado con la futura ruta de zkEVM. Planea integrar los cambios necesarios para la prueba de ejecución opcional en el estándar de ejecución unificado, reduciendo el problema de mantener versiones bifurcadas a largo plazo entre diferentes proyectos zkVM.

EIP-8279 (Byte Layer de la lista de acceso a bloques) y EIP-8131 (Capa unificada de contenido de transacción) son un conjunto de propuestas de seguridad de ejecución. Ambas establecen estándares mínimos de valoración para la lista de acceso a bloques y el contenido de transacción, con el objetivo de limitar que los atacantes generen cargas extremas de recursos aprovechando contenidos con valoración baja. Abordan inicialmente el costo de procesamiento de bloques en el peor de los casos, en lugar de declarar directamente un aumento en la capacidad de la red. La decisión de aprovechar el margen de seguridad generado para ampliar la capacidad deberá tomarse por separado en el futuro.

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 a los contratos transferir ETH sin ejecutar el código del receptor, separando claramente la "transferencia de valor" de la "llamada al contrato".

Al mismo tiempo, algunas propuestas destacadas aún permanecen en la categoría B.

Por ejemplo, EIP-8198 (Quick Slots) busca reducir el tiempo de Slot, pero el equipo de protocolo requiere que primero se completen la especificación, el prototipo completo y la evaluación de impactos en los componentes descendientes, así como demostrar que no interfiere con el diseño de consenso desacoplado futuro. La razón es que el tiempo de Slot no solo afecta la velocidad de generació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 enumeran como «TBD» (por determinar). Ambas propuestas abordan límites de Gas y valoración de recursos de estado; el equipo del protocolo decidió esperar los datos de la red principal tras el lanzamiento de Glamsterdam en diciembre de 2026 antes de determinar si es necesario recalibrar.

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

Más importante aún, ¿puede entregar FOCIL, Frames y sus complementos principales sin sacrificar la seguridad ni la calidad de las pruebas, al mismo tiempo que deja suficientes recursos de investigación y desarrollo para el registro de la clave pública de I*, la desacoplación del consenso, la capacidad mínima viable de resistencia cuántica de J*, y las pruebas de ejecución y el consenso completamente resistente a la computación cuántica de K* y L*?

Según el objetivo actual, Glamsterdam iniciará este ciclo de actualización compacta en diciembre de 2026, mientras que el L* en la ruta base alcanzará su punto final en diciembre de 2029. Cada actualización intermedia no solo debe cumplir con sus propias funciones, sino también garantizar que la siguiente fase pueda continuar avanzando.

Nadie puede dar una respuesta segura sobre si la amenaza cuántica se convertirá en realidad antes de 2030. Pero la opción actual de Ethereum ya está clara: establecer plazos para el riesgo y permitir que cada propuesta demuestre, mediante especificaciones, prototipos y pruebas, que cumple con los requisitos para ingresar a la red principal.

Referencia 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