Autor del artículo: Mysten Labs, Kostas Chalkias y Mahdi Sedaghat

https://www.sui.io/blog/suis-post-quantum-signature-schemes

Resumen de puntos clave

  • Sui eligió ML-DSA-65 de nivel 3 de NIST, en lugar de un nivel de seguridad más bajo y de menor costo. Hoy en día, el criptoanálisis asistido por IA ya puede romper algunos esquemas de criptografía reticular que han resistido durante años la revisión manual. Además, el costo adicional de elegir un mayor margen de seguridad es casi despreciable: el rendimiento de verificación de ML-DSA-65 es prácticamente equivalente al de Ed25519.

  • Ambas soluciones provienen de dos sistemas matemáticos diferentes. El “banco” de SLH-DSA se ejecuta en Move, no en la capa de protocolo; por lo tanto, incluso si se produce un avance que rompa la criptografía reticular, no afectaría a la ruta de seguridad basada en hashes. Además, Sui puede adaptarse a cambios en estándares externos sin necesidad de actualizar el protocolo.

  • Los usuarios existentes no se verán afectados. La clave privada seguirá siendo de 32 bytes, por lo que la forma de respaldo del monedero no necesita cambiar. Las cuentas post-cuánticas usan un modo de selección voluntaria; los alias de direcciones permiten que las cuentas existentes, manteniendo la dirección y los activos originales, cambien su clave autorizada a una clave resistente a la computación cuántica.

En el artículo publicado recientemente (Sui se está preparando para la era cuántica), presentamos la dirección de Sui en términos de seguridad post-cuántica: usar ML-DSA-65 para la autenticación de cuentas nativas; usar SLH-DSA-SHA2-128s para proteger bóvedas de alto valor; y al mismo tiempo proporcionar una ruta de migración que permite conservar la dirección y la frase de recuperación existentes.

Y este artículo trata sobre el “por qué” detrás de todo, explicando en profundidad esas elecciones desde la perspectiva de los criptógrafos. Por qué elegimos ML-DSA-65 en lugar de un nivel con menor costo; por qué, aunque las firmas de Falcon sean más pequeñas, no lo elegimos; por qué SLH-DSA se coloca en contratos inteligentes en lugar de en la capa de protocolo; por qué no adoptamos directamente bibliotecas existentes, sino que escribimos un encapsulado Rust propio; y qué descubrimos durante el proceso. Si leíste el artículo anterior y quieres conocer la lógica técnica detrás de estas decisiones, este artículo es la respuesta.

Estas decisiones tienen su verdadera dificultad en otra parte: en realidad no se trata de elegir qué algoritmo. NIST ya había resuelto casi por completo este problema hace unos años. En cuanto a firmas, el conjunto de candidatos se reduce en la práctica a dos: ML-DSA (FIPS 204) y SLH-DSA (FIPS 205). El gran trabajo está después: elegir qué nivel de seguridad, adoptar qué implementación, cómo verificar el código, cómo manejar las claves que ya existen, y qué atajos que parecen atractivos técnicamente finalmente se decide no usar.

Primero, presentemos nuestro contexto. Nuestra investigación sobre sistemas post-cuánticos es anterior a Sui por varios años: en 2017, en Corda de R3, se lanzó un esquema post-cuántico de nivel producción y sin estado, que fue la primera firma post-cuántica resistente y reutilizable en el espacio de libros contables distribuidos. En los años siguientes, trabajamos con Mike Hearn en estructuras criptográficas post-cuánticas aplicables a blockchains. En Meta se construyó Winterfell, el primer probador STARK de código abierto. Y también investigamos PQ-EdDSA, HashWires y Truncator.

Sobre la estrategia de migración específica para Sui, ya la planificamos desde (Cómo garantizar la seguridad de Sui en la era de la computación cuántica) publicada en abril de 2025, incluyendo aspectos de firmas, hash, cifrado y pruebas de conocimiento cero. Lo que se presenta a continuación es la parte de firmas; en la actualidad, las decisiones relacionadas ya quedaron definidas.

Definición precisa de la amenaza

El algoritmo de Shor puede romper directamente RSA y la criptografía basada en curvas elípticas. El algoritmo de Grover solo aporta una aceleración de orden cuadrático a las funciones hash; y el aumento del tamaño del resultado del hash puede compensar esa influencia. Por ello, para blockchain, el riesgo cuántico se concentra casi por completo en las firmas, no en el hash.

Lo especial de las blockchains no está en el algoritmo en sí, sino en la forma en que se expone la clave pública. En la mayoría de los sistemas, la clave pública se encuentra detrás de algún límite de acceso; el atacante primero debe vulnerar el sistema, y entonces es cuando la cuenta atrás del ataque realmente empieza. Pero en la cadena, cuando una cuenta realiza su primera transacción, la clave pública queda expuesta de forma permanente. Al igual que “recolectar ahora y descifrar más tarde”, los ataques contra firmas ni siquiera necesitan tener ahora mismo hardware cuántico: solo requieren almacenar datos y tener paciencia para esperar. Recopilas la clave pública hoy y, cuando el hardware cuántico madure en el futuro, falsificas la firma. Esta ventana de recolección se abrió hace años, y las predicciones de capacidad de cómputo cuántico han ido cambiando siempre en la misma dirección: estimaciones sobre los recursos necesarios para descomponer una clave RSA de 2.048 bits han caído desde alrededor de 20 millones de qubits en 2019 hasta menos de 1 millón en 2025. Cada revisión implica que las máquinas necesarias son más pequeñas y más baratas, no más caras.

这也重新定义了迁移期限。美国在 2026 年 6 月发布的第 14412 号行政命令中，要求联邦机构在 2030 年 12 月前完成后量子密钥建立迁移，并在 2031 年 12 月前完成数字签名迁移，这比 NIST 仍处于草案阶段的 2035 年迁移时间表更早。而对于链上密钥来说，实际期限还要更早，因为风险是向过去累积的：一个第一天就公开的密钥，从第一天开始就已经处于暴露状态，而不是等截止日期到来时才开始暴露。

Por qué elegir ML-DSA-65 y no ML-DSA-44

NIST divide las soluciones post-cuánticas en cinco niveles de seguridad. Cada nivel corresponde a un punto de referencia de fuerza bruta, en lugar de a cifras abstractas de bits de seguridad:

  • Nivel 1: dificultad de ruptura al menos equivalente a la recuperación de una clave AES-128

  • Nivel 3: equivalente a AES-192

  • Nivel 5: equivalente a AES-256

Los niveles impares se definen según colisiones hash: Level 2 corresponde a SHA-256 y Level 4 a SHA-384.

ML-DSA ofrece tres conjuntos de parámetros:

ML-DSA-44：Nivel 2

ML-DSA-65: Nivel 3

ML-DSA-87: Nivel 5

Un nivel de seguridad representa el umbral de seguridad bajo el mejor ataque conocido en la actualidad. Por lo tanto, elegir un nivel equivale esencialmente a responder esta pregunta: si en el futuro los métodos de ataque más avanzados mejoran, ¿cuánta holgura de seguridad debemos dejar?

Sui 最终选择将 Level 3 的 ML-DSA-65 集成为协议原生签名方案，而不是成本更低的 ML-DSA-44。

Una de las razones importantes es que Anthropic recientemente descubrió un ataque contra el esquema de firma HAWK. HAWK es un esquema reticular que ha sido estudiado a fondo y que ha pasado por grandes cantidades de revisión de criptoanálisis. Es importante destacar que HAWK y ML-DSA se basan en problemas reticulares diferentes, por lo que el ataque contra HAWK no se puede aplicar directamente a ML-DSA. Pero lo que sí merece atención es la enseñanza que deja: el criptoanálisis asistido por IA ya está empezando a descubrir problemas que, pese a años de revisión por humanos, no se habían detectado.

Esto cambia cómo debemos decidir cuánta holgura de seguridad conservar bajo supuestos criptográficos basados en retículas. El margen que deja el Nivel 1 cuando cambian las estimaciones de seguridad es pequeño; mientras que el Nivel 3 ofrece un búfer mayor. Y la evidencia muestra que el costo de esta holgura adicional de seguridad es muy bajo.

Hay dos razones adicionales. Primero, Chrome y Cloudflare también eligieron Level 3 para el intercambio de claves post-cuántico que ya protege una gran parte del tráfico web; por ello, este nivel ya cuenta con más experiencia de despliegue. Segundo, al discutir el mecanismo de establecimiento de claves con la industria financiera regulada, Level 3 también se ajusta mejor a las expectativas de seguridad de estas instituciones.

El soporte de hardware también es un factor importante que consideramos. Validamos la compatibilidad con FIPS 204 directamente contra los SDK de fabricantes de HSM y monederos hardware. También probamos ML-DSA en dispositivos de nivel DePIN con consumo ultrabajo; estos representan el entorno limitado de CPU y RAM al que se enfrenta un monedero post-cuántico tipo NFC, y también son el escenario donde los problemas aparecen primero cuando el algoritmo es demasiado pesado.

Todo el ecosistema también está tendiendo a una elección similar. Ledger ya incorporó soporte preliminar oficial de ML-DSA (FIPS 204) en su SDK recientemente, y es compatible con el estándar de NIST a nivel bit. También verificamos que Ledger y nuestra implementación pueden completar interoperabilidad de firmas en ambos sentidos.

Mientras tanto, también monitoreamos continuamente el progreso de criptoanálisis contra ML-DSA. Esta incertidumbre que persiste es una de las razones por las que priorizamos lanzar SLH-DSA como solución para contratos inteligentes y recomendarlo para bóvedas de alto valor: su seguridad depende de la función hash, no de criptografía basada en retículas. Por lo tanto, incluso si en el futuro aparecen avances en retículas que afecten las estimaciones de seguridad de ML-DSA, eso no afectará a SLH-DSA.

¿Por qué no elegir Falcon?

Otro candidato basado en retículas es Falcon (FN-DSA, es decir, el futuro FIPS 206). Su mayor ventaja es que las firmas son más pequeñas. En Level 1, FN-DSA-512 tiene un tamaño de firma de solo 666 bytes, mientras que el de ML-DSA-65 en Level 3 es de 3.309 bytes.

Aun así, no elegimos Falcon. Las razones incluyen:

  • No hay Nivel 3. Falcon solo ofrece dos niveles de seguridad (FN-DSA-512 y FN-DSA-1024): o eliges el Level 1 con menos holgura que acabamos de mencionar, o pagas el costo del Level 5 para obtener un búfer mayor, y este último haría que todas las métricas se multipliquen aproximadamente por dos.

  • No se ha completado la estandarización. FIPS 206 aún no está finalizado; en comparación, FIPS 204 ya quedó oficialmente cerrado desde 2024.

  • Falta de un método estandarizado de derivación de semilla a clave. Esto rompe la propiedad de semilla de 32 bytes que actualmente permite que el respaldo del monedero se mantenga sin cambios.

  • Muestreo gaussiano con punto flotante. En el proceso de firma de Falcon, se necesita realizar un FFT discreto gaussiano con números de punto flotante para el muestreo gaussiano. En general, este mecanismo se considera más difícil de completar correctamente que cualquier implementación necesaria para ML-DSA. En cambio, ML-DSA usa operaciones enteras de principio a fin.

  • Mayor dificultad para una implementación segura. Con el mecanismo de muestreo gaussiano, hay exigencias de implementación más altas para asegurar ejecución en tiempo constante, resistencia a ataques de fallos y ataques de caché, y además garantizar la calidad del azar.

  • Protección frente a canales laterales más difícil. Debido a la inclusión del muestreo gaussiano y operaciones FFT, se considera en general que Falcon es más difícil de hacer seguro y confiable que ML-DSA frente a ataques de temporización, ataques de caché y ataques de fallos.

  • Rendimiento de verificación. En niveles de seguridad más altos, la velocidad de verificación de Falcon es más lenta que los resultados de nuestras pruebas de ML-DSA. En concreto, en la misma máquina, el tiempo de verificación de FN-DSA-1024 es de 49,8 microsegundos, mientras que ML-DSA-65 es de solo 23,2 microsegundos. Es decir, dado un margen de seguridad suficiente, la velocidad de verificación del conjunto de parámetros de Falcon es aproximadamente 2 veces más lenta que el esquema que elegimos.

  • Ecosistema de hardware. Muchos fabricantes de HSM, tarjetas inteligentes, TPM y elementos seguros dan prioridad a ML-DSA: ya completó la estandarización antes, es más fácil de implementar y también es una de las soluciones que los clientes empresariales más exigen que se soporte. Según los comentarios que recibimos, el soporte de hardware para Falcon está mejorando, pero aún no llega a la misma difusión que ML-DSA.

  • Por último, igual de importante es el ecosistema y las herramientas. En la actualidad, ML-DSA es más maduro en cuanto a bibliotecas, SDK, vectores de prueba, paquetes de cumplimiento e implementaciones certificadas. Esto reduce el riesgo de implementación de ingeniería, especialmente cuando se usa como una función nativa en el protocolo.

Por tanto, un tamaño de firma más pequeño no compensa estas desventajas.

Por qué SLH-DSA se ejecuta en Move y no en la capa de protocolo

Para activos de alto valor, ofrecemos bóvedas inteligentes de contratos en Move basadas en hash de SLH-DSA-SHA2-128s (FIPS 205), en lugar de ofrecerlo como un esquema de firma nativo del protocolo. Esto no se debe a que no confiemos en SLH-DSA. Todo lo contrario: la criptografía basada en hash es, entre ambos sistemas, la que se entiende con más profundidad y SHA-256 ya está ampliamente utilizada. Algunos equipos de monederos hardware con los que consultamos incluso prefieren los esquemas basados en hash, porque los ingenieros los entienden mejor.

Las razones para ponerlo en los contratos son, principalmente, tres:

  • Características de costo. El costo de verificación de SLH-DSA es claramente más alto que el de Ed25519, y además su tamaño de firma es mayor; por ello, no se puede reducir la carga de manera efectiva mediante caché. Para ML-DSA, la clave pública es una parte reutilizable, así que la caché aporta beneficios notables; mientras que SLH-DSA no ofrece espacios de optimización similares.

  • Riesgo de cambios de estándar. Es muy probable que Bitcoin, Ethereum y el siguiente ciclo de estándares de NIST terminen convergiendo en un conjunto menor de esquemas de firma que el actual. Independientemente de qué esquema elijan las comunidades de Bitcoin y Ethereum, incluidos los diversos esquemas basados en hash que se discuten hoy, esperamos poder implementar rápidamente la compatibilidad. El puente entre Sui y Ethereum, y también Hashi orientado a Bitcoin, hacen esta necesidad más práctica: si se implementa dentro de contratos, los monederos de Bitcoin en Sui que admitan cifrado post-cuántico compatible no necesitarán publicar una nueva versión del núcleo de Sui; si se implementa de forma nativa, cada vez que cambie el estándar objetivo externo, podría ser necesaria una actualización de protocolo.

  • Alcance de implementación. La implementación de SLH-DSA en Move se centra principalmente en operaciones relacionadas con árboles Merkle; comparado con agregar un autenticador nativo adicional, el alcance es menor y el código es más claro y fácil de entender. Además, puede desplegarse sin bifurcar ni actualizar el protocolo, porque la manipulación de bytes y los primitivos hash necesarios ya existen en el lenguaje Move.

Estos dos esquemas se basan en diferentes sistemas matemáticos, y ahí está la clave del diseño. Si se rompe el supuesto de seguridad de la criptografía basada en retículas, eso no afectará la ruta de seguridad basada en hash; y ocurre lo contrario también.

Para las cuentas de mayor valor, el mecanismo existente de multisig 2-de-2 en Sui también permite a los usuarios exigir simultáneamente que una firma tradicional y una post-cuántica autoricen una transacción. Por lo tanto, ningún esquema se convierte por sí solo en un único punto de falla dentro del sistema de seguridad. Esta es también la razón por la que recientemente, en una discusión iniciada por Bernstein, se defendió un esquema híbrido de seguridad.

Ambos esquemas siguen los algoritmos criptográficos post-cuánticos estandarizados por NIST (ML-KEM, ML-DSA, SLH-DSA) y la hoja de ruta de preparación para seguridad cuántica definida conjuntamente por CISA, NSA y NIST.

Pruebas de rendimiento

Todas las elecciones anteriores terminan dependiendo del costo. Hicimos pruebas con fastcrypto en Apple M2 Max.

Aquí lo verdaderamente importante son dos cosas.

El rendimiento de verificación está prácticamente a la par con Ed25519, e incluso ligeramente mejor; por lo tanto, el costo de CPU que requiere cada firma en los nodos verificadores no aumenta. Esto es crucial, porque Sui es una de las L1 más rápidas del mundo y, incluso después de la migración post-cuántica, debemos seguir manteniendo esta ventaja. La métrica verdaderamente importante es el costo de verificación, ya que los costos de cómputo en distintos pasos ocurren en diferentes lugares: generación de claves y firma se hacen fuera de la cadena para cada transacción, en el dispositivo del firmante; la verificación, en cambio, requiere que cada nodo verificador ejecute la verificación para cada transacción. En términos absolutos, la velocidad de firma sí es más lenta, pero en el dispositivo del cliente solo tarda alrededor de 66 microsegundos, y en el navegador incluso se mantiene en el rango de milisegundos, por lo que el usuario casi no percibe la diferencia.

La clave privada sigue manteniendo 32 bytes, porque en esencia es una semilla. El monedero puede seguir haciendo respaldos y restauraciones de la misma manera que ahora; mientras que las nuevas claves se generan mediante una nueva ruta de derivación estándar a partir de la misma frase de recuperación que ya tienes en tu poder.

El costo real que hay que pagar es el volumen de datos: los datos relacionados con cada transacción aumentarán aproximadamente hasta 50 veces. Este es el costo que toda la industria debe asumir para obtener capacidades resistentes a la computación cuántica, y es también el enfoque principal de nuestras optimizaciones. Sin embargo, para Sui hay dos factores que amortiguan este problema. Primero, el límite superior del tamaño de las transacciones en Sui puede llegar hasta 128 KB, así que en comparación con cadenas de bloques con restricciones de tamaño de transacción más estrictas, hay más espacio. Segundo, anteriormente ya publicamos y ejecutamos en la práctica esquemas que incluyen firmas grandes, como multisig y zkLogin. Además, las transacciones programables (PTB) permiten que una firma autorice múltiples operaciones; por ello, el costo adicional promedio por operación es, en realidad, menor que el resultado inferido únicamente a partir del tamaño de una sola firma. En el futuro, incluso se podría adoptar un mecanismo similar al caché de claves públicas que existe actualmente en zkLogin: el usuario solo envía su clave pública una vez y, después, las transacciones solo necesitan enviar la firma. Sin embargo, esta función no se habilitará en la versión inicial. Queremos que la primera implementación se mantenga relativamente conservadora y que esta optimización se vaya habilitando gradualmente tras una consideración suficiente.

Además, hay que aclarar que los datos anteriores representan solo una configuración de prueba. Para un informe de rendimiento más completo y riguroso, habría que cubrir la ruta de ejecución Rust en el lado del nodo verificador, configuraciones típicas de desarrolladores comunes, y las firmas del lado del navegador realizadas mediante el stack de TypeScript. Planeamos publicar después datos de prueba más completos. Para una comparación más integral de los esquemas de firma candidatos de NIST, consulta nist-sigs-zoo.

Además, la investigación Remora de Sui sobre extensiones de ejecución también hace que los problemas de expansión de throughput involucrados durante la migración post-cuántica sean más fáciles de manejar. Estas dos líneas de investigación se impulsaron de manera intencional desde el principio de forma coordinada.

La manera de implementarlo, y por qué decidimos hacerlo nosotros

Casi todos los lenguajes de programación tienen grandes bibliotecas de criptografía, y en ellas ya está incluida ML-DSA. Así que introducir una biblioteca existente parece la opción más obvia. Pero nosotros hicimos algo diferente: desarrollamos mysten-mldsa-native-rs, un encapsulado Rust ligero construido sobre mldsa-native. mldsa-native es una implementación compacta de ML-DSA con verificación formal mantenida por el proyecto pq-code-package de Linux Foundation. Comparte el mismo núcleo con bibliotecas criptográficas populares de la industria como aws-lc, solo que no incluye los demás componentes de una biblioteca grande.

Hacerlo así se basa en que esta porción de código está en la ruta de ejecución del consenso. Cada nodo verificador necesita ejecutar el código de verificación para cada transacción, por lo que queremos reducir al máximo el alcance de la implementación para que el código sea fácil de leer y auditar, y al mismo tiempo evitar opciones que puedan configurarse de forma incorrecta. Este encapsulamiento ofrece un único modo: el modo predeterminado de FIPS 204, usando hedged signing (firma con cobertura), es decir, que cada firma utilice nueva aleatoriedad para mejorar la resistencia frente a ataques de fallos y problemas de reutilización del aleatorio. No incluye un generador de números aleatorios, de modo que cada operación se puede reproducir en el entorno de pruebas. Además, la clave privada tiene solo un formato de serialización: una semilla de 32 bytes, lo que permite al monedero seguir haciendo respaldos y restauraciones de la misma manera exacta de siempre.

Como se mencionó antes, nuestra velocidad de implementación es muy alta. Esto se debe principalmente a que aguas arriba ya existen implementaciones ensambladas verificadas para Apple/ARM y servidores x86. El sistema seleccionará en tiempo de ejecución la implementación correspondiente según la máquina, asegurando que el mismo binario funcione correctamente en entornos mixtos de hardware de nodos verificadores. Independientemente de qué implementación subyacente se use, las firmas generadas serán exactamente las mismas. La diferencia está únicamente en el rendimiento: la velocidad del backend en ensamblador es aproximadamente 2,5 veces la de una implementación en C portable.

Un punto de fallo poco discutido

El verdadero peligro de la criptografía nueva suele no estar en las matemáticas, sino en el código y en las implementaciones apresuradas.

Este año, se divulgó que un probador STARK líder tiene una vulnerabilidad de solidez: un cierto valor en el que confía el nodo verificador no queda realmente vinculado al transcript de la prueba. Por ello, un probador malicioso puede falsificar una prueba de afirmación incorrecta, y aun así el nodo verificador la aceptará. Esta vulnerabilidad existe en el código abierto desde 2024, ha pasado auditorías externas y verificación formal, pero nunca se había detectado. Finalmente, en junio de 2026 fue identificada por herramientas de auditoría con IA; por suerte, no se había aprovechado antes.

El propio ML-DSA ya ha tenido casos similares. Solo en 2026, en tres repositorios de código independientes de este esquema de firma se revelaron cuatro vulnerabilidades a nivel de implementación:

  • Hay una vulnerabilidad de escritura fuera de límites en el flujo de firmas de libgcrypt (CVE-2026-41990);

  • En el crate ml-dsa de RustCrypto existe una vulnerabilidad de canal lateral temporal durante el cálculo de hint, que podría causar la filtración de información de la clave de firma (CVE-2026-22705);

  • También hay una vulnerabilidad de verificación en el mismo crate, que acepta erróneamente firmas que contienen índices de hint duplicados (CVE-2026-24850);

  • En el código post-cuántico para dispositivos embebidos de wolfSSL hay una vulnerabilidad de inyección de fallos (CVE-2026-3503).

De entre todo, el asunto que más vale la pena observar es el fallo de verificación: según la norma FIPS 204, una firma válida tiene solo una forma de codificación legal. Si una implementación acepta erróneamente la segunda codificación, entonces determinar si una firma es válida podría depender de qué nodo le preguntes. En blockchain, eso podría causar una división de la cadena.

Mientras tanto, en el mismo periodo, el número de veces que la matemática subyacente de ML-DSA fue vulnerada en sí misma fue cero.

Dicho de otro modo: hoy la base matemática sigue sólida y el riesgo real está más en la capa de implementación del código.

Repetimos esta historia una y otra vez porque ofrece un referente de evaluación de riesgos muy importante y razonable para lo que sea que publiquemos; los resultados de investigación de HAWK también apuntan en la misma dirección. Durante mucho tiempo confiamos en nuestros mecanismos de revisión anteriores —incluyendo auditoría manual, métodos formales y el hecho de que el código se sometió durante años a examen público—, y aun así no se encontraron estos problemas. Pero el análisis asistido por IA sí los detectó.

Esto demuestra aún más que necesitamos:

  • Reservar suficiente holgura de seguridad al elegir parámetros;

  • Mantener el alcance de la implementación lo más pequeño posible y fácil de auditar;

  • Convertir la verificación entre implementaciones en un umbral obligatorio en el proceso de construcción;

  • Adoptar una estrategia de despliegue más cautelosa, paso a paso, para componentes que son más recientes y con menor madurez.

Esta es también la razón por la que hablaremos de la siguiente parte.

No vamos a pulsar todavía ese botón

En realidad tenemos un atajo más ideal que el esquema que usamos ahora, pero por el momento no lo elegimos.

En Sui, cada clave Ed25519 se deriva a partir de una semilla protegida mediante hash. Incluso si una computadora cuántica logra romper el sistema criptográfico de curvas elípticas, solo podría recuperar el escalar de firma, pero no podría reconstruir la semilla original que generó ese escalar. Nuestro artículo de investigación Post-Quantum Readiness in EdDSA Chains (Baldimtsi, Chalkias, Roy y Sedaghat, eprint 2025/1368) aprovecha esta asimetría para convertirla en una prueba de propiedad resistente a la computación cuántica: el usuario puede demostrar mediante pruebas de conocimiento cero que posee la semilla original, autorizando así una nueva clave post-cuántica, manteniendo al mismo tiempo la dirección existente, y sin exponer ninguna información secreta durante todo el proceso.

Este esquema tiene algunas características mejores que migrar mediante nuevas rutas de derivación. Se aplica a cuentas en las que la clave pública ya está expuesta; también puede aplicarse retrospectivamente a claves derivadas hace muchos años; e incluso funciona para cuentas en modo de reposo que, en el futuro, no volverán a firmar ninguna transacción. Esta es una categoría de cuentas que los otros esquemas de migración no pueden cubrir, y para blockchains que no admiten derivación determinista de semillas, estas cuentas ni siquiera pueden migrarse mediante esta vía. Esta es precisamente la ventaja estructural que tienen las blockchains EdDSA frente a las blockchains ECDSA, y por eso este documento estudia específicamente EdDSA.

Entonces, si este esquema es tan bueno, ¿por qué no se habilita directamente ahora? Porque este “botón” en esencia es un sistema de pruebas de conocimiento cero. Si se activara ahora, la seguridad de la cuenta dependería de ese sistema de pruebas, y la tecnología en sí es más joven que el esquema de firma que protege. Combinado con el riesgo de implementación mencionado en la sección anterior, esta es precisamente la razón por la que elegimos ser prudentes.

El costo de esperar es en realidad muy pequeño, porque este “botón” no caduca. Una semilla no deja de ser secreta simplemente por el paso del tiempo. Cuando el sistema de pruebas de conocimiento cero haya acumulado suficientes verificaciones de seguridad y confianza, todavía podremos construir y habilitar este mecanismo de pruebas. Mientras tanto, haremos primero la migración de una forma más directa: mediante rutas de derivación nuevas que admiten cuentas post-cuánticas nativas, y usando alias de direcciones para ayudar a las cuentas existentes a migrar.

Por lo tanto, por ahora tratamos zkPQ-EdDSA como un interruptor de seguridad de emergencia que puede habilitarse en el futuro si fuera necesario, en lugar de como una función de lanzamiento inicial. Hay otra característica de diseño que vale la pena notar: dado que en Sui la clave privada de ML-DSA también es una semilla de 32 bytes, en el futuro, si fuera necesario, el mismo mecanismo de “prueba de posesión de la semilla” también podría aplicarse aún más a las propias cuentas post-cuánticas.

Mecanismo de migración

En las dos actualizaciones de seguridad, Sui proporcionará nuevas rutas de derivación estándar y aplicará selección voluntaria a nivel de cuenta. Las cuentas existentes no necesitan transferir fondos. Los alias de direcciones (Address Aliases) ya desplegados permiten a las cuentas actualizar la clave autorizada a una clave post-cuántica, mientras: la dirección no cambia y los activos permanecen en el mismo lugar. Para usuarios existentes, la migración que realmente realizan es este mecanismo, no el esquema de pruebas de conocimiento cero mencionado antes, que además está siendo pospuesto en la actualidad.

Para la bóveda resistente a lo cuántico, los retiros usan un modelo de dos transacciones; una transferencia simple podría requerir solo una. Para desarrolladores e instituciones, el significado práctico es muy claro: las cuentas resistentes a lo cuántico se irán desplegando como una funcionalidad opcional nueva, de manera gradual, como ocurre con zkLogin y Passkeys. No se fuerza la migración y las funciones existentes no cambian. Activarlo es solo una actualización rutinaria de funcionalidad del protocolo, no un cambio en el mecanismo de consenso ni en el estado existente.

¿Hasta dónde ha llegado la industria?

No somos el único equipo que está haciendo esto, y tampoco queremos ser el único. Near ya lanzó ML-DSA-65 este verano como un tipo de clave opcional, con el mismo esquema y nivel de seguridad que eligió Sui; esto también es una señal independiente valiosa. La hoja de ruta de consenso de Ethereum se inclina más por esquemas basados en hash. Bitcoin tiene actualmente varias propuestas activas, pero aún no ha tomado una decisión final.

Creemos que el verdadero liderazgo de Sui no consiste en elegir qué algoritmo, sino en el diseño de la arquitectura:

  • Dos esquemas corresponden a dos modelos de amenaza;

  • La bóveda puede adaptarse a estándares externos sin actualizar el protocolo;

  • Los usuarios pueden conservar sus direcciones existentes.

Estado actual y cronograma

La implementación principal ya está lista y se han hecho pruebas de rendimiento. Plan actual:

  • Bóveda resistente a lo cuántico: en línea con la mainnet este año;

  • Cuenta ML-DSA-65 nativa: para fin de año en la testnet;

  • Autenticación de cuentas nativas: como máximo, llegar a la mainnet en el primer trimestre de 2027.

El soporte para monederos, SDK y CLI se lanzará simultáneamente.

La auditoría externa independiente está en curso. No podemos garantizar que todas las auditorías terminen completamente según lo planeado; por eso, preferimos posponer la fecha antes que desplegar un autenticador que no ha sido auditado suficientemente. Por lo tanto, este artículo presenta la dirección actual; el cronograma final aún puede ajustarse según los resultados de auditoría y los comentarios de la testnet.

Todo lo necesario para la revisión pertinente ya es público, incluyendo FIPS 204, FIPS 205, una implementación mldsa-native en C verificada formalmente, el encapsulado nativo en Rust de Mysten mysten-mldsa-native-rs, y la implementación open source de Post-Quantum Readiness in EdDSA Chains que actualmente hemos decidido retrasar el despliegue.

Más que buscar elogios, queremos que este trabajo sea sometido a escrutinio. Hemos hecho a propósito que el alcance de la implementación esté lo más controlado posible; hemos fijado de forma intencional la verificación cruzada como un umbral obligatorio de construcción; y hemos retrasado la adopción de atajos de migración. Si trabajas en firmas post-cuánticas, monederos hardware o sistemas de pruebas, y crees que alguna de estas decisiones está mal, nos gustaría mucho escuchar tu opinión.

Un huevo de pascua

La ruta de derivación es la regla que sigue el monedero al convertir una frase mnemónica en múltiples claves: está compuesta por una pequeña secuencia de números aplicados paso a paso de manera secuencial. Por ello, la misma frase mnemónica genera las mismas claves en cualquier dispositivo. Todas las claves basadas en frases mnemónicas en Sui se derivan a través de esa ruta, y el primer número de la ruta —el índice de uso— se usa para identificar el esquema de firma.

Actualmente, las claves Ed25519 en Sui usan la siguiente ruta de derivación:

m/44'/784'/0'/0'/0'

En este caso, 784' representa Sui y 44' es el índice de uso; el esquema de firmas ECDSA utiliza, respectivamente, 54' y 74'. Las claves post-cuánticas usarán:

m/94'/784'/0'/0'/0'

Aquí el “94” no es solo el siguiente número en una secuencia: representa un año. Casualidades mediante, Peter Shor publicó en 1994 el algoritmo que hizo que todo esto fuera necesario. Para conmemorar esta coincidencia, cada ruta de derivación de una clave segura cuántica de Sui incluye el año desde el cual comienza esta cuenta atrás.