Fiquei com a questão: a documentação do Dusk não responde diretamente com números exatos — duas anotações diferentes do Phoenix podem produzir o mesmo nullifier?
O que posso confirmar com precisão: o próprio repositório do Dusk sobre Phoenix afirma que o nullifier é computado especificamente para que um observador externo não consiga vinculá-lo à anotação de origem. Cada anotação é convertida em hash e inserida como folhas de uma árvore de Merkle de anotações, e gastar uma produz um valor de nullifier determinístico ligado aos dados daquela anotação específica.
A etapa de hashing por baixo disso — tanto na estrutura da árvore de Merkle do Dusk quanto em operações criptográficas mais amplas — usa Poseidon, uma função hash amigável para SNARK, projetada pela própria equipe do Dusk especificamente para hashing resistente a colisões dentro de circuitos de zero conhecimento. Não é um hash genérico reaproveitado “pronto”; é algo construído para este tipo de trabalho de compromisso nativo de ZK.
Mas “resistente a colisões” não é a mesma coisa que “à prova de colisões”. Qualquer função hash, incluindo o Poseidon, carrega uma chance teórica (astronomicamente pequena) de que duas entradas diferentes produzam a mesma saída — isso faz parte da própria ideia de hashing, e não é uma fraqueza específica do Dusk.
O que eu não encontrei nos materiais do próprio Dusk é qualquer número publicado de probabilidade de colisão específico para os parâmetros exatos do Poseidon, nem documentação de testes de colisão dedicados além das propriedades gerais de segurança que o Poseidon herda por design.
Se alguém já viu um relatório de auditoria cobrindo especificamente essa propriedade para a implementação do Dusk, eu gostaria de compará-lo com o que está documentado publicamente.
#dusk $DUSK @Dusk
O que posso confirmar com precisão: o próprio repositório do Dusk sobre Phoenix afirma que o nullifier é computado especificamente para que um observador externo não consiga vinculá-lo à anotação de origem. Cada anotação é convertida em hash e inserida como folhas de uma árvore de Merkle de anotações, e gastar uma produz um valor de nullifier determinístico ligado aos dados daquela anotação específica.
A etapa de hashing por baixo disso — tanto na estrutura da árvore de Merkle do Dusk quanto em operações criptográficas mais amplas — usa Poseidon, uma função hash amigável para SNARK, projetada pela própria equipe do Dusk especificamente para hashing resistente a colisões dentro de circuitos de zero conhecimento. Não é um hash genérico reaproveitado “pronto”; é algo construído para este tipo de trabalho de compromisso nativo de ZK.
Mas “resistente a colisões” não é a mesma coisa que “à prova de colisões”. Qualquer função hash, incluindo o Poseidon, carrega uma chance teórica (astronomicamente pequena) de que duas entradas diferentes produzam a mesma saída — isso faz parte da própria ideia de hashing, e não é uma fraqueza específica do Dusk.
O que eu não encontrei nos materiais do próprio Dusk é qualquer número publicado de probabilidade de colisão específico para os parâmetros exatos do Poseidon, nem documentação de testes de colisão dedicados além das propriedades gerais de segurança que o Poseidon herda por design.
Se alguém já viu um relatório de auditoria cobrindo especificamente essa propriedade para a implementação do Dusk, eu gostaria de compará-lo com o que está documentado publicamente.
#dusk $DUSK @Dusk