O que me chamou a atenção é que o modelo de privacidade da Dusk pode deixar um evento de autorização visível, mantendo a evidência de identidade por trás dele oculta.

No Citadel 2, um usuário prova com conhecimento zero que possui uma credencial registrada e assinada pelo provedor. O contrato verifica essa prova e registra uma sessão pública. Mas a documentação da Dusk diz que essa sessão não expõe a chave da carteira, a licença específica usada, a chave do provedor de licença, a chave do provedor de serviço, atributos assinados ou o caminho da prova de Merkle.

Essa é uma escolha de design mais interessante do que simplesmente dizer “KYC privado”.

Eu esperava que a própria blockchain decidisse se um usuário está em conformidade. Ela não decide. O Citadel prova que a credencial/sessão é válida criptograficamente; o provedor de serviço ainda decide quais emissores de credenciais ele confia, quais atributos satisfazem a política dele, se uma sessão está expirada ou revogada e se um cookie de sessão pode ser reutilizado.

Para mim, essa separação importa para aplicações financeiras. A privacidade é tratada pelo sistema de prova, enquanto as políticas de negócio e regulatórias permanecem configuráveis na camada da aplicação, em vez de ficarem “congeladas” em uma única regra universal.

Isso também cria uma troca real: flexibilidade é útil, mas a segurança depende de provedores de serviço definirem essas políticas corretamente.

Para dusk_foundation e DUSK, a parte que estou acompanhando não é apenas se as credenciais permanecem privadas, mas como aplicações reais implementam de forma consistente a camada de política ao redor delas.

@Dusk $DUSK #dusk