# Así será la seguridad cuántica de Ethereum según Thomas Coratger > Ethereum separa su defensa cuántica en ejecución, consenso y datos. Te explicamos leanXMSS, leanVM y el registro PQ con cifras y plazos claros. > Por José Maldonado · Blockchain · 2026-10-09 Imagina que tu casa tiene tres puertas distintas y cada una necesita una cerradura nueva antes de una tormenta anunciada. Ethereum vive una situación parecida en octubre de 2026, con tres capas que deben volverse resistentes a la computación cuántica antes de que el riesgo madure. La Fundación creó en enero de 2026 un equipo dedicado de seguridad postcuántica liderado por Thomas Coratger, con trabajo público en [pq.ethereum.org](https://pq.ethereum.org/). Ese equipo coordina más de diez equipos de clientes en devnets semanales de interoperabilidad y publica su hoja de ruta por forks. La palabra qubit suele sonar lejana, pero el calendario ya es concreto y afecta a carteras y validadores. Google Quantum AI estimó en marzo de 2026 que romper la curva elíptica de 256 bits podría exigir unos 1.200 qubits lógicos, unas 20 veces menos que estimaciones previas, según resume [ethereum.org](https://ethereum.org/roadmap/security/quantum-resistance/). El hardware actual maneja unos pocos miles de qubits físicos ruidosos y cada qubit lógico exige muchos físicos para corregir errores. La brecha sigue siendo amplia, aunque se estrecha más rápido de lo previsto hace tres años. La solución de Ethereum no es un único interruptor, sino tres caminos coordinados con herramientas distintas y ritmos propios. La capa de ejecución apuesta por cuentas flexibles que cambian de firma sin un fork por esquema. La capa de consenso prepara firmas basadas en hash con agregación mediante pruebas concisas. La capa de datos adapta el muestreo y los compromisos para firmas mucho más grandes y pesadas. ## ¿Qué protege cada capa de Ethereum? La capa de ejecución es donde firmas tus transacciones y donde viven tus cuentas y contratos. Hoy la mayoría usa ECDSA sobre secp256k1, con claves pequeñas y verificación barata en cada nodo. El riesgo futuro es que una máquina potente derive tu clave privada desde tu clave pública ya visible. La defensa pasa por dar a cada cuenta la capacidad de elegir un esquema nuevo sin esperar a toda la red. La capa de consenso es donde los validadores votan bloques con firmas BLS que se agregan en una sola prueba. BLS permite combinar cientos de miles de votos en apenas 96 bytes, una eficiencia difícil de igualar. El problema es que BLS depende de emparejamientos elípticos sensibles a avances cuánticos. La defensa exige sustituir el esquema completo mediante forks y con pruebas de rendimiento muy exigentes. La capa de datos es donde viajan los blobs y las pruebas que sostienen la disponibilidad para las capas dos. Sus compromisos actuales usan KZG, con supuestos matemáticos que también deben revisarse ante el horizonte cuántico. El reto es mantener el ancho de banda bajo control cuando las firmas crecen de 96 bytes a unos 3.000 bytes. La defensa combina muestreo eficiente y compromisos nuevos compatibles con pruebas concisas. * Ejecución para cuentas y contratos con firmas flexibles por usuario * Consenso para votos de validadores con firmas agregadas en cada slot * Datos para blobs y disponibilidad con compromisos ligeros y verificables ![Una forma más clara de ver la futura protección post-cuántica de Ethereum](https://content.observatorioblockchain.com/wp-content/uploads/2026/10/seguridad-cuantica-ethereum-infografia.webp) *Una forma más clara de ver la futura protección post-cuántica de Ethereum* Este reparto explica por qué el calendario habla de 2029 para la infraestructura central y de años extra para la migración total. Cambiar una cuenta es una decisión individual que puede hacerse por oleadas. Cambiar el consenso exige que miles de nodos adopten el mismo esquema al mismo tiempo. * Cuentas individuales que migran por oleadas con ayuda de su cartera habitual * Consenso colectivo que exige adopción coordinada en miles de nodos a la vez * Datos intermedios que acompañan a ambos ritmos sin frenar la red entre pares [Vitalik Buterin explica por qué Ethereum será mucho más que una blockchain](https://content.observatorioblockchain.com/criptomonedas/ethereum/ethereum-mas-que-blockchain-vitalik-buterin/) ## ¿Cómo cambia la ejecución sin un día de bandera? La respuesta está en la abstracción nativa de cuentas impulsada por EIP 8141 y su modelo de marcos. Cada cuenta podrá definir su propia lógica de verificación de firma dentro de las reglas del protocolo. Un usuario adoptará un esquema postcuántico cuando su cartera lo soporte y lo explique con claridad. La red no necesita detener todo para mover a millones de cuentas el mismo día. El proceso previsto ocurre en tres fases que ya aparecen en la documentación pública de octubre de 2026. Primero llega la preparación con precompilados de verificación y herramientas de cartera para pruebas controladas. Después avanza la adopción gradual, con cuentas que migran por voluntad propia y con ayuda de su programa habitual. Al final llega la consolidación del protocolo, cuando los esquemas nuevos se vuelven la opción normal para cuentas nuevas. Los candidatos en estudio pasan por Falcon y por Dilithium en una primera línea de trabajo. SPHINCS aparece como alternativa basada solo en hash con otros compromisos entre tamaño y velocidad. Elegir demasiado pronto expone a debilidad posterior o a problemas de denegación por claves grandes. Elegir demasiado tarde deja a usuarios expuestos durante la ventana de riesgo. Por eso la agilidad resulta tan valiosa como el algoritmo final para la red principal. La guía oficial mantiene que los fondos están a salvo hoy y que el programa de cartera guiará cada paso, como explica la [página de resistencia cuántica](https://ethereum.org/roadmap/security/quantum-resistance/). No necesitas mover fondos en octubre de 2026 ni cambiar de cartera por titulares sobre inteligencia artificial. Conviene actualizar solo desde fuentes oficiales y conservar respaldos probados. La migración real llegará con avisos claros dentro de tu propia aplicación. ## ¿Por qué el consenso necesita leanXMSS y leanVM? El consenso no puede copiar la receta flexible de la ejecución porque sus firmas deben combinarse en cada slot. BLS permite sumar firmas con una simple operación elíptica y mantener la red ligera. Ningún esquema postcuántico ofrece esa agregación nativa con el mismo coste. Sustituir sin más dispararía el tamaño de cada bloque y el tiempo de propagación por la red. La respuesta combina dos piezas complementarias que ya tienen nombres propios en la hoja de ruta. leanXMSS es un esquema de firmas basado solo en hash para validadores, con seguridad apoyada en SHA o BLAKE. leanVM es una máquina virtual mínima que genera pruebas concisas de que muchas firmas leanXMSS son válidas. Juntas comprimen los datos por un factor cercano a 250 y recuperan la eficiencia perdida. Las cifras ayudan a entender el salto técnico que asume la red en cada slot. Una firma BLS ocupa 96 bytes y se agrega por suma directa. Una firma hash ronda los 3.000 bytes y exige una prueba para comprimirse. Las pruebas agregadas medidas están entre 127 y 344 KiB según configuración, con objetivo de red en torno a 256 KiB por segundo. Cada diseño debe cumplir ese presupuesto sin expulsar a operadores modestos. Pieza Qué aporta Cifra central leanXMSS Firmas de validador solo con hash Unos 3.000 bytes por firma leanVM Agregación con pruebas concisas Compresión cercana a 250x Registro en I Claves postcuánticas junto a BLS Base para atestaciones Atestaciones en L Votos postcuánticos en tiempo real Finalidad económica completa EIP 8292 define además el rol de agregador para separar la prueba pesada de la producción de bloques. Cualquier nodo con hardware suficiente puede ofrecerse como agregador y probar firmas dentro del intervalo del slot. Los propositores y validadores comunes siguen verificando de forma barata una sola prueba. El diseño protege a operadores domésticos y evita centralizar la producción en pocos equipos. [El Bundesbank prueba cómo verificar operaciones financieras en Ethereum con Matter Labs](https://content.observatorioblockchain.com/criptomonedas/ethereum/bundesbank-tecnologia-matter-labs-ethereum/) ## ¿Qué pasa con los datos y las pruebas? La capa de datos sostiene la disponibilidad que necesitan las soluciones de escalado y los clientes ligeros. Cuando las firmas crecen, los blobs y las pruebas también pesan más en la red entre pares. El plan introduce muestreo adaptado llamado leanDA y compromisos seguros para blobs en la etapa M. Cada cambio busca mantener la propagación por debajo del segundo con pruebas de tamaño estable. El hito intermedio llamado MV-PQ permite seguir operando durante el día Q con garantías reducidas. Incluye latido postcuántico en consenso, muestreo leanDA en datos y transacciones leanSPHINCS en ejecución. Los investigadores aún definen con precisión qué garantías se relajan y por cuánto tiempo. La meta completa sigue siendo resistencia total en las tres capas para diciembre de 2029. La verificación formal acompaña todo el proceso como herramienta transversal y no como adorno final. La Fundación financia con 20 millones un proyecto de tres años para verificar componentes de máquina virtual de conocimiento cero, según detalla el equipo postcuántico. Esa inversión cubre primitivas que sostienen la agregación de firmas y la compresión de pruebas. Sin esa comprobación matemática, cada optimización agresiva introduciría dudas sobre la solidez del sistema. El calendario por forks ordena las piezas para que cada equipo sepa qué entregar y cuándo probar. El registro de claves llega en I junto a las claves BLS actuales. Los precompilados de verificación llegan en J para contratos y carteras. Las atestaciones y pruebas en tiempo real llegan en L con leanVM. La agregación total y los blobs seguros cierran en M y en etapas posteriores con pruebas abiertas. * Registro en I para convivir con BLS sin romper la operativa diaria * Precompilados en J para que contratos y carteras prueben firmas nuevas * Atestaciones en L para activar votos postcuánticos con finalidad completa ## Lo que conviene vigilar si haces staking desde Europa El staking mira de frente a la capa de consenso porque cada voto futuro usará el esquema nuevo. Los validadores deberán registrar claves postcuánticas junto a las actuales cuando el registro en I esté disponible. También deberán seguir los requisitos de hardware para agregadores si desean asumir ese rol con pruebas pesadas. Quienes delegan en proveedores deberán preguntar por su plan de migración y por sus pruebas en devnets. Los usuarios de carteras y de capas dos verán cambios más graduales y guiados por sus aplicaciones. Las carteras añadirán soporte para esquemas nuevos y explicarán la migración dentro de su flujo habitual. Las capas dos heredarán compromisos y pruebas de la principal sin exigir acciones técnicas al usuario final. La recomendación oficial en octubre de 2026 es no actuar por cuenta propia ni mover fondos por miedo. El debate sobre cuentas dormidas sigue abierto y afecta a la gobernanza europea del ecosistema. Nadie ha decidido cómo tratar carteras cuyos dueños no responden cuando llegue la migración. Forzar un movimiento choca con la resistencia a la censura y con derechos de propiedad. Dejarlas expuestas mantiene un riesgo sistémico si un avance teórico permite vaciarlas. La defensa en tres capas convierte un problema enorme en piezas manejables con responsables claros. Ejecución da flexibilidad al usuario sin prisas colectivas. Consenso aporta seguridad compartida con pruebas exigentes y agregación eficiente. Datos sostiene la escalabilidad sin romper la propagación entre pares. Hasta 2029, cada fork acercará esas piezas con validación pública en Europa y en todo el mundo. [Vitalik investiga un futuro donde Ethereum proteja los secretos de los contratos inteligentes](https://content.observatorioblockchain.com/criptomonedas/ethereum/vitalik-investiga-contratos-inteligentes-privados-en-ethereum/)