Vamos fazer um experimento de arquitetura hoje: numa mesma transferência de valores mobiliários, é preciso verificar a elegibilidade do investidor, realizar a liquidação do ativo e, ao mesmo tempo, não divulgar a identidade, o saldo e as condições da transação para todos. Se a privacidade for apenas uma funcionalidade adicionada por algum aplicativo, outros aplicativos talvez não reconheçam o mesmo conjunto de credenciais, e as regras de conformidade podem acabar sendo escritas de formas diferentes.
O mais complicado é que, quando o mesmo ativo é transferido entre contratos diferentes, a elegibilidade que o aplicativo anterior conseguiu provar pode não ser reutilizável diretamente pelo próximo; no fim, ainda é necessário contar com uma camada intermediária adicional para reexplicar tudo.
Quando analisei a arquitetura da Dusk, o ponto que mais chama atenção é exatamente isso: ela não coloca a privacidade separadamente dentro de uma carteira ou de um misturador, mas a divide em componentes distintos na L1. A documentação oficial define o DuskDS como a camada de liquidação responsável pelo consenso, finalização e disponibilidade de dados; o Moonlight lida com contas transparentes, e o Phoenix lida com transferências shielded (protegidas) e confidenciais. Ambos conseguem transferir DUSK, pagar gas e também servir como entradas de execução para contratos.
Mas a Dusk também não força todos os ativos a cair no mesmo modo de privacidade. O DuskVM roda diretamente contratos em Rust/WASM na L1, adequado para aplicações que precisam de ativos nativos, privacidade ou capacidades de zero conhecimento; o DuskEVM fornece um ambiente compatível com OP Stack para EVM, e realiza a liquidação e a disponibilidade de dados via DuskDS.
Isso é uma escolha: quanto mais as regras de privacidade ficam próximas da camada de transição de estado, mais fácil é manter a consistência entre aplicações. Porém, a complexidade do protocolo e o custo de validação também aumentam. Os nós não só precisam tratar assinaturas comuns, mas também validar provas, atualizar estados ocultos e garantir que aplicações diferentes não contornem o mesmo conjunto de regras do ativo. Em outras palavras, a camada base não assume um “interruptor de privacidade”, e sim um conjunto de restrições executadas continuamente.
@Dusk $DUSK #dusk
Portanto, vale a pena entender a trajetória da Dusk assim: invariantes de privacidade são mantidas pela infraestrutura; o escopo em que elas se aplicam fica a cargo das camadas de aplicação e de identidade. O site oficial enfatiza confidential by default, provas de zero conhecimento e controlled visibility; o whitepaper coloca contas transparentes e UTXO de privacidade lado a lado. Isso é bem mais preciso do que simplesmente dizer “privacidade na blockchain”.
O mais complicado é que, quando o mesmo ativo é transferido entre contratos diferentes, a elegibilidade que o aplicativo anterior conseguiu provar pode não ser reutilizável diretamente pelo próximo; no fim, ainda é necessário contar com uma camada intermediária adicional para reexplicar tudo.
Quando analisei a arquitetura da Dusk, o ponto que mais chama atenção é exatamente isso: ela não coloca a privacidade separadamente dentro de uma carteira ou de um misturador, mas a divide em componentes distintos na L1. A documentação oficial define o DuskDS como a camada de liquidação responsável pelo consenso, finalização e disponibilidade de dados; o Moonlight lida com contas transparentes, e o Phoenix lida com transferências shielded (protegidas) e confidenciais. Ambos conseguem transferir DUSK, pagar gas e também servir como entradas de execução para contratos.
Mas a Dusk também não força todos os ativos a cair no mesmo modo de privacidade. O DuskVM roda diretamente contratos em Rust/WASM na L1, adequado para aplicações que precisam de ativos nativos, privacidade ou capacidades de zero conhecimento; o DuskEVM fornece um ambiente compatível com OP Stack para EVM, e realiza a liquidação e a disponibilidade de dados via DuskDS.
Isso é uma escolha: quanto mais as regras de privacidade ficam próximas da camada de transição de estado, mais fácil é manter a consistência entre aplicações. Porém, a complexidade do protocolo e o custo de validação também aumentam. Os nós não só precisam tratar assinaturas comuns, mas também validar provas, atualizar estados ocultos e garantir que aplicações diferentes não contornem o mesmo conjunto de regras do ativo. Em outras palavras, a camada base não assume um “interruptor de privacidade”, e sim um conjunto de restrições executadas continuamente.
@Dusk $DUSK #dusk
Portanto, vale a pena entender a trajetória da Dusk assim: invariantes de privacidade são mantidas pela infraestrutura; o escopo em que elas se aplicam fica a cargo das camadas de aplicação e de identidade. O site oficial enfatiza confidential by default, provas de zero conhecimento e controlled visibility; o whitepaper coloca contas transparentes e UTXO de privacidade lado a lado. Isso é bem mais preciso do que simplesmente dizer “privacidade na blockchain”.