Primeira vez que vi @Dusk fazendo, ao mesmo tempo, dois modelos de negociação — Moonlight e Phoenix — eu na verdade tive uma dúvida bem direta:
se o seu foco é privacidade, por que não transformar tudo de forma a ser uma transação privada?
uma é transparente, a outra é privativa… não fica trabalhoso demais?
Depois, ao ler com atenção o whitepaper, eu passei a achar que essa “complicação” talvez seja justamente o que deixa o sistema mais próximo do funcionamento real do mercado financeiro.
O Moonlight é simples: segue um modelo de contas semelhante ao da Ethereum. Saldo, Nonce, status das transações — tudo isso fica público. A transação depende da validação por assinatura.
O Phoenix, por sua vez, segue outra lógica totalmente diferente.
Ele usa o modelo UTXO, introduzindo stealth address, nullifier e provas de conhecimento zero. A rede não precisa ver diretamente em qual transação você gastou, nem qual é o seu saldo; ela só precisa verificar aquela prova ZK: que você realmente tem os ativos, que o saldo é suficiente, que não há gasto duplo e que a transação não foi adulterada.
À primeira vista, parece que estão deixando o sistema mais complexo.
Mas a realidade do mercado financeiro não é, por natureza, algo de um único “nível de permissão”.
Depósitos e saques em corretoras podem ser mais adequados a uma conta pública.
Transferências de valores mobiliários e posições de ativos entre instituições, bem como operações de clientes, podem exigir privacidade.
E na auditoria, por outro lado, é necessário conseguir divulgar.
Se você enfiar todos os tipos de operação em um único modelo de transação, no final ou a privacidade fica insuficiente, ou a conformidade fica ruim.
Por isso, Moonlight + Phoenix me passam a sensação de que é como se existisse, dentro de um banco, tanto um “salão” quanto um “cofre”.
No salão, não há necessidade de esconder as coisas.
No cofre, também não há necessidade de mostrar aos desconhecidos.
O ponto não é ser totalmente transparente ou totalmente privativo; é que dinheiro diferente é tratado com regras diferentes.
Isso também explica por que agora o Dusk continua fazendo tanto L1 nativo quanto DuskEVM e Hedger. O DuskEVM oferece aos desenvolvedores Solidity um caminho familiar com o EVM; e o Hedger aproveita criptografia homomórfica e provas de conhecimento zero para complementar fluxos de transações confidenciais.
Eu pessoalmente acho que essa rota é mais realista do que “todos os desenvolvedores precisam aprender uma coisa nova do zero”.
Mas o problema também é bem claro.
Quanto mais módulos, mais complexo fica o sistema. Será que o Native L1, o DuskEVM, o Hedger e o Dusk Trade conseguirão realmente formar um ciclo fechado — e não quatro produtos contando histórias diferentes cada um por si? É isso que eu continuo observando.
$DUSK #dusk
se o seu foco é privacidade, por que não transformar tudo de forma a ser uma transação privada?
uma é transparente, a outra é privativa… não fica trabalhoso demais?
Depois, ao ler com atenção o whitepaper, eu passei a achar que essa “complicação” talvez seja justamente o que deixa o sistema mais próximo do funcionamento real do mercado financeiro.
O Moonlight é simples: segue um modelo de contas semelhante ao da Ethereum. Saldo, Nonce, status das transações — tudo isso fica público. A transação depende da validação por assinatura.
O Phoenix, por sua vez, segue outra lógica totalmente diferente.
Ele usa o modelo UTXO, introduzindo stealth address, nullifier e provas de conhecimento zero. A rede não precisa ver diretamente em qual transação você gastou, nem qual é o seu saldo; ela só precisa verificar aquela prova ZK: que você realmente tem os ativos, que o saldo é suficiente, que não há gasto duplo e que a transação não foi adulterada.
À primeira vista, parece que estão deixando o sistema mais complexo.
Mas a realidade do mercado financeiro não é, por natureza, algo de um único “nível de permissão”.
Depósitos e saques em corretoras podem ser mais adequados a uma conta pública.
Transferências de valores mobiliários e posições de ativos entre instituições, bem como operações de clientes, podem exigir privacidade.
E na auditoria, por outro lado, é necessário conseguir divulgar.
Se você enfiar todos os tipos de operação em um único modelo de transação, no final ou a privacidade fica insuficiente, ou a conformidade fica ruim.
Por isso, Moonlight + Phoenix me passam a sensação de que é como se existisse, dentro de um banco, tanto um “salão” quanto um “cofre”.
No salão, não há necessidade de esconder as coisas.
No cofre, também não há necessidade de mostrar aos desconhecidos.
O ponto não é ser totalmente transparente ou totalmente privativo; é que dinheiro diferente é tratado com regras diferentes.
Isso também explica por que agora o Dusk continua fazendo tanto L1 nativo quanto DuskEVM e Hedger. O DuskEVM oferece aos desenvolvedores Solidity um caminho familiar com o EVM; e o Hedger aproveita criptografia homomórfica e provas de conhecimento zero para complementar fluxos de transações confidenciais.
Eu pessoalmente acho que essa rota é mais realista do que “todos os desenvolvedores precisam aprender uma coisa nova do zero”.
Mas o problema também é bem claro.
Quanto mais módulos, mais complexo fica o sistema. Será que o Native L1, o DuskEVM, o Hedger e o Dusk Trade conseguirão realmente formar um ciclo fechado — e não quatro produtos contando histórias diferentes cada um por si? É isso que eu continuo observando.
$DUSK #dusk