Nos últimos dias, voltei a ver @Dusk . O que mais me chama a atenção não é, na verdade, as duas palavras “privacidade”, e sim como ele lida com algo que é mais fácil de ignorar numa transação: o estado.
Moonlight e Phoenix me deram um recorte bem intuitivo. O primeiro coloca o saldo, o remetente, o destinatário e o valor em uma conta pública; o segundo transforma os fundos em notes criptografadas. A transação não expõe diretamente o valor, o remetente e a note específica. Em vez disso, usa ZKP para provar se há fundos suficientes e se ocorreu (ou não) double-spend; e, quando for preciso auditar, ainda dá para revelar via viewing key. As duas abordagens parecem muito diferentes, mas no fim precisam responder à mesma pergunta: após concluir esta transação, para que exatamente o estado na cadeia deve mudar? O que eu realmente parei para pensar foi o Transfer Contract — ele recebe diferentes tipos de payload, encaminha para a lógica de validação correspondente e, por fim, incorpora o resultado no mesmo conjunto global de estado. Essa etapa é o que impede que uma transação de privacidade vire outro livro-razão isolado.
Seguindo o estado ainda mais adiante: DuskDS é responsável por consenso, finalização, disponibilidade de dados e liquidação; DuskVM executa os contratos compilados para WASM, ficando bem próximo de como o Dusk L1 executa; e DuskEVM oferece outra rota de execução em EVM. O Hedger roda sobre o DuskEVM e usa criptografia homomórfica e ZKP para implementar transações confidenciais. Assim, conectando tudo, o que é realmente interessante no Dusk não é “esconder as transações”, e sim permitir que transações com visibilidades diferentes ainda entrem no mesmo sistema de atualização e liquidação de estado.
$DUSK assume o gas e o staking, fazendo com que tanto o custo de execução quanto a segurança da rede caiam na mesma camada econômica. Para mim, o próximo passo que realmente vale a pena observar é: depois que essa arquitetura entrar em processos financeiros reais, ela consegue fazer o que precisa ser escondido ficar escondido, o que precisa ser verificado ser verificado, e garantir que o estado final seja suficientemente determinável e suficientemente utilizável.
#dusk $DUSK @Dusk
Moonlight e Phoenix me deram um recorte bem intuitivo. O primeiro coloca o saldo, o remetente, o destinatário e o valor em uma conta pública; o segundo transforma os fundos em notes criptografadas. A transação não expõe diretamente o valor, o remetente e a note específica. Em vez disso, usa ZKP para provar se há fundos suficientes e se ocorreu (ou não) double-spend; e, quando for preciso auditar, ainda dá para revelar via viewing key. As duas abordagens parecem muito diferentes, mas no fim precisam responder à mesma pergunta: após concluir esta transação, para que exatamente o estado na cadeia deve mudar? O que eu realmente parei para pensar foi o Transfer Contract — ele recebe diferentes tipos de payload, encaminha para a lógica de validação correspondente e, por fim, incorpora o resultado no mesmo conjunto global de estado. Essa etapa é o que impede que uma transação de privacidade vire outro livro-razão isolado.
Seguindo o estado ainda mais adiante: DuskDS é responsável por consenso, finalização, disponibilidade de dados e liquidação; DuskVM executa os contratos compilados para WASM, ficando bem próximo de como o Dusk L1 executa; e DuskEVM oferece outra rota de execução em EVM. O Hedger roda sobre o DuskEVM e usa criptografia homomórfica e ZKP para implementar transações confidenciais. Assim, conectando tudo, o que é realmente interessante no Dusk não é “esconder as transações”, e sim permitir que transações com visibilidades diferentes ainda entrem no mesmo sistema de atualização e liquidação de estado.
$DUSK assume o gas e o staking, fazendo com que tanto o custo de execução quanto a segurança da rede caiam na mesma camada econômica. Para mim, o próximo passo que realmente vale a pena observar é: depois que essa arquitetura entrar em processos financeiros reais, ela consegue fazer o que precisa ser escondido ficar escondido, o que precisa ser verificado ser verificado, e garantir que o estado final seja suficientemente determinável e suficientemente utilizável.
#dusk $DUSK @Dusk
