A Network foi cavar no “acesso ao auditor” porque é normalmente a parte mais vaga de qualquer pitch de privacidade. Queria o mecanismo real, não a frase.
A Dusk roda dois modelos de transação lado a lado: Moonlight (totalmente público, como um modelo de conta normal) e Phoenix (protegido, saldos/transfers confidenciais). Você escolhe por transação. Essa parte é direta.
A parte que eu não esperava: a divulgação ao auditor não é “o auditor ganha uma master key para tudo”. De acordo com o próprio material da Dusk, o usuário criptografa a carga útil da transação com uma chave do usuário e, em seguida, criptografa essa chave do usuário com a chave do auditor — de modo que apenas o auditor específico consiga desbloqueá-la. Uma prova de conhecimento zero então confirma que a chave do auditor foi realmente usada corretamente, sem expor a carga útil para qualquer pessoa que valide a cadeia.
Então é divulgação ponto a ponto, chave-específica, e não uma backdoor que fica sentada no sistema inteiro. Sem chave do auditor = nenhum acesso, ponto final, nem mesmo para os validadores próprios da rede.
A lacuna que eu não consegui fechar completamente: a documentação descreve isso na camada de identidade Citadel, mas eu não encontrei um caso público de um regulador realmente puxando dados por esse fluxo no mainnet ainda. Leitura parece sólida no papel, mas “o auditor descriptografa uma transação via criptografia comprovável” e “o workflow real de um regulador durante uma auditoria ao vivo” são dois testes diferentes.
Alguém já viu isso ser acionado num cenário real de conformidade, não só documentado como uma capacidade
#dusk $DUSK #dusk $DUSK