‎Certa vez, um amigo chaveiro me disse que as fechaduras mais difíceis de abrir não são as que têm mais pinos — são as em que mudar até um único pino invalida todo o mecanismo, e não apenas aquele pino. Eu assumi que as provas de segurança de Phoenix da Dusk guardavam contra o óbvio — propriedade, equilíbrio, gasto duplo — e que a maleabilidade era um problema de outra pessoa, tratado em outro lugar na pilha.

‎Essa suposição desmoronou quando encontrei o próprio artigo formal de prova de segurança da Dusk para Phoenix.

‎Ele afirma diretamente: a Dusk publicou modelos de segurança e provas cobrindo não-maleabilidade, indistinguibilidade do ledger e equilíbrio com possibilidade de gasto de notas, tudo como propriedades que Phoenix satisfaz em conjunto, não como verificações independentes adicionadas em separado. A proteção contra maleabilidade significa que uma transação não pode ser alterada depois do fato e ainda passar como a mesma prova válida — alguém que intercepta uma transação transmitida não consegue ajustá-la e reenviá-la numa versão modificada que continue verificando.

‎Vale a pena nomear o que torna isso realmente raro: o mesmo artigo diz que a Zcash tentou uma abordagem semelhante de segurança formal para seu próprio modelo de transação e acabou abandonando. Os materiais da Dusk descrevem Phoenix como o primeiro modelo de transação que preserva a privacidade a disponibilizar provas de segurança completas para todas essas propriedades, juntas.

‎O teste real para DUSK é saber se essa cobertura de provas formais se mantém à medida que o desenvolvimento da Phoenix 2.0 avança, mencionado na mesma atualização por razões de conformidade com a MiCA, e que muda a implementação subjacente.

‎Uma garantia formalmente provada de não-maleabilidade importa mais para você do que uma que simplesmente nunca foi quebrada na prática?

#dusk $DUSK @Dusk