$NEAR admite firmas de cuentas resistentes a la computación cuántica, pero eso no significa que toda la cadena ya haya completado la migración poscuántica. Vale la pena analizar el tema que ocupa actualmente el sexto puesto en la plaza, pero los hitos técnicos a los que se refiere corresponden a julio y septiembre; no se deben presentar como una función nueva que acaba de lanzarse hoy.
La primera capa es cómo una cuenta autoriza transacciones. nearcore 2.13.0 se publicó el 9 de julio e indicó que ML-DSA-65 se incorpora como tercer tipo de firma de transacciones y de clave de acceso, junto a los dos tipos existentes. Este cambio ofrece a las cuentas una nueva opción de verificación de firmas, pero no cambia automáticamente las claves de todas las cuentas existentes ni permite afirmar que todas las cuentas ya hayan adoptado el nuevo algoritmo.
La segunda capa es si un contrato puede verificar un mensaje. La versión candidata para testnet 2.14.0-rc.1, del 16 de septiembre, añadió la interfaz ml_dsa_verify para que los contratos verifiquen mensajes. Esta es una vía distinta de la autorización nativa de transacciones de las cuentas: que un contrato pueda comprobar una firma no demuestra directamente que todas las operaciones que controla, los activos externos o los mensajes entre cadenas hayan completado la migración de seguridad. Tampoco se debe presentar una versión candidata de prueba como si ya se hubiera desplegado en la red principal.
La tercera capa es el alcance de la migración de todo el sistema. La firma de cuentas es solo una parte: qué versión del protocolo adoptan los nodos, cómo se actualizan las claves existentes y cómo se gestionan las demás dependencias requieren pruebas específicas. No se puede deducir que todas las capas del sistema cuentan con las mismas garantías porque un módulo haya adoptado un algoritmo nuevo.
También hay que distinguir las fechas. El registro de desarrollo del 2 de julio muestra una demostración de añadir una clave y transferir fondos en un entorno de pruebas; el 9 de julio se publicó una versión destinada a la red principal; y esa versión también indicaba un plan para iniciar una votación sobre el protocolo el 20 de julio. Una demostración exitosa, una versión publicada, un plan de votación y la activación efectiva en la red no representan el mismo estado de finalización. En esta revisión no se ha verificado el resultado de la actualización de toda la red, así que no se toma la fecha prevista como confirmación del despliegue.
Para los usuarios comunes, las preguntas más concretas son: si su cuenta tiene realmente configurada una clave de acceso de este tipo, si la billetera que utilizan puede generarla, guardarla y firmar correctamente con ella, y si la aplicación admite el proceso correspondiente. Ver solo un titular no permite saber si la cuenta que uno tiene ya está protegida por el nuevo esquema de firmas. Tras añadir una clave nueva, también conviene comprobar cómo se gestionan los permisos de las claves antiguas según la configuración real de la cuenta.
Para los desarrolladores, hay que distinguir entre las transacciones nativas de las cuentas y la verificación de mensajes por parte de los contratos. La primera determina quién puede autorizar operaciones de la cuenta; la segunda, cómo un programa determina si un mensaje es válido. Que la verificación de una firma sea exitosa no significa que el contenido del mensaje, el alcance de los permisos o la lógica de negocio sean correctos por naturaleza. Los límites de seguridad deben definirse en el proceso de autorización real.
Me interesan más los próximos puntos que puedan verificarse: los registros de las versiones oficiales y de la activación del protocolo, la compatibilidad de las billeteras y las instrucciones claras para la migración. Lo que puede confirmarse ahora es que NEAR está impulsando distintas capacidades en las capas de firma de cuentas y verificación de firmas de contratos; lo que no puede confirmarse es que todas las cuentas antiguas, aplicaciones y dependencias externas hayan completado la migración a la vez. Esta es una observación sobre el alcance técnico, no una predicción de la dirección del precio basada en el nombre de un algoritmo.
La primera capa es cómo una cuenta autoriza transacciones. nearcore 2.13.0 se publicó el 9 de julio e indicó que ML-DSA-65 se incorpora como tercer tipo de firma de transacciones y de clave de acceso, junto a los dos tipos existentes. Este cambio ofrece a las cuentas una nueva opción de verificación de firmas, pero no cambia automáticamente las claves de todas las cuentas existentes ni permite afirmar que todas las cuentas ya hayan adoptado el nuevo algoritmo.
La segunda capa es si un contrato puede verificar un mensaje. La versión candidata para testnet 2.14.0-rc.1, del 16 de septiembre, añadió la interfaz ml_dsa_verify para que los contratos verifiquen mensajes. Esta es una vía distinta de la autorización nativa de transacciones de las cuentas: que un contrato pueda comprobar una firma no demuestra directamente que todas las operaciones que controla, los activos externos o los mensajes entre cadenas hayan completado la migración de seguridad. Tampoco se debe presentar una versión candidata de prueba como si ya se hubiera desplegado en la red principal.
La tercera capa es el alcance de la migración de todo el sistema. La firma de cuentas es solo una parte: qué versión del protocolo adoptan los nodos, cómo se actualizan las claves existentes y cómo se gestionan las demás dependencias requieren pruebas específicas. No se puede deducir que todas las capas del sistema cuentan con las mismas garantías porque un módulo haya adoptado un algoritmo nuevo.
También hay que distinguir las fechas. El registro de desarrollo del 2 de julio muestra una demostración de añadir una clave y transferir fondos en un entorno de pruebas; el 9 de julio se publicó una versión destinada a la red principal; y esa versión también indicaba un plan para iniciar una votación sobre el protocolo el 20 de julio. Una demostración exitosa, una versión publicada, un plan de votación y la activación efectiva en la red no representan el mismo estado de finalización. En esta revisión no se ha verificado el resultado de la actualización de toda la red, así que no se toma la fecha prevista como confirmación del despliegue.
Para los usuarios comunes, las preguntas más concretas son: si su cuenta tiene realmente configurada una clave de acceso de este tipo, si la billetera que utilizan puede generarla, guardarla y firmar correctamente con ella, y si la aplicación admite el proceso correspondiente. Ver solo un titular no permite saber si la cuenta que uno tiene ya está protegida por el nuevo esquema de firmas. Tras añadir una clave nueva, también conviene comprobar cómo se gestionan los permisos de las claves antiguas según la configuración real de la cuenta.
Para los desarrolladores, hay que distinguir entre las transacciones nativas de las cuentas y la verificación de mensajes por parte de los contratos. La primera determina quién puede autorizar operaciones de la cuenta; la segunda, cómo un programa determina si un mensaje es válido. Que la verificación de una firma sea exitosa no significa que el contenido del mensaje, el alcance de los permisos o la lógica de negocio sean correctos por naturaleza. Los límites de seguridad deben definirse en el proceso de autorización real.
Me interesan más los próximos puntos que puedan verificarse: los registros de las versiones oficiales y de la activación del protocolo, la compatibilidad de las billeteras y las instrucciones claras para la migración. Lo que puede confirmarse ahora es que NEAR está impulsando distintas capacidades en las capas de firma de cuentas y verificación de firmas de contratos; lo que no puede confirmarse es que todas las cuentas antiguas, aplicaciones y dependencias externas hayan completado la migración a la vez. Esta es una observación sobre el alcance técnico, no una predicción de la dirección del precio basada en el nombre de un algoritmo.