Sui Planea Firmas Resistentes a la Computación Cuántica Sin Mover los Fondos de los Usuarios
Puntos clave
- •Sui planea admitir ML-DSA-65 para cuentas estándar y SLH-DSA-SHA2-128s para bóvedas de mayor valor, utilizando dos esquemas de firma post-cuántica estandarizados por NIST y finalizados en agosto de 2024.
- •El sistema de Address Aliases de Sui permite que una cuenta existente autorice a un firmador post-cuántico sin cambiar su dirección ni transferir activos.
- •Se prevé que las bóvedas resistentes a la computación cuántica lleguen a Mainnet antes de finales de 2026, mientras que la autenticación nativa de cuentas ML-DSA-65 se espera en Mainnet en el primer trimestre de 2027.
- •Las firmas post-cuánticas son sustancialmente más grandes que las firmas Ed25519 actuales, con ML-DSA-65 produciendo firmas de 3,309 bytes en comparación con los 64 bytes de Ed25519.
- •La migración será aditiva y opcional, y Sui advierte que cualquier mensaje que afirme que los usuarios deben transferir fondos urgentemente para volverse resistentes a la computación cuántica es inconsistente con su diseño.

Sui ha detallado su enfoque para introducir la criptografía post-cuántica sin requerir que los usuarios asuman uno de los aspectos más disruptivos de una actualización de seguridad en blockchain: transferir todos los activos a una cuenta nueva.
Según el anuncio del 6 de agosto de la Sui Foundation, la red tiene la intención de admitir ML-DSA-65, estandarizado por NIST bajo FIPS 204, para cuentas estándar, y SLH-DSA-SHA2-128s, estandarizado bajo FIPS 205, para bóvedas de mayor valor construidas con contratos inteligentes de Move. Ambos esquemas están diseñados para resistir ataques de computadoras cuánticas a gran escala que eventualmente podrían amenazar las firmas de curva elíptica utilizadas en todo el ecosistema de criptomonedas en la actualidad. NIST finalizó FIPS 204 y 205 en agosto de 2024 como los primeros estándares de firma post-cuántica aprobados por el gobierno de EE. UU., culminando una competencia pública de varios años que comenzó en 2016.
El modelo de amenaza es bien comprendido en los círculos criptográficos. El algoritmo de Shor, si se ejecuta en una computadora cuántica suficientemente grande y tolerante a fallos, podría derivar claves privadas a partir de claves públicas que son visibles públicamente en cada libro mayor de blockchain. Debido a que las claves públicas se exponen en el momento de la transacción, un adversario podría teóricamente registrar transacciones firmadas hoy y romper las claves subyacentes una vez que llegue el hardware cuántico capaz, una preocupación a menudo descrita como "cosechar ahora, descifrar después". Ninguna computadora cuántica de conocimiento público puede actualmente realizar este ataque a la escala necesaria para claves criptográficas de producción, pero investigadores de la academia y la industria, incluyendo equipos de IBM, Google y laboratorios nacionales, continúan avanzando en el conteo de qubits y la corrección de errores.
La Cuenta Puede Permanecer Incluso Cuando Cambia la Clave
Reemplazar la criptografía detrás de una cuenta de blockchain generalmente requiere que los usuarios creen una nueva dirección y transfieran tokens, NFT y otros activos. Las aplicaciones y contratos vinculados a la dirección anterior también pueden requerir ajustes. Para la mayoría de las redes de blockchain, esto significa que una transición post-cuántica requeriría que cada titular moviera activamente sus fondos, un desafío de coordinación que se vuelve más difícil a medida que crecen la base de usuarios y el ecosistema de contratos desplegados de una cadena.
El sistema existente de Address Aliases de Sui ofrece una solución a este problema. Una cuenta puede mantener un conjunto de alias autorizados, permitiendo que otro firmador autentique transacciones en nombre de la dirección original. Un nuevo firmador puede ser añadido a ese conjunto autorizado y eventualmente convertirse en el único firmador permitido para aprobar transacciones, mientras que la dirección original continúa apareciendo como el remitente.
Cuando las cuentas ML-DSA estén disponibles, Sui afirma que una cuenta existente podrá autorizar a un firmador post-cuántico conservando la misma dirección. Esto es particularmente relevante para cuentas ya conectadas a contratos inteligentes, identidades u otras aplicaciones donde cambiar una dirección crearía sustancialmente más trabajo que simplemente transferir tokens SUI.
El proceso de recuperación también está diseñado para seguir siendo familiar. Una clave ML-DSA-65 puede derivarse de la frase de recuperación existente de un usuario a través de una nueva ruta de derivación, en lugar de requerir un método de respaldo completamente diferente.
Un alias autorizado tiene autoridad total sobre la cuenta. La documentación de Sui advierte que añadir uno efectivamente otorga a ese firmador el control sobre los activos propiedad de la dirección, lo que significa que el software del monedero deberá dificultar el uso indebido o la comprensión errónea del proceso de migración.
Por Qué Sui Utiliza Dos Sistemas Diferentes Resistentes a la Computación Cuántica
Sui no depende de un único diseño post-cuántico para todos los casos de uso.
ML-DSA-65 se basa en retículos y está destinado a la firma rutinaria de transacciones. Corresponde a la Categoría de seguridad 3 de NIST, ofreciendo un mayor margen de seguridad que la configuración más pequeña ML-DSA-44 mientras sigue siendo práctico para la verificación frecuente.
Sui también hizo referencia al reciente descubrimiento asistido por IA de una debilidad en HAWK, otro candidato de firma post-cuántica. El hallazgo no comprometió ML-DSA, pero demostró con qué rapidez el criptoanálisis automatizado puede desafiar diseños que ya han sido sometidos a una extensa revisión humana.
Para bóvedas de mayor valor, Sui planea admitir SLH-DSA-SHA2-128s a través de contratos inteligentes de Move. Esta es una configuración de Categoría 1, por debajo de la calificación de Categoría 3 de ML-DSA-65. La justificación de Sui proviene de su diseño basado en hashes, que ofrece una alternativa a las suposiciones de retículos de ML-DSA y reduce la dependencia de una única base criptográfica. Una debilidad descubierta en una familia no socavaría automáticamente a la otra, mientras que la implementación mediante contratos inteligentes da a los desarrolladores de bóvedas flexibilidad para reemplazar el esquema más adelante si es necesario. El principio de implementar más de una familia criptográfica no relacionada es la misma lógica de diversificación que motivó a NIST a estandarizar tanto firmas basadas en retículos como basadas en hashes en lugar de depender de un único enfoque.
La contrapartida es el tamaño de la firma. Una firma ML-DSA-65 tiene 3,309 bytes, en comparación con los 64 bytes de una firma típica Ed25519. Su clave pública tiene 1,952 bytes. La configuración SLH-DSA-SHA2-128s seleccionada produce una firma de 7,856 bytes, considerablemente más pequeña que las cifras de 16–30 KB a veces asociadas con SLH-DSA. Esas cifras más grandes se aplican a conjuntos de parámetros SLH-DSA más fuertes, no a la configuración 128s seleccionada por Sui.
Firmas más grandes significan transacciones más grandes y más datos moviéndose a través de la red. Sui afirma que el rendimiento de verificación de ML-DSA está suficientemente cerca de Ed25519 como para que el costo por firma en la red no necesite aumentar, aunque el tamaño de la transacción sí aumenta. Se están llevando a cabo optimizaciones adicionales.
Los Usuarios No Necesitan Migrar Hoy
Se prevé que las bóvedas resistentes a la computación cuántica lleguen a Mainnet antes de finales de 2026. Se espera que las cuentas nativas de ML-DSA-65 estén disponibles en Testnet para fin de año, seguidas por la autenticación nativa de cuentas en Mainnet en el primer trimestre de 2027. Se planea incluir soporte para monederos, SDK y línea de comandos junto con el lanzamiento. La mayoría de las principales blockchains de Capa 1 han discutido la migración post-cuántica en términos generales, pero pocas han publicado cronogramas concretos con algoritmos específicos estandarizados por NIST y mecanismos on-chain, lo que sitúa a Sui entre las primeras redes en comprometerse con una hoja de ruta detallada.
Las auditorías independientes y los comentarios de Testnet continúan en curso, por lo que estos cronogramas podrían cambiar antes de que las funciones lleguen a producción.
Las cuentas existentes no necesitan tomar ninguna medida en este momento. Los nuevos métodos de autenticación serán aditivos y opcionales en lugar de una migración forzada en toda la red.
El diseño de la migración también establece una señal de alerta sencilla para posibles estafas. La ruta de migración descrita por Sui no requiere que los titulares envíen sus activos a una dirección de monedero recién proporcionada. Cualquier mensaje no solicitado que afirme que los fondos deben transferirse urgentemente a otra parte para volverse "resistente a la computación cuántica" sería inconsistente con el mecanismo descrito por Sui.
Ninguna computadora cuántica de conocimiento público puede actualmente romper las firmas que protegen las cuentas de Sui. La pregunta relevante es si la red puede migrar su criptografía antes de que esa capacidad se vuelva práctica. El enfoque de Sui consiste en hacer que la clave sea reemplazable sin que la cuenta sea desechable.
Metodología: Este artículo hace referencia al anuncio del 6 de agosto de la Sui Foundation, la documentación oficial de Sui Address Alias, y las especificaciones NIST FIPS 204 y FIPS 205. Los tamaños de firma y las categorías de seguridad fueron verificados contra los estándares pertinentes de NIST. Las funciones ya admitidas a través de Address Aliases se distinguen de la funcionalidad post-cuántica que permanece en la hoja de ruta de desarrollo de Sui.
Aviso legal: Este artículo se proporciona únicamente con fines informativos y educativos y no constituye asesoramiento financiero, de inversión o de seguridad. Las funciones post-cuánticas de Sui continúan en desarrollo, revisión independiente y pruebas, y los detalles de implementación o los cronogramas pueden cambiar antes del lanzamiento en Mainnet.