A maior confusão perigosa em carteiras de privacidade é entender “consegue ocultar” como “pode olhar menos uma vez”. Quando li, na página do Dusk Wallet, a linha “public and shielded DUSK” junto com o aviso de segurança de que “cada conexão, assinatura e transação precisa de aprovação”, percebi que o produto separou duas coisas que muitas vezes são confundidas: a exibição de ativos pode ser em camadas, mas a responsabilidade pela autorização não pode.
O navegador com extensão oficial de autogerenciamento do @Dusk também gerencia, ao mesmo tempo, DUSK público e shielded, e ainda apresenta a apps compatíveis solicitações de conexão, transação e assinatura. O desafio não está em a interface ter alguns estados de ativos a mais; está no fato de que o usuário pode facilmente confundir “o saldo de terceiros não é visível” com “esta autorização não é importante”. A privacidade on-chain responde ao que um observador consegue ver; o pop-up de assinatura, porém, responde ao que um aplicativo está prestes a fazer com você.
Os cenários ruins não estão longe. Um aplicativo falsificado embala o pedido como um login comum. O usuário, para proteger o saldo, escolhe o ativo shielded, mas então pula detalhes de conexão ou assinatura no pop-up. Mecanismos de sigilo não substituem o julgamento humano sobre a quem a autorização está sendo dada; e, em geral, o primeiro limite a ser atravessado é o limite operacional. O custo de verificação recai sobre o usuário de autogerenciamento, e a equipe da carteira precisa deixar o pedido claro a ponto de não poder ser facilmente interpretado de forma errada.
Eu não trato isso como uma questão de a carteira ter “mais ou menos” recursos. Se o $DUSK quer levar a privacidade para a rotina das operações financeiras, o mais importante é fazer com que cada solicitação exiba de forma inequívoca a identidade do site, as contas afetadas e as consequências das ações. #dusk