El diseño preliminar de firmas resistentes a la computación cuántica de TRON podría dejar a algunas cuentas en una situación paradójica: capaces de realizar pagos, pero sin autoridad suficiente para sustituir las claves afectadas. El problema dependería de cómo se configuren los permisos y los umbrales de firma antes de que la red desactive uno de los esquemas criptográficos.
Una cuenta puede seguir pagando y perder la capacidad de recuperarse
La propuesta TIP-899 permite que la gobernanza de TRON active o desactive por separado los esquemas de firma previstos. En la práctica, una firma procedente de un sistema deshabilitado provoca el rechazo de la transacción. Para utilizar una vía alternativa, la operación tendría que emplear únicamente firmas aceptadas y alcanzar el umbral de autoridad configurado en la cuenta.
Ese mecanismo puede afectar de forma distinta a los pagos y a la gestión de claves. TRON separa el permiso de propietario, que puede modificar los permisos de la cuenta, de los permisos activos, limitados a las operaciones que se les hayan asignado, como las transferencias. Una clave autorizada para enviar fondos no tiene por qué poder reemplazar las claves del propietario.
Por ejemplo, una cuenta cuyo permiso de propietario dependa únicamente de una clave Falcon podría quedarse sin capacidad para autorizar transferencias o actualizar permisos si Falcon fuese desactivado. Sin embargo, un permiso activo independiente podría seguir permitiendo determinados pagos. En ese caso, la cuenta no estaría completamente inoperativa, pero tampoco dispondría de una vía para reparar su configuración de claves.
La combinación con una clave del sistema ECDSA existente tampoco garantiza siempre la recuperación. Si ambas claves tienen un peso de uno y el umbral es dos, las dos firmas son necesarias. Al deshabilitar Falcon, la clave ECDSA restante ya no alcanzaría el umbral.
La alternativa ML-DSA requiere una configuración previa
TIP-899 contempla una segunda opción resistente a la computación cuántica: ML-DSA. Una cuenta podría conservar una ruta de recuperación si sus claves ML-DSA, por sí solas, alcanzan el umbral del permiso de propietario y el esquema continúa habilitado. En cambio, si el umbral exige simultáneamente una clave Falcon y otra ML-DSA, la desactivación de cualquiera de las dos impediría cumplirlo.
La propuesta de “una u otra” protege frente a la indisponibilidad de uno de los sistemas, pero no frente a una clave comprometida mientras el esquema correspondiente siga aceptándose. Son problemas diferentes: uno afecta a la continuidad operativa tras la desactivación y el otro a la seguridad frente a una firma maliciosa válida.
La documentación también advierte de que mantener una ruta basada únicamente en ECDSA puede anular el objetivo de protección cuántica. Por eso, la evaluación no debe limitarse a la clave usada para los pagos habituales. También hay que revisar el permiso de propietario y cualquier permiso activo capaz de mover los activos protegidos.
El despliegue sigue en fase de propuesta y pruebas
El 8 de agosto de 2026, Justin Sun afirmó que su objetivo era convertir TRON en la primera red blockchain resistente a la computación cuántica y mencionó las pruebas en la red de pruebas Nile. A 12 de septiembre, TIP-899 continuaba clasificada como borrador.
La actualización de software de Nile del 30 de junio incorporó implementaciones basadas en Falcon, denominada FN-DSA-512, y ML-DSA-44. Cada una necesita su propia aprobación de gobernanza antes de que la red acepte sus firmas. Una consulta realizada el 12 de septiembre mostró activado el parámetro getAllowFnDsa512, con valor 1. El parámetro de ML-DSA aparecía sin valor y la respuesta de la red principal no incluía ninguno de los dos. Los desarrolladores habían señalado el 15 de julio que el calendario para la red principal aún no estaba decidido.
Los interruptores propuestos se someterían a los 27 Super Representatives elegidos de TRON mediante propuestas en cadena. Sus identificadores también cambiaron: TIP-899 y la implementación de Nile utilizan los códigos 1000 y 1001, frente a los códigos 99 y 100 presentes en debates anteriores. Esos números solo identifican los parámetros; la activación requiere una decisión de gobernanza independiente.
Antes de una eventual activación en la red principal, la propuesta reclama auditorías criptográficas y de implementación, publicación del material revisado y cobertura mediante programas de recompensas por errores. También quedan pendientes adaptaciones para carteras, almacenes de claves, kits de desarrollo y dispositivos físicos. Las pruebas en Nile y las herramientas de generación de claves no demuestran por sí solas que las carteras o custodios puedan ejecutar todas las operaciones de migración y recuperación.
La prueba decisiva consistiría en desactivar un esquema, realizar una operación con las firmas supervivientes y comprobar tanto qué pagos siguen autorizados como si el propietario puede sustituir las claves afectadas. Sin una configuración que preserve ambas capacidades, pagar no equivaldría necesariamente a poder recuperar la cuenta.
