#dusk $DUSK @Dusk
O que acho interessante no design de privacidade da Dusk não é apenas que as notas são ocultadas. É onde a ocultação acontece e quantas suposições precisam ser verdadeiras ao mesmo tempo.

A Phoenix usa compromissos e uma árvore de Merkle, enquanto compromissos de valor adicionam um fator de cegamento. Os validadores podem verificar a consistência sem aprender a quantia. Endereços furtivos também tornam o vínculo entre destinatários mais difícil.

A camada de criptografia é onde eu analiso com mais rigor. A Phoenix atual expõe o AES como seu cifrador simétrico, enquanto a pilha também inclui JubJub ElGamal e Poseidon. A biblioteca Poseidon da Dusk tem funcionalidades de criptografia, mas dizer “Poseidon fornece confidencialidade” é simplista demais. A implementação evoluiu, e isso importa ao avaliar segurança semântica.

Minha pergunta real é se a composição foi provada como um único sistema. Um compromisso pode ocultar um valor e a criptografia pode ocultar texto em claro, mas a privacidade ainda pode falhar por metadados, manejo de chaves, uso incorreto de nonce, correlação de endereços ou uma relação de prova falha. Já vi isso antes: primitivas fortes não tornam automaticamente um protocolo forte.

A Poseidon foi construída para computação amigável a ZK, enquanto o AES é maduro para criptografia geral. Isso pode ajudar no desempenho, mas torna importante a fronteira entre criptografar, comprometer e provar.

Eu ainda não estou pronto para confiar na construção porque os ingredientes são respeitados. Eu quero um argumento formal mostrando que a criptografia de notas oculta valores e identidades. É aí que a alegação de privacidade da Dusk se torna algo que eu posso avaliar.