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: seguirían pudiendo ejecutar pagos mediante un permiso separado, pero no tendrían autoridad suficiente para sustituir las claves desactivadas. El riesgo depende de cómo se configuren los pesos y umbrales de firma de cada cuenta.
Desactivar una firma no rebaja automáticamente el umbral
La propuesta, identificada como TIP-899 y todavía marcada como borrador a 12 de septiembre de 2026, contempla que la gobernanza de TRON pueda activar o desactivar por separado dos esquemas de firma resistentes a la computación cuántica: FN-DSA-512, basado en Falcon, y ML-DSA.
Ambas implementaciones fueron incluidas en la versión del 30 de junio de la red de pruebas Nile. Sin embargo, cada una necesita una aprobación específica de la gobernanza antes de que sus firmas sean aceptadas por la red. Una consulta realizada el 12 de septiembre mostró activado el ajuste getAllowFnDsa512, con un valor de 1. El parámetro de ML-DSA aparecía sin valor que confirmara su activación. En la red principal no figuraba ninguno de los dos ajustes, por lo que esas comprobaciones no demuestran que las funciones estén activas allí.
Los interruptores de activación forman parte del sistema de propuestas en cadena que administran los 27 Super Representantes elegidos de TRON. Los códigos utilizados actualmente son 1000 y 1001, frente a los valores 99 y 100 que aparecían en discusiones anteriores. Según explicaron los desarrolladores, la numeración se modificó para evitar conflictos con futuros ajustes de la red principal.
La cuestión central está en el verificador de transacciones. Si una firma procede de un esquema que ha sido desactivado, la transacción es rechazada. Por tanto, no bastaría con conservar una clave válida de otro sistema: la operación tendría que excluir la firma del esquema deshabilitado y, además, reunir el peso suficiente con las claves restantes.
La diferencia entre pagar y cambiar las claves
TRON asigna un peso a cada clave y establece un umbral para cada permiso. La autoridad del propietario puede cambiar los permisos de la cuenta, mientras que un permiso activo solo permite las operaciones que se le hayan asignado, como transferencias.
Esto abre la puerta a configuraciones en las que una cuenta pueda seguir moviendo fondos, pero no reparar sus propias claves. Por ejemplo, una autoridad de propietario formada únicamente por una clave Falcon con peso 1 y umbral 1 dejaría de poder autorizar operaciones cuando Falcon fuese desactivado. Un permiso activo independiente podría seguir permitiendo pagos, pero no tendría capacidad para modificar la autoridad del propietario.
La presencia de una clave ECDSA tampoco garantiza por sí sola la recuperación. Si la cuenta asignase un peso 1 a ECDSA y otro peso 1 a Falcon, con un umbral de 2, ambas firmas serían necesarias. Al desactivarse Falcon, la clave ECDSA restante no alcanzaría el umbral.
Una configuración con Falcon y ML-DSA puede ofrecer una vía alternativa, pero solo si la clave superviviente puede alcanzar por sí sola el umbral del propietario. Con un peso 1 para cada clave y un umbral de 1, cualquiera de las dos podría autorizar cambios. Con un umbral de 2, la pérdida de una de ellas bloquearía esa autoridad.
Una propuesta aún pendiente de auditorías y pruebas
El diseño también advierte de que añadir una clave resistente a la computación cuántica no ofrece esa protección si un conjunto de claves ECDSA puede seguir alcanzando el umbral. Por eso, la revisión no debe limitarse a la clave utilizada para pagos: hay que analizar la autoridad del propietario y todas las rutas activas capaces de mover los activos protegidos.
ML-DSA cuenta con el estándar FIPS 204, finalizado por el Instituto Nacional de Estándares y Tecnología de Estados Unidos el 13 de agosto de 2024. La estandarización de Falcon, en cambio, continúa en curso. TIP-899 plantea ML-DSA como alternativa, pero eso no constituye por sí mismo un mecanismo automático de recuperación.
Antes de una eventual activación en la red principal, el borrador reclama auditorías criptográficas y de implementación, publicación de sus resultados y cobertura mediante programas de recompensas por fallos. También quedan trabajos en carteras, almacenes de claves, kits de desarrollo y dispositivos físicos. La documentación revisada no incluye un informe independiente de auditoría completado.
Justin Sun afirmó el 8 de agosto de 2026 que quería convertir a TRON en la primera red de cadenas de bloques resistente a la computación cuántica y citó las pruebas en Nile. La propuesta todavía necesita demostrar algo más que la generación y validación de nuevas firmas: que, cuando un esquema deje de estar disponible, las cuentas conserven una ruta autorizada tanto para pagar como para sustituir sus claves.
