O detalhe de privacidade em Dusk que eu não esperava não é sobre ocultar saldos. É sobre o que acontece depois que uma prova de identidade com conhecimento zero é bem-sucedida.
A especificação em rascunho do Citadel 2 para maio de 2026 usa um "session_id" na cadeia como um nullifier. Para a mesma licença oculta e o mesmo desafio aceito, o contrato pode rejeitar uma sessão duplicada. À primeira vista, isso parece proteção contra replay.
Mas a especificação traça uma fronteira mais nítida: o nullifier impede a criação de sessões on-chain duplicadas; ele não impede que alguém reutilize o mesmo cookie de sessão divulgado off-chain.
Isso me fez olhar duas vezes.
No Citadel, a cadeia verifica a validade criptográfica e registra a sessão. O Provedor de Serviço ainda precisa impor suas próprias regras de replay, confiança do emissor, revogação, expiração, vinculação de conta e limites de taxa.
Acho essa separação mais interessante do que um simples slogan “privacidade + conformidade”. Ela impede que o protocolo base codifique a política de acesso de cada instituição, ao mesmo tempo em que transfere a responsabilidade real de autorização para a camada de aplicação.
O custo disso é óbvio: builders não podem tratar “prova ZK válida” como equivalente a “credencial de acesso reutilizável e segura”.
Para @Dusk and $DUSK , eu observaria como os perfis padrão do Citadel em produção padronizam o uso único, o vínculo e a revogação sem enfraquecer a privacidade. Quais escolhas de política viram padrão — e quais permanecem específicas da aplicação? #dusk
#dusk $DUSK @Dusk
A especificação em rascunho do Citadel 2 para maio de 2026 usa um "session_id" na cadeia como um nullifier. Para a mesma licença oculta e o mesmo desafio aceito, o contrato pode rejeitar uma sessão duplicada. À primeira vista, isso parece proteção contra replay.
Mas a especificação traça uma fronteira mais nítida: o nullifier impede a criação de sessões on-chain duplicadas; ele não impede que alguém reutilize o mesmo cookie de sessão divulgado off-chain.
Isso me fez olhar duas vezes.
No Citadel, a cadeia verifica a validade criptográfica e registra a sessão. O Provedor de Serviço ainda precisa impor suas próprias regras de replay, confiança do emissor, revogação, expiração, vinculação de conta e limites de taxa.
Acho essa separação mais interessante do que um simples slogan “privacidade + conformidade”. Ela impede que o protocolo base codifique a política de acesso de cada instituição, ao mesmo tempo em que transfere a responsabilidade real de autorização para a camada de aplicação.
O custo disso é óbvio: builders não podem tratar “prova ZK válida” como equivalente a “credencial de acesso reutilizável e segura”.
Para @Dusk and $DUSK , eu observaria como os perfis padrão do Citadel em produção padronizam o uso único, o vínculo e a revogação sem enfraquecer a privacidade. Quais escolhas de política viram padrão — e quais permanecem específicas da aplicação? #dusk
#dusk $DUSK @Dusk