El diseño que TRON estudia para adaptar sus cuentas a la computación cuántica podría dejar a algunos usuarios en una situación paradójica: mantener la capacidad de realizar pagos, pero perder la autoridad necesaria para sustituir las claves de la cartera si la red desactiva el sistema de firma del que dependen.
El problema aparece en TIP-899, una propuesta que continúa marcada como borrador a 12 de septiembre de 2026. El documento contempla incorporar dos esquemas de firma resistentes a la computación cuántica, Falcon basado en FN-DSA-512 y ML-DSA-44, que se activarían por separado mediante decisiones de gobernanza.
Una clave para pagar no siempre sirve para recuperar la cuenta
TRON asigna pesos a las claves y establece umbrales para cada tipo de permiso. Una operación solo es válida cuando las firmas autorizadas alcanzan ese umbral. La configuración de propietario —owner— tiene un papel central: puede aprobar contratos y modificar los permisos de la cuenta. Las autorizaciones activas, en cambio, se limitan a las operaciones que se les hayan asignado, como transferencias.
Por eso, una clave que todavía permita enviar fondos no tiene necesariamente capacidad para cambiar las claves de la cuenta. La modificación de permisos debe aprobarse con la autorización de propietario existente.
La propuesta añade además un matiz relevante al verificador de transacciones: si una operación contiene una firma procedente de un esquema que ha sido desactivado, la transacción es rechazada. Para utilizar las firmas supervivientes, no bastaría con que estas tengan peso suficiente; la transacción tendría que omitir también la firma del sistema deshabilitado.
En un caso hipotético, una autorización de propietario formada únicamente por una clave Falcon con peso 1 y umbral 1 dejaría de poder aprobar operaciones cuando Falcon fuese desactivado. Una autorización activa configurada por separado podría seguir permitiendo pagos, pero no reparar la autorización de propietario.
La combinación de claves tampoco garantiza por sí sola la recuperación. Si una cuenta tiene una clave ECDSA con peso 1 y otra Falcon con peso 1, pero exige un umbral de 2, la desactivación de Falcon impediría alcanzar el umbral con la clave restante. El mismo problema se produciría con dos claves cuántico-resistentes si ambas fueran obligatorias para firmar.
La gobernanza podrá activar o retirar cada esquema
TIP-899 propone interruptores independientes para habilitar o deshabilitar cada algoritmo. TRON cuenta con 27 Super Representatives elegidos, que toman decisiones mediante propuestas en cadena. La propuesta utiliza los códigos 1000 y 1001 para estos ajustes, en lugar de los identificadores 99 y 100 que aparecían en conversaciones anteriores. Según la explicación de los desarrolladores del 1 de julio, el cambio busca evitar conflictos con futuras numeraciones de la red principal.
La red de pruebas Nile ya incorporó implementaciones de FN-DSA-512 y ML-DSA-44 en su actualización del 30 de junio. Una consulta realizada el 12 de septiembre devolvió un valor de 1 para el parámetro getAllowFnDsa512. El ajuste de ML-DSA aparecía sin valor, por lo que no ofrecía una confirmación positiva de activación. La respuesta de la red principal no incluía ninguno de los dos parámetros.
Estos datos no demuestran que los esquemas estén activos en la red principal. En una llamada del 15 de julio, los desarrolladores señalaron que el calendario para esa activación todavía no estaba decidido. Justin Sun había afirmado el 8 de agosto que su objetivo era convertir a TRON en la primera red blockchain resistente a la computación cuántica y había mencionado las pruebas en Nile.
La migración aún requiere auditorías y adaptación de las carteras
La propuesta contempla una posible vía de recuperación mediante un segundo esquema resistente a la computación cuántica. Sin embargo, las claves supervivientes tendrían que alcanzar por sí mismas el umbral de propietario ya configurado. Si ambas claves fueran necesarias de forma simultánea, la cuenta seguiría dependiendo de que los dos sistemas permanecieran disponibles.
El diseño también advierte de que mantener una ruta ECDSA capaz de alcanzar el umbral no ofrece protección cuántica plena. La evaluación debe incluir tanto la autorización de propietario como todas las autorizaciones activas que puedan mover los activos protegidos.
NIST finalizó el estándar FIPS 204 para ML-DSA el 13 de agosto de 2024, mientras que la estandarización de Falcon continúa en proceso. TIP-899 plantea auditorías criptográficas y de implementación, publicación de sus resultados y un programa de recompensas por errores antes de una eventual activación en la red principal. El material revisado no incluye todavía un informe independiente de auditoría terminado.
También quedan pendientes los cambios en derivación de claves, almacenes de claves, herramientas de desarrollo y dispositivos físicos. Que Nile disponga de implementaciones y herramientas de generación no significa que las carteras de usuarios o custodios puedan ejecutar ya todas las operaciones de migración y recuperación. Para validar el diseño será necesario comprobar en la red de pruebas qué pagos siguen autorizados tras desactivar un esquema y si el propietario conserva la capacidad de reemplazar las claves afectadas.
