El tema de la resistencia cuántica de $ZEC tiene un límite que conviene aclarar desde el principio: el equipo de desarrollo fijó como objetivo ofrecer compatibilidad con firmas en enero, pero todavía no se puede afirmar que Zcash en su conjunto haya completado una actualización resistente a la computación cuántica. Me interesa más la distancia entre la propuesta técnica y su implementación en la red, y si la experiencia de uso de las billeteras podrá avanzar al mismo ritmo.
El artículo publicado el 9 de octubre sobre el proyecto Zakura dio pie a este debate. Su autor, Roman Akhtariev, afirma explícitamente que el equipo planea incorporar en enero a Zcash códigos de operación para firmas poscuánticas. Estos códigos son instrucciones que la red utiliza para comprobar la autorización de los pagos; el artículo analiza un esquema de firma basado en hashes que ofrece una vía alternativa de autorización a las claves actuales de curva elíptica. El artículo no indica una altura de activación de la red principal que ya haya entrado en vigor. Por lo tanto, enero es, ante todo, un objetivo del equipo, no una fecha de finalización confirmada.
El valor de esta iniciativa es que convierte un debate general sobre los riesgos en preparativos de ingeniería que se pueden verificar. Más adelante se podrá comprobar si la implementación se incluye en una versión oficial, si se completan las revisiones y si quedan claras las reglas de adopción de la red y la compatibilidad de las billeteras. Una fecha objetivo puede ayudar a organizar el trabajo, pero por sí sola no demuestra que el despliegue se haya completado, y mucho menos explica causalmente el precio de ZEC. La preparación en materia de seguridad y las expectativas del mercado requieren pruebas independientes.
El artículo se centra en las direcciones transparentes. Las direcciones transparentes estándar revelan primero el hash de la clave pública y solo hacen pública la clave correspondiente cuando se realiza un gasto; rotar las direcciones puede reducir la reutilización que se produce cuando una misma clave pública queda expuesta de forma continuada. La incorporación de compatibilidad con firmas se centra en la capa de autorización de pagos. De ello no se puede deducir que el cifrado, las pruebas y la privacidad histórica de todas las transacciones blindadas reciban al mismo tiempo la misma protección. Cada componente utiliza mecanismos distintos, por lo que hay que verificar por separado el alcance de la actualización.
Tampoco interpreto «recuperable» directamente como «totalmente resistente a la computación cuántica». La documentación oficial de Ironwood de Zcash explica por separado los billetes recuperables ante ataques cuánticos y el nuevo conjunto de fondos, que aún reutiliza algunas estructuras del protocolo Orchard. Esto nos recuerda que la capacidad de recuperación, la seguridad de las firmas y la protección de la privacidad resuelven problemas distintos. Que algo incluya la palabra «cuántico» en su nombre no sustituye una explicación concreta de las amenazas y del alcance de la protección.
Hay otra etapa de uso que es fácil pasar por alto: aunque una billetera genere varias direcciones nuevas, las consultas ordinarias de saldo pueden permitir que el servidor las vincule entre sí. PIR, descrito en el artículo original de Zakura, es un mecanismo concreto para ocultar las consultas al consultar el historial y los saldos. Las transacciones transparentes siguen siendo públicas en la cadena. Proteger la información de las consultas y ocultar las propias transacciones son cosas distintas; no se debe promocionar esta herramienta como si los pagos en la cadena ya fueran transacciones blindadas.
El artículo señala que el ajuste «Private queries» de Vizor permite probar una implementación experimental. Esto corresponde al estado experimental divulgado por el equipo, y no significa que todas las billeteras ya lo admitan de forma predeterminada ni que hayamos verificado su funcionamiento de manera independiente. La fluidez del proceso de uso y la fiabilidad de la recuperación todavía deberán aclararse con versiones posteriores y los resultados de las revisiones.
El nuevo aspecto que merece atención en esta ocasión es el plan de firmas y su relación con la rotación de direcciones y las consultas privadas; no he retomado el tema anterior de los riesgos para las claves BTC cambiando simplemente de token. Mi conclusión es que vale la pena seguir de cerca los objetivos de ingeniería claramente definidos, pero para saber si realmente cambia el límite de seguridad habrá que observar las reglas oficiales y su adopción efectiva. A continuación, conviene prestar atención a tres aspectos: la implementación de las firmas, las condiciones de activación de la red principal y la integración en las billeteras. Cualquier retraso o cambio de alcance exigirá revisar nuestras conclusiones; no se puede usar el compromiso de un mes para afirmar que toda la red ya es segura.
El artículo publicado el 9 de octubre sobre el proyecto Zakura dio pie a este debate. Su autor, Roman Akhtariev, afirma explícitamente que el equipo planea incorporar en enero a Zcash códigos de operación para firmas poscuánticas. Estos códigos son instrucciones que la red utiliza para comprobar la autorización de los pagos; el artículo analiza un esquema de firma basado en hashes que ofrece una vía alternativa de autorización a las claves actuales de curva elíptica. El artículo no indica una altura de activación de la red principal que ya haya entrado en vigor. Por lo tanto, enero es, ante todo, un objetivo del equipo, no una fecha de finalización confirmada.
El valor de esta iniciativa es que convierte un debate general sobre los riesgos en preparativos de ingeniería que se pueden verificar. Más adelante se podrá comprobar si la implementación se incluye en una versión oficial, si se completan las revisiones y si quedan claras las reglas de adopción de la red y la compatibilidad de las billeteras. Una fecha objetivo puede ayudar a organizar el trabajo, pero por sí sola no demuestra que el despliegue se haya completado, y mucho menos explica causalmente el precio de ZEC. La preparación en materia de seguridad y las expectativas del mercado requieren pruebas independientes.
El artículo se centra en las direcciones transparentes. Las direcciones transparentes estándar revelan primero el hash de la clave pública y solo hacen pública la clave correspondiente cuando se realiza un gasto; rotar las direcciones puede reducir la reutilización que se produce cuando una misma clave pública queda expuesta de forma continuada. La incorporación de compatibilidad con firmas se centra en la capa de autorización de pagos. De ello no se puede deducir que el cifrado, las pruebas y la privacidad histórica de todas las transacciones blindadas reciban al mismo tiempo la misma protección. Cada componente utiliza mecanismos distintos, por lo que hay que verificar por separado el alcance de la actualización.
Tampoco interpreto «recuperable» directamente como «totalmente resistente a la computación cuántica». La documentación oficial de Ironwood de Zcash explica por separado los billetes recuperables ante ataques cuánticos y el nuevo conjunto de fondos, que aún reutiliza algunas estructuras del protocolo Orchard. Esto nos recuerda que la capacidad de recuperación, la seguridad de las firmas y la protección de la privacidad resuelven problemas distintos. Que algo incluya la palabra «cuántico» en su nombre no sustituye una explicación concreta de las amenazas y del alcance de la protección.
Hay otra etapa de uso que es fácil pasar por alto: aunque una billetera genere varias direcciones nuevas, las consultas ordinarias de saldo pueden permitir que el servidor las vincule entre sí. PIR, descrito en el artículo original de Zakura, es un mecanismo concreto para ocultar las consultas al consultar el historial y los saldos. Las transacciones transparentes siguen siendo públicas en la cadena. Proteger la información de las consultas y ocultar las propias transacciones son cosas distintas; no se debe promocionar esta herramienta como si los pagos en la cadena ya fueran transacciones blindadas.
El artículo señala que el ajuste «Private queries» de Vizor permite probar una implementación experimental. Esto corresponde al estado experimental divulgado por el equipo, y no significa que todas las billeteras ya lo admitan de forma predeterminada ni que hayamos verificado su funcionamiento de manera independiente. La fluidez del proceso de uso y la fiabilidad de la recuperación todavía deberán aclararse con versiones posteriores y los resultados de las revisiones.
El nuevo aspecto que merece atención en esta ocasión es el plan de firmas y su relación con la rotación de direcciones y las consultas privadas; no he retomado el tema anterior de los riesgos para las claves BTC cambiando simplemente de token. Mi conclusión es que vale la pena seguir de cerca los objetivos de ingeniería claramente definidos, pero para saber si realmente cambia el límite de seguridad habrá que observar las reglas oficiales y su adopción efectiva. A continuación, conviene prestar atención a tres aspectos: la implementación de las firmas, las condiciones de activación de la red principal y la integración en las billeteras. Cualquier retraso o cambio de alcance exigirá revisar nuestras conclusiones; no se puede usar el compromiso de un mes para afirmar que toda la red ya es segura.