Presentamos el Plan de Preparación Cuántica

Hoy estamos presentando el Plan de Preparación Cuántica (QPP) para la red de Stellar—el programa para migrar la red a criptografía poscuántica.

Para finales de 2027, además de la ventaja estructural que tiene Stellar al separar la identidad de la cuenta de las claves de firma, se espera que toda cuenta de Stellar pueda agregar un firmante poscuántico mediante una actualización nativa del protocolo, manteniendo la misma dirección y el mismo historial. Se espera que las billeteras empresariales puedan pasar a la firma poscuántica en 2026 a través de cuentas de contrato de Soroban.

Las computadoras cuánticas eventualmente romperán la criptografía de curva elíptica que asegura casi todas las blockchains, incluida Stellar. Esto no es especulativo—es una certeza matemática dada una computadora cuántica lo suficientemente potente. La pregunta abierta es cuándo, no si.

Es importante destacar que esta amenaza se extiende mucho más allá de las blockchains. Las criptografías de curva elíptica y RSA sustentan TLS, SSH, la firma de código y prácticamente todas las comunicaciones seguras que protegen el internet tal como lo conocemos. Cada industria principal—finanzas, salud, defensa, telecomunicaciones—enfrenta el mismo reto de migración. Esto significa que recursos significativos en todo el ecosistema tecnológico global están trabajando en soluciones poscuánticas, produciendo estándares maduros, herramientas y experiencia de implementación que el ecosistema de Stellar puede aprovechar.

Desarrollos recientes han comprimido el cronograma. A inicios de 2026, investigadores de INRIA mostraron que romper curvas elípticas de 256 bits (la familia a la que pertenece Ed25519 de Stellar) requiere solo 1.193 qubits lógicos—una reducción del 44% respecto de estimaciones previas y menos de lo necesario para romper RSA-3072. Por separado, nuevas arquitecturas de corrección de errores cuánticos han reducido el sobrecosto de qubits físicos para ataques criptográficos en un orden de magnitud. La guía del National Institute of Standards and Technology (NIST), que previamente ubicaba la zona de peligro en 2030 y más allá, se ha actualizado a 2029+. Google ha fijado 2029 como su plazo interno para estar listo para lo poscuántico en todos sus sistemas—y Google tanto construye hardware cuántico como emplea a los investigadores detrás de estos avances.

En el frente de los estándares, NIST finalizó los primeros estándares criptográficos poscuánticos en 2024 (ML-DSA para firmas, ML-KEM para encapsulación de claves), con esquemas adicionales en preparación. Ya existen los bloques de construcción para la migración. Otras blockchains ya se están moviendo: Ethereum ha redactado un plan de hard fork de emergencia, Bitcoin tiene BIP-360 y Algorand ha implementado pruebas de estado basadas en Falcon. Los marcos regulatorios—CNSA 2.0 en EE. UU., DORA en la UE—están recomendando cronogramas de migración PQ para la infraestructura financiera, señalando la dirección de las expectativas de cumplimiento futuras.

La combinación de un cronograma de amenaza acelerándose, estándares finalizados y el impulso de la industria hace que este sea el momento adecuado para definir la estrategia para Stellar. Comenzar ahora garantiza una migración deliberada en lugar de esperar para responder a una crisis.

Hay dos amenazas para Stellar provenientes de computadoras cuánticas lo suficientemente potentes, y requieren soluciones diferentes.

Integridad de la red. Los mensajes de Stellar Consensus Protocol son autenticados con firmas Ed25519 por validadores. Un atacante que pueda falsificar suficientes firmas de validadores para controlar la intersección de quórum puede comprometer el consenso mismo. Esta es una amenaza seria pero un problema de coordinación más tratable—hay cientos de validadores, no decenas de millones de cuentas. La integridad de la red se abordará mediante una actualización del protocolo a SCP.

Toma de control de cuentas. El algoritmo de Shor puede derivar la clave privada de cualquier clave pública Ed25519. En Stellar, las direcciones de cuenta (direcciones G...) codifican directamente la clave pública Ed25519, lo que significa que cada dirección de cuenta en la red es un objetivo—incluidas las cuentas inactivas que nunca han autorizado una transacción. Esta es una diferencia estructural con Bitcoin y Ethereum, donde las direcciones son hashes de claves públicas y solo quedan expuestas tras el primer uso.

La toma de control de cuentas es el problema más difícil y el foco de QPP.

En la mayoría de las cadenas, la dirección de la cuenta es la clave pública. Rotar claves significa mover saldos a una nueva cuenta y actualizar cada sistema externo que hace referencia a la dirección antigua.

En Stellar, la identidad de la cuenta está separada de las claves de firma. La dirección G... es un identificador estable, y las claves que autorizan transacciones en la cuenta pueden rotarse mediante la operación set_options existente sin cambiar la dirección. Una cuenta de Stellar no necesita migrar a una nueva cuenta para volverse poscuántica. Necesita agregar un firmante poscuántico a la cuenta que ya tiene, ponderarlo adecuadamente y luego eliminar el firmante Ed25519 heredado.

La pieza que falta hoy es el propio tipo de firmante poscuántico, junto con los primitivos de protocolo requeridos para verificar firmas poscuánticas de manera eficiente. QPP trata, en gran medida, de construir ese tipo de firmante y la infraestructura a su alrededor.

Etapa 1—Bloques básicos y cuentas de contrato (2026). Agregar verificación de firmas poscuánticas a Soroban como funciones nativas del host, con soporte para ML-DSA-44 y ML-DSA-65—los estándares de firma de NIST de nivel empresarial. Con esos primitivos en su lugar, las cuentas de contrato pueden implementar autenticación poscuántica a través de la capa de abstracción de cuentas de Soroban, sin requerir cambio a nivel de protocolo para las cuentas clásicas. Las billeteras empresariales pueden migrar a cuentas de contrato poscuánticas en 2026. Se agregarán esquemas adicionales con el tiempo a medida que se finalicen los estándares (FN-DSA, también conocido como Falcon) o a medida que se sume soporte más amplio del ecosistema (por ejemplo, compatibilidad con HSM para despliegue en la nube).

Etapa 2—Consagración a nivel de protocolo y migración voluntaria (opt-in) (2027). Una Propuesta de Avance del Núcleo introducirá tipos de firmante poscuánticos como firmantes de primera clase en cuentas clásicas. Cada cuenta G... existente puede agregar un firmante poscuántico junto a su firmante Ed25519 mediante set_options. Sin nuevo tipo de cuenta, sin cambio de dirección, sin migración de saldo. Se actualizarán billeteras, SDKs, anclajes y SEPs para admitir generación de claves, firma y verificación poscuánticas.

Etapa 3—Obsolescencia (tiempo determinado por la amenaza). El trabajo de preparación estará completo en 2027. La activación—el libro mayor en el que Ed25519 ya no se aceptará para autorizar nuevas transacciones—se determinará por el progreso de la computación cuántica y la preparación del ecosistema.

La activación requerirá aporte de la comunidad, ya que es probable que venga con cierta disrupción para algunas cuentas: Stellar tiene una gran población de cuentas inactivas cuyos titulares no se pueden contactar. Cualquier corte forzado requiere congelar estas cuentas y debe elegir entre proporcionar un mecanismo de recuperación (Stellar, a diferencia de muchas otras cadenas, admite pruebas basadas en semilla), o aceptar que queden bloqueadas permanentemente. Abriremos esto para discusión de diseño comunitaria en lugar de presentar una decisión unilateral.

El QPP aún no aborda los protocolos de conocimiento cero basados en emparejamientos construidos sobre Stellar. Varios protocolos ZK dependen de SNARKs sobre curvas como BN254 y BLS12-381, que el algoritmo de Shor rompe por la misma razón que rompe Ed25519. A diferencia de los esquemas de firma, no hay un sustituto directo poscuántico para los SNARKs basados en emparejamientos con rendimiento comparable. Los STARKs y los sistemas de pruebas basados en retículas son candidatos, cada uno con compensaciones significativas.

Este es un problema que la industria en general necesitará resolver en conjunto. Como parte del QPP convocaremos a equipos de protocolos ZK que están construyendo sobre Stellar para desarrollar una agenda de investigación compartida.

El QPP no es un trabajo que SDF pueda ejecutar solo. Validadores, billeteras, anclajes, custodios, mantenedores de SDK y desarrolladores de contratos de Soroban tienen todos un papel. Durante las próximas semanas publicaremos especificaciones técnicas detalladas, abriremos la discusión comunitaria sobre la cuestión de las cuentas inactivas e iniciaremos conversaciones a nivel de protocolo sobre el soporte de funciones de host de Soroban para la verificación de firmas poscuánticas.