He estado sentado con una pregunta para la documentación de Dusk que no responde directamente con números concretos: ¿dos notas distintas de Phoenix pueden producir alguna vez el mismo nullifier.
Lo que puedo confirmar con precisión: el propio repositorio de Phoenix de Dusk establece que el nullifier se calcula específicamente para que un observador externo no pueda vincularlo con la nota de la que proviene. Cada nota se codifica mediante hash en las hojas de un árbol de Merkle de notas, y gastar una produce un valor determinista del nullifier vinculado a los datos de esa nota específica.
Ese proceso de hash subyacente —a través de la estructura del árbol de Merkle de Dusk y operaciones criptográficas más amplias— se ejecuta en Poseidon, una función hash compatible con SNARK diseñada por el propio equipo de Dusk específicamente para hashing resistente a colisiones dentro de circuitos de cero conocimiento. Eso no es un hash genérico tomado de estantería; está construido a medida para este tipo de trabajo de compromiso nativo de ZK.
Pero ser resistente a colisiones no es lo mismo que estar libre de colisiones. Cualquier función hash, incluido Poseidon, conlleva una probabilidad teórica (astronómicamente pequeña) de que dos entradas distintas produzcan la misma salida; esa es la naturaleza del hashing en sí, no una debilidad específica de Dusk.
Lo que no he encontrado en los materiales propios de Dusk es ninguna cifra publicada sobre la probabilidad de colisión específica para sus parámetros exactos de Poseidon, ni documentación de pruebas dedicadas de colisión más allá de las propiedades generales de seguridad que Poseidon hereda por diseño.
Si alguien ha visto un informe de auditoría que cubra esta propiedad específica para la implementación de Dusk, me gustaría compararlo con lo que está documentado públicamente.
#dusk $DUSK @Dusk
Lo que puedo confirmar con precisión: el propio repositorio de Phoenix de Dusk establece que el nullifier se calcula específicamente para que un observador externo no pueda vincularlo con la nota de la que proviene. Cada nota se codifica mediante hash en las hojas de un árbol de Merkle de notas, y gastar una produce un valor determinista del nullifier vinculado a los datos de esa nota específica.
Ese proceso de hash subyacente —a través de la estructura del árbol de Merkle de Dusk y operaciones criptográficas más amplias— se ejecuta en Poseidon, una función hash compatible con SNARK diseñada por el propio equipo de Dusk específicamente para hashing resistente a colisiones dentro de circuitos de cero conocimiento. Eso no es un hash genérico tomado de estantería; está construido a medida para este tipo de trabajo de compromiso nativo de ZK.
Pero ser resistente a colisiones no es lo mismo que estar libre de colisiones. Cualquier función hash, incluido Poseidon, conlleva una probabilidad teórica (astronómicamente pequeña) de que dos entradas distintas produzcan la misma salida; esa es la naturaleza del hashing en sí, no una debilidad específica de Dusk.
Lo que no he encontrado en los materiales propios de Dusk es ninguna cifra publicada sobre la probabilidad de colisión específica para sus parámetros exactos de Poseidon, ni documentación de pruebas dedicadas de colisión más allá de las propiedades generales de seguridad que Poseidon hereda por diseño.
Si alguien ha visto un informe de auditoría que cubra esta propiedad específica para la implementación de Dusk, me gustaría compararlo con lo que está documentado públicamente.
#dusk $DUSK @Dusk