No começo eu achava que o Dusk era apenas uma “cadeia de privacidade” — o modelo de contas é bem parecido com o de outras moedas de privacidade, ou seja, só criptografia por padrão. Só que, depois de ler a documentação inteira, percebi que eu tinha pensado pequeno demais: o Dusk, na verdade, mantém dois sistemas de contas coexistindo, um ao lado do outro. Esse tipo de design eu não tinha visto em nenhum outro projeto.

Phoenix é o modelo UTXO: ele usa transações confidenciais com provas de conhecimento zero. Valores e participantes ficam invisíveis por padrão, o que se aproxima da abordagem de muitos projetos focados em privacidade. Mas o Dusk também roda, em paralelo, o Moonlight, que é um modelo de contas, no estilo do Ethereum — transparente e verificável. Na mesma blockchain, você pode escolher qual sistema de contas usar para receber e enviar ativos. E ainda dá para converter ativos entre os dois sistemas.

À primeira vista, esse design parece um pouco “dividido”, eu também pensei assim no começo, até entender uma coisa: instituições precisam fazer transações de acordo com normas de conformidade — e justamente por isso, elas precisam alternar entre “privacidade quando for necessário” e “transparência quando for necessário”, em vez de ficar presas a um único modo. Por exemplo: remanejamento interno de ativos precisa ser mantido em sigilo, mas títulos/valores emitidos publicamente devem permitir que o regulador consulte quando quiser. Usar apenas um mesmo modelo de contas dificulta atender aos dois lados ao mesmo tempo; separar em dois sistemas paralelos é, na prática, uma atitude mais honesta — sem fingir que um único modo daria conta de todos os cenários.

O custo também é bem claro: dois sistemas de contas significam dois conjuntos de lógica de gerenciamento de estado. Os desenvolvedores precisam entender, simultaneamente, dois paradigmas de programação — UTXO e contas — e a complexidade de chamadas fica bem maior do que em uma blockchain com um único modelo. Olhei o fórum de desenvolvedores: há muitos tópicos sobre a questão de conversão entre Phoenix/Moonlight, o que mostra que essa curva de aprendizado é real, não é só impressão minha.

A complexidade dá em flexibilidade. Se vale a pena ou não, depende de haver, no fim, cenários reais em que essa capacidade de alternar seja realmente usada — e não apenas ficar na ideia de que “o design é bem inteligente”.
O que vocês acham: esse esquema de “querer as duas coisas” com dois modelos de contas é uma escolha inteligente de concessões, ou é uma complexidade desnecessária adicionada para os desenvolvedores?
@Dusk_Foundation #dusk $DUSK