El plan cuántico de TRON podría dejar algunas billeteras capaces de pagar pero incapaces de reemplazar sus claves

El diseño de firma cuántica en borrador de TRON podría dejar algunas cuentas migradas incapaces de reemplazar sus claves después de que la gobernanza de la red desactive el esquema de firma del que dependen. Algunas de esas cuentas aún podrían realizar pagos a través de un permiso separado.

El diseño incluye una posible ruta de recuperación a través de un segundo esquema de firma resistente a cuánticos. Para usarlo, los titulares necesitarían las claves sobrevivientes para cumplir con el umbral de propietario existente de la cuenta, el nivel de autoridad requerido para cambiar permisos. Una clave de respaldo autorizada solo para pagos dejaría ese poder de reparación fuera de alcance.

Esa es la pregunta práctica detrás del impulso cuántico de Justin Sun. El 8 de agosto de 2026, @justinsuntron dijo que su objetivo era que TRON se convirtiera en la primera red blockchain resistente a cuánticos y se refirió a las pruebas en la red de prueba Nile. Esa declaración de ambición proporciona el telón de fondo a un diseño de migración cuyos interruptores de gobernanza pueden retirar posteriormente la aprobación para un esquema de firma.

A partir del 12 de septiembre, el TIP-899 sigue etiquetado como Borrador. La versión de software de Nile del 30 de junio incluyó implementaciones de FN-DSA-512 basado en Falcon y ML-DSA-44, cada una sujeta a su propia configuración de activación. Cada implementación aún necesita su propia aprobación de gobernanza antes de que la red acepte sus firmas.

Una verificación del 12 de septiembre del punto final de parámetros de Nile devolvió getAllowFnDsa512 con un valor de 1. La configuración de ML-DSA apareció sin un valor, proporcionando ninguna lectura de activación afirmativa. La respuesta de la red principal no contenía ninguna configuración. Los desarrolladores habían dicho en su llamada del 15 de julio que el tiempo de la red principal no estaba decidido; las verificaciones actuales no establecen la activación de la red principal.

Un interruptor de red cumple con un umbral de cuenta

El TIP-899 permite a la gobernanza habilitar o deshabilitar cada esquema propuesto por separado. Los 27 Super Representantes electos de TRON gobiernan a través de propuestas en la cadena. Los interruptores propuestos pertenecen a ese proceso.

Las configuraciones de activación también han sido renumeradas. El TIP-899 y la implementación de Nile utilizan los códigos 1000 y 1001, mientras que la discusión de migración anterior aún contiene 99 y 100. La llamada de desarrolladores del 1 de julio explica que se eligieron los números más grandes para evitar conflictos con la numeración futura de la red principal. Esos números identifican las configuraciones propuestas; la activación requiere una decisión de gobernanza separada.

A nivel de cuenta, la pregunta es qué firmas siguen siendo aceptables. TRON asigna pesos a las claves y requiere que los firmantes válidos de un permiso seleccionado cumplan o superen su umbral. El camino de firma cuántica propuesto utiliza ese mismo cálculo de permiso.

Hay un detalle importante en el verificador de transacciones de referencia: una firma de un esquema deshabilitado desencadena el rechazo. Por lo tanto, una transacción de respaldo funcional debe usar firmas aceptadas y omitir la firma del esquema deshabilitado, incluso si las claves restantes tienen suficiente peso.

Desactivar un esquema puede, por lo tanto, eliminar una ruta de firma sin cambiar el umbral configurado de la cuenta. Nada en ese interruptor otorga automáticamente a otra clave la autoridad que falta.

La documentación de permisos de TRON separa la autoridad del propietario de los permisos activos. El permiso del propietario puede autorizar cualquier tipo de contrato y cambiar los permisos de la cuenta. Un permiso activo está limitado a las operaciones asignadas a él, como transferencias.

Una actualización de permisos debe ser firmada bajo el permiso de propietario existente. Eso hace que la configuración del propietario sea central para la recuperación: una clave capaz de enviar un pago no necesariamente tiene el poder de reemplazar las claves de la cuenta.

Considere un permiso de propietario que contenga solo una clave Falcon con peso 1 y umbral 1. Mientras Falcon esté deshabilitado, ese permiso de propietario no puede autorizar una transferencia o una actualización de permisos. Un permiso activo configurado por separado aún podría permitir transacciones, por lo que esto no hace necesariamente que toda la cuenta no pueda gastar.

Mantener una clave para el método de firma ECDSA existente de TRON junto con Falcon no siempre restaura el acceso. Con un peso ECDSA de 1, un peso Falcon de 1 y un umbral de 2, se requieren ambas firmas. Después de que Falcon esté deshabilitado, el peso ECDSA restante no puede cumplir con el umbral.

Los siguientes ejemplos aplican las reglas propuestas a configuraciones hipotéticas. Muestran deducciones de las reglas documentadas de permisos y verificación; no hay un bloqueo observado o una prueba de reversión ejecutada que respalde estos ejemplos. Suponga que Falcon ha sido deshabilitado, que cualquier clave ML-DSA fue configurada de antemano, que ML-DSA sigue habilitado y seguro, y que el titular aún puede usar esas claves.

Estos resultados conciernen a la autoridad de firma; se aplican otros requisitos de transacción. La distinción también funciona en la otra dirección. Un permiso de propietario ML-DSA sobreviviente podría autorizar transacciones directamente y reemplazar un permiso activo Falcon deshabilitado.

Una segunda clave cuántica ayuda solo si puede actuar

El ejemplo de propietario de dos esquemas preserva una ruta resistente a cuánticos para la reparación de permisos si alguna de las claves puede cumplir independientemente con el umbral del propietario. Requerir ambas claves crea una dependencia de que ambos esquemas permanezcan disponibles. El umbral determina cuáles de esas propiedades tiene una cuenta.

Tampoco una ruta de recuperación clásica preserva el mismo objetivo de seguridad. La propuesta de migración dice explícitamente que agregar una clave resistente a cuánticos no proporciona protección cuántica si un conjunto de firma solo ECDSA aún puede cumplir con el umbral. Una ruta de propietario solo ECDSA también puede reemplazar un permiso activo protegido cuánticamente.

La configuración relevante es, por lo tanto, más amplia que la clave utilizada para pagos rutinarios. La autoridad del propietario y cada ruta activa capaz de mover los activos protegidos deben considerarse juntas.

Una configuración de cualquiera de los esquemas también tiene un límite: preserva una alternativa después de que un esquema esté deshabilitado, pero no protege contra un esquema comprometido mientras ese esquema permanezca habilitado y autorizado de forma independiente. La disponibilidad después de la desactivación y la resistencia a una clave comprometida aún aceptada son propiedades separadas.

El estado de los estándares de ML-DSA ayuda a explicar su lugar en el diseño. NIST finalizó FIPS 204, que especifica ML-DSA, el 13 de agosto de 2024. NIST aún describe la estandarización de Falcon como en curso. TIP-899 presenta ML-DSA como una alternativa implementada a la estandarización de Falcon y al riesgo de auditoría. Esto proporciona un algoritmo alternativo, en lugar de un permiso de recuperación automática.

El trabajo restante va más allá de agregar un botón de firma. TIP-899 exige auditorías criptográficas externas e implementación, material de auditoría pública y cobertura de recompensas por errores antes de la activación de la mainnet. Los materiales de propuesta revisados no proporcionan un informe de auditoría independiente completo.

La propuesta y la discusión de desarrolladores del 15 de julio también identifican el trabajo de derivación de billeteras, keystore, SDK y adaptación de billeteras de hardware. La implementación de testnet y las herramientas de generación de claves no establecen que las billeteras de los consumidores o los custodios puedan ya realizar cada operación de migración y recuperación.

Una demostración útil de testnet seguiría los permisos a través de la falla: deshabilitar el esquema, construir una transacción utilizando solo firmas sobrevivientes, mostrar qué transferencias siguen autorizadas y mostrar si el propietario existente puede reemplazar las claves afectadas. El resultado necesitaría coincidir con la configuración que los usuarios realmente poseen.

Si ambos esquemas cuánticos propuestos fueran deshabilitados y ningún conjunto de firmas válidas pudiera cumplir con el propietario o el umbral activo relevante, las reglas descritas no proporcionarían un camino ordinario inmediato para gastar o rotar claves. Eso no establece una pérdida permanente. La reactivación de la gobernanza o un cambio de protocolo posterior serían una ruta de recuperación diferente; el canal de emergencia más rápido y las ideas de recuperación de conocimiento cero permanecen fuera del alcance actual de esta propuesta.

Para billeteras y custodios, la continuidad de pagos por sí sola dejaría sin respuesta la pregunta central de recuperación. Una configuración de migración necesita un camino autorizado por el propietario sobreviviente para reemplazar claves, así como una forma de mover fondos, con ambos caminos preservando su objetivo de resistencia cuántica.

Este contenido se ofrece únicamente con fines informativos generales y no constituye un asesoramiento financiero, de inversión, legal ni fiscal. Cualquier evento, recompensa, promoción en línea o información relacionada que se mencione en el presente documento no debe considerarse como una recomendación, solicitud o invitación a comprar, vender, operar o de negociar de otra manera con cualquier criptoactivo. Los criptoactivos son sumamente volátiles y pueden provocar pérdidas. La disponibilidad de los servicios, productos y eventos relacionados de WEEX puede variar según la región. Tienes la responsabilidad de asegurarte de que tu participación esté de acuerdo con las leyes y regulaciones locales vigentes.