Olá, queridos amigos! Quando comecei a me aprofundar em Dusk, tive uma pergunta simples: se a rede foi criada para mercados financeiros regulamentados, como ela consegue equilibrar transparência e privacidade?
Encontrei a resposta no DuskDS. Neste nível, a Dusk oferece dois modelos nativos de transação: Moonlight e Phoenix.
Moonlight é o modelo público, baseado em contas. Os saldos das contas ficam visíveis, e as transferências mostram o remetente, o destinatário e o valor. Isso o torna adequado para fluxos que precisam permanecer observáveis, como certos cenários de tesouraria ou relatórios.
Phoenix funciona de forma diferente. É um modelo protegido, baseado em notas, que usa provas de conhecimento zero. Os fundos existem como notas criptografadas, enquanto as transações provam que a operação é válida, que há fundos suficientes e que não ocorre dupla contagem, sem revelar o valor da transferência, as notas específicas envolvidas ou o remetente da nota para observadores.
É aqui que acho a abordagem da Dusk especialmente interessante: privacidade não significa que a informação nunca possa ser divulgada.
Phoenix oferece divulgação seletiva por meio de chaves de visualização. Quando exigido para regulamentação ou auditoria, os usuários podem revelar seletivamente as informações relevantes.
O resultado é uma configuração prática: uma única rede pode suportar transferências públicas quando a transparência é necessária e transferências protegidas quando as informações financeiras precisam permanecer privadas.
E Moonlight e Phoenix não são redes separadas. Ambos operam no DuskDS, enquanto o Transfer Contract aceita suas diferentes cargas úteis de transação, as direciona para a lógica de verificação apropriada e mantém o estado global consistente.
Então eu descreveria a privacidade na Dusk não apenas como a capacidade de ocultar uma transação. É melhor entendida como controle sobre quais informações são públicas, quais permanecem confidenciais e o que pode ser divulgado seletivamente quando necessário.
No próximo post, vamos ver como as provas de conhecimento zero funcionam dentro do Phoenix e qual é o papel do Prover nesse processo.
#dusk $DUSK @Dusk
Encontrei a resposta no DuskDS. Neste nível, a Dusk oferece dois modelos nativos de transação: Moonlight e Phoenix.
Moonlight é o modelo público, baseado em contas. Os saldos das contas ficam visíveis, e as transferências mostram o remetente, o destinatário e o valor. Isso o torna adequado para fluxos que precisam permanecer observáveis, como certos cenários de tesouraria ou relatórios.
Phoenix funciona de forma diferente. É um modelo protegido, baseado em notas, que usa provas de conhecimento zero. Os fundos existem como notas criptografadas, enquanto as transações provam que a operação é válida, que há fundos suficientes e que não ocorre dupla contagem, sem revelar o valor da transferência, as notas específicas envolvidas ou o remetente da nota para observadores.
É aqui que acho a abordagem da Dusk especialmente interessante: privacidade não significa que a informação nunca possa ser divulgada.
Phoenix oferece divulgação seletiva por meio de chaves de visualização. Quando exigido para regulamentação ou auditoria, os usuários podem revelar seletivamente as informações relevantes.
O resultado é uma configuração prática: uma única rede pode suportar transferências públicas quando a transparência é necessária e transferências protegidas quando as informações financeiras precisam permanecer privadas.
E Moonlight e Phoenix não são redes separadas. Ambos operam no DuskDS, enquanto o Transfer Contract aceita suas diferentes cargas úteis de transação, as direciona para a lógica de verificação apropriada e mantém o estado global consistente.
Então eu descreveria a privacidade na Dusk não apenas como a capacidade de ocultar uma transação. É melhor entendida como controle sobre quais informações são públicas, quais permanecem confidenciais e o que pode ser divulgado seletivamente quando necessário.
No próximo post, vamos ver como as provas de conhecimento zero funcionam dentro do Phoenix e qual é o papel do Prover nesse processo.
#dusk $DUSK @Dusk
