#dusk $DUSK
Enquanto eu traduzia o modelo de transação @Dusk , sempre tive uma dúvida:
se o Phoenix consegue ocultar sender, receiver e amount, por que ainda manter o Moonlight, totalmente público?
Continuei lendo a documentação de integração e, na verdade, a resposta é bem realista.
Em alguns cenários, simplesmente é necessário ser público.
Por exemplo, quando uma exchange recebe DUSK.
Ela precisa verificar os registros de depósito que já foram finalizados, saber qual conta entrou com quanto e reconciliar os registros on-chain com seu próprio ledger de custódia.
Nessa situação, o account model do Moonlight acaba sendo muito mais simples.
O Phoenix segue outra lógica. Os fundos existem como shielded notes, e um ZK proof comprova que a entrada é válida e que não houve double spend, sem precisar expor as duas partes da transação nem o valor para todo mundo no navegador.
No fim, os dois modelos são processados no DuskDS, mas resolvem necessidades diferentes.
Esse detalhe mudou bastante a minha visão sobre o design de privacidade da Dusk.
Antes eu pensava:
quanto mais forte a privacidade, melhor.
Hoje eu já não vejo assim.
Em sistemas financeiros, o público tem sua utilidade, e a privacidade também. Depósitos em exchanges precisam ser escaneáveis; transferências comuns ou fluxos de fundos sensíveis nem sempre têm motivo para permanecer publicamente visíveis para sempre.
O mais interessante é que a própria Dusk Wallet também suporta conversão entre Moonlight e Phoenix.
Então ela não força o usuário a escolher um lado.
Quando precisa ser público, usa-se Moonlight; quando precisa de um shielded flow, entra-se no Phoenix.
Agora eu até acho que manter esses dois modelos ao mesmo tempo é mais prático do que enfiar todas as transações à força dentro da palavra “privacidade”.
Aqui, o público não é sinal de que a privacidade falhou, mas sim uma função preservada de forma intencional.
Enquanto eu traduzia o modelo de transação @Dusk , sempre tive uma dúvida:
se o Phoenix consegue ocultar sender, receiver e amount, por que ainda manter o Moonlight, totalmente público?
Continuei lendo a documentação de integração e, na verdade, a resposta é bem realista.
Em alguns cenários, simplesmente é necessário ser público.
Por exemplo, quando uma exchange recebe DUSK.
Ela precisa verificar os registros de depósito que já foram finalizados, saber qual conta entrou com quanto e reconciliar os registros on-chain com seu próprio ledger de custódia.
Nessa situação, o account model do Moonlight acaba sendo muito mais simples.
O Phoenix segue outra lógica. Os fundos existem como shielded notes, e um ZK proof comprova que a entrada é válida e que não houve double spend, sem precisar expor as duas partes da transação nem o valor para todo mundo no navegador.
No fim, os dois modelos são processados no DuskDS, mas resolvem necessidades diferentes.
Esse detalhe mudou bastante a minha visão sobre o design de privacidade da Dusk.
Antes eu pensava:
quanto mais forte a privacidade, melhor.
Hoje eu já não vejo assim.
Em sistemas financeiros, o público tem sua utilidade, e a privacidade também. Depósitos em exchanges precisam ser escaneáveis; transferências comuns ou fluxos de fundos sensíveis nem sempre têm motivo para permanecer publicamente visíveis para sempre.
O mais interessante é que a própria Dusk Wallet também suporta conversão entre Moonlight e Phoenix.
Então ela não força o usuário a escolher um lado.
Quando precisa ser público, usa-se Moonlight; quando precisa de um shielded flow, entra-se no Phoenix.
Agora eu até acho que manter esses dois modelos ao mesmo tempo é mais prático do que enfiar todas as transações à força dentro da palavra “privacidade”.
Aqui, o público não é sinal de que a privacidade falhou, mas sim uma função preservada de forma intencional.