#dusk $DUSK @Dusk No início eu pensei que o Phoenix funcionava como a maioria dos sistemas com proteção: a prova verifica a matemática e a criptografia, separadamente, oculta quem fez o quê. Mas, olhando com mais atenção para como o Phoenix da Dusk realmente verifica uma transação, essa separação simplesmente não existe. A titularidade, a autoria do remetente e a correção do saldo não são checadas fora da prova para depois serem ocultadas; elas são codificadas dentro do mesmo circuito que prova que a transação é válida desde o começo. E isso muda o que “verificar” significa aqui, porque a rede não está verificando uma transação visível e depois escolhendo mascará-la; ela está verificando uma prova que nunca carregava dados visíveis de início, e essa prova por si só já é suficiente para confirmar que não houve gasto duplo, que nada foi forjado e que o remetente realmente é o dono do que está transferindo. Assim, ninguém precisa ver a nota para confiar que foi liquidada corretamente. Correção e visibilidade deixam de estar atreladas; isso é uma coisa estranha de aceitar depois que você está acostumado a confiar porque consegue ver. O que eu continuo tentando entender é o que isso faz com a conformidade em @Dusk : porque, se a visibilidade não é necessária para a correção, então a divulgação por uma viewing key não está “desbloqueando uma verdade oculta”; está concedendo permissão para olhar algo que já foi liquidado e já foi verificado. Então a pergunta deixa de ser “isto pode ser provado?” e passa a ser “quem é autorizado a vê-lo?”. Isso é menos um problema de criptografia e mais de governança, decidido por quem controla a chave, e não pelo próprio protocolo. Então, quando um regulador ou uma exchange guarda uma viewing key e verifica uma transação no Dusk, eles estão de fato verificando algo que a cadeia não tivesse verificado por conta própria, ou estão apenas sendo deixados entrar numa sala que estava trancada para todo o resto? #Dusk