Na primeira vez que estudei o Dusk, desconfiei um pouco do que chamam de “finanças de privacidade”. Antes, muitos projetos diziam que privacidade é apenas esconder; mas, diante de instituições e de mercados regulados, o problema não é tão simples. O sistema financeiro precisa não é do “invisível”, e sim da capacidade de, quando for necessário verificar, provar que certas coisas são verdadeiras.
Mais tarde, ao revisitar os materiais do Dusk Citadel, percebi que minha compreensão anterior estava enviesada. O Citadel separa a autenticação em duas etapas. Na primeira, o usuário envia uma transação on-chain, anexando um endereço de “esconderijo” invisível que apenas ele consegue controlar. A entidade emissora da licença fica varrendo a cadeia; ao ver o pedido enviado para si, valida e aprova, cunhando a licença nesse endereço. Então o usuário varre o link e a recebe. Na segunda etapa, o usuário usa a licença para solicitar um serviço: ele envia outra transação on-chain com uma prova de conhecimento zero, que comprova que ele possui uma licença válida, além de calcular um cookie de sessão — um valor que pode ser verificado com dados da própria cadeia, cujo significado é conhecido apenas pelo usuário e pelo provedor do serviço. O cookie é enviado ao provedor por um canal criptografado. O provedor então confere, na cadeia, o ID da sessão; se bater, libera o acesso. O processo inteiro acontece na cadeia, mas fora o usuário e o provedor do serviço, ninguém sabe quem está solicitando o quê.
As restrições desse circuito de prova de conhecimento zero são em torno de 35 mil; gerar a prova leva dezenas de segundos, enquanto a verificação on-chain leva apenas 0,007 segundo. Para o usuário, esperar mais alguns segundos para cada solicitação é algo que acontece, mas nas validações seguintes o tempo é no nível de milissegundos. E ainda há o fato de que a licença pode ser cancelada com antecedência; então não é preciso esperar expirar. Por isso, esses dezenas de segundos de geração não afetam muito o desempenho geral do protocolo.
O Citadel precisa garantir cinco coisas: provar que você realmente tem a credencial, sem expor informações adicionais; o provedor conseguir revogar, mas, enquanto a credencial não for revogada, ela continuar válida; suas atividades não poderem ser rastreadas; a credencial não poder ser reutilizada; e apenas vazar as informações necessárias. Essas cinco propriedades, somadas às ferramentas para desenvolvedores do Moat já empacotadas como SDK, formam o núcleo da camada de identidade do Dusk — ela fica no mesmo nível do DuskDS e do DuskVM, não é uma privacidade independente: é o que determina quem está autorizado a fazer as transações públicas do Moonlight e as transações privadas do Phoenix.
Ao chegar aqui, parei para pensar em uma coisa. Um sistema de privacidade verdadeiramente maduro não faz com que tudo seja invisível; ele faz com que diferentes papéis vejam apenas aquilo que devem ver. No futuro, quando os ativos forem tokenizados on-chain, o diferencial competitivo não será quem esconde mais #dusk $DUSK @Dusk
Mais tarde, ao revisitar os materiais do Dusk Citadel, percebi que minha compreensão anterior estava enviesada. O Citadel separa a autenticação em duas etapas. Na primeira, o usuário envia uma transação on-chain, anexando um endereço de “esconderijo” invisível que apenas ele consegue controlar. A entidade emissora da licença fica varrendo a cadeia; ao ver o pedido enviado para si, valida e aprova, cunhando a licença nesse endereço. Então o usuário varre o link e a recebe. Na segunda etapa, o usuário usa a licença para solicitar um serviço: ele envia outra transação on-chain com uma prova de conhecimento zero, que comprova que ele possui uma licença válida, além de calcular um cookie de sessão — um valor que pode ser verificado com dados da própria cadeia, cujo significado é conhecido apenas pelo usuário e pelo provedor do serviço. O cookie é enviado ao provedor por um canal criptografado. O provedor então confere, na cadeia, o ID da sessão; se bater, libera o acesso. O processo inteiro acontece na cadeia, mas fora o usuário e o provedor do serviço, ninguém sabe quem está solicitando o quê.
As restrições desse circuito de prova de conhecimento zero são em torno de 35 mil; gerar a prova leva dezenas de segundos, enquanto a verificação on-chain leva apenas 0,007 segundo. Para o usuário, esperar mais alguns segundos para cada solicitação é algo que acontece, mas nas validações seguintes o tempo é no nível de milissegundos. E ainda há o fato de que a licença pode ser cancelada com antecedência; então não é preciso esperar expirar. Por isso, esses dezenas de segundos de geração não afetam muito o desempenho geral do protocolo.
O Citadel precisa garantir cinco coisas: provar que você realmente tem a credencial, sem expor informações adicionais; o provedor conseguir revogar, mas, enquanto a credencial não for revogada, ela continuar válida; suas atividades não poderem ser rastreadas; a credencial não poder ser reutilizada; e apenas vazar as informações necessárias. Essas cinco propriedades, somadas às ferramentas para desenvolvedores do Moat já empacotadas como SDK, formam o núcleo da camada de identidade do Dusk — ela fica no mesmo nível do DuskDS e do DuskVM, não é uma privacidade independente: é o que determina quem está autorizado a fazer as transações públicas do Moonlight e as transações privadas do Phoenix.
Ao chegar aqui, parei para pensar em uma coisa. Um sistema de privacidade verdadeiramente maduro não faz com que tudo seja invisível; ele faz com que diferentes papéis vejam apenas aquilo que devem ver. No futuro, quando os ativos forem tokenizados on-chain, o diferencial competitivo não será quem esconde mais #dusk $DUSK @Dusk
