Estava vasculhando as documentações do módulo de conformidade da Dusk na semana passada e quase passei direto pela parte que realmente importa. A Dusk ($DUSK , #dusk , @Dusk ) é apresentada como "privacidade encontra conformidade" como se fosse um argumento de marketing, mas a parte interessante é o mecanismo que eles escolheram para chegar lá.
A maioria das cadeias de privacidade trata a conformidade como um complemento: você obtém uma chave de visualização, entrega ao regulador e pronto. O modelo de transferência da Zedger da Dusk incorpora verificações de licenciamento na própria validade da transação, e não como uma camada de auditoria externa. Isso significa que uma transferência pode ser criptograficamente válida na cadeia, mas ainda assim falhar se a contraparte não atender às condições de licenciamento embutidas no ativo. Não é "comprovar conformidade depois do fato", é "a conformidade é parte do que torna a transição de estado correta desde o início".
O que eu não paro de considerar é o trade-off que ninguém enquadra de forma honesta: isso só funciona se os emissores realmente configurarem essas condições corretamente no momento da criação do ativo, o que significa que a garantia de privacidade é tão boa quanto o cuidado com que alguém configurou um smart contract que a maioria dos usuários nunca chega a ver. As ferramentas iniciais em torno disso ainda são escassas. Então a pergunta real não é se a criptografia se sustenta, e sim se os emissores vão de fato usar a granularidade disponível para eles, ou se vão recorrer às configurações mais permissivas que apenas passam por uma lista de verificação.