Ontem à noite, ao terminar a leitura da documentação de arquitetura do @Dusk , um paradoxo sempre acaba aparecendo: existem duas rotas de execução em paralelo — é uma estratégia de agradar a duas partes, ou uma divisão de funções bem definida?
A documentação oficial deixa isso bem claro. O DuskDS, como camada de liquidação e disponibilidade de dados, fica na base. Sobre ele, o Dusk oferece duas rotas de contratos inteligentes: o DuskVM (antes chamado de Piecrust) executa contratos em Rust/WASM, diretamente na Dusk L1; já o DuskEVM é um ambiente equivalente para execução EVM, baseado no OP Stack, e usa o DuskDS para concluir a liquidação e a disponibilidade de dados.
A divisão de trabalho entre esses dois sistemas não é duplicação de infraestrutura.
O DuskVM é voltado para negócios no nível de protocolo. Ele suporta a lógica de liquidação de privacidade de dois modelos de transação — Phoenix/Moonlight. Os contratos são compilados para WASM, e não para bytecode EVM, o que já se adapta naturalmente a sistemas de provas de conhecimento zero. Quando for necessário acionar recursos nativos de privacidade, o caminho é o DuskVM.
O DuskEVM funciona como uma “camada de compatibilidade”. Desenvolvedores acostumados com Solidity não precisam reestruturar o código: podem usar diretamente ferramentas familiares como Hardhat e Foundry, e até carteiras MetaMask conseguem integração sem atrito. Após a execução, os dados da transação são enviados ao DuskDS em formato de blob por meio do batcher para o registro final.
Essa divisão, por si só, é razoável — a lógica nativa de privacidade e conformidade roda no ambiente base, enquanto o nível de compatibilidade EVM atua como porta de entrada para o tráfego, cada um cumprindo seu papel. Mas ser razoável não significa que já tenha sido validado.
O ponto crucial é: quantas aplicações são implantadas em cada tipo de ambiente? Com base em informações públicas, já há 17 projetos DeFi implantados na rede de testes do DuskEVM, mas não encontrei dados estatísticos claros sobre o número, proporção e tipos de aplicações nativas no ambiente do DuskVM. Sem dados de distribuição de apps, “divisão razoável” ainda fica no nível do desenho arquitetural. A lógica da arquitetura pode ser deduzida, mas o efeito no ecossistema só pode ser respondido com dados.
#dusk $DUSK
A documentação oficial deixa isso bem claro. O DuskDS, como camada de liquidação e disponibilidade de dados, fica na base. Sobre ele, o Dusk oferece duas rotas de contratos inteligentes: o DuskVM (antes chamado de Piecrust) executa contratos em Rust/WASM, diretamente na Dusk L1; já o DuskEVM é um ambiente equivalente para execução EVM, baseado no OP Stack, e usa o DuskDS para concluir a liquidação e a disponibilidade de dados.
A divisão de trabalho entre esses dois sistemas não é duplicação de infraestrutura.
O DuskVM é voltado para negócios no nível de protocolo. Ele suporta a lógica de liquidação de privacidade de dois modelos de transação — Phoenix/Moonlight. Os contratos são compilados para WASM, e não para bytecode EVM, o que já se adapta naturalmente a sistemas de provas de conhecimento zero. Quando for necessário acionar recursos nativos de privacidade, o caminho é o DuskVM.
O DuskEVM funciona como uma “camada de compatibilidade”. Desenvolvedores acostumados com Solidity não precisam reestruturar o código: podem usar diretamente ferramentas familiares como Hardhat e Foundry, e até carteiras MetaMask conseguem integração sem atrito. Após a execução, os dados da transação são enviados ao DuskDS em formato de blob por meio do batcher para o registro final.
Essa divisão, por si só, é razoável — a lógica nativa de privacidade e conformidade roda no ambiente base, enquanto o nível de compatibilidade EVM atua como porta de entrada para o tráfego, cada um cumprindo seu papel. Mas ser razoável não significa que já tenha sido validado.
O ponto crucial é: quantas aplicações são implantadas em cada tipo de ambiente? Com base em informações públicas, já há 17 projetos DeFi implantados na rede de testes do DuskEVM, mas não encontrei dados estatísticos claros sobre o número, proporção e tipos de aplicações nativas no ambiente do DuskVM. Sem dados de distribuição de apps, “divisão razoável” ainda fica no nível do desenho arquitetural. A lógica da arquitetura pode ser deduzida, mas o efeito no ecossistema só pode ser respondido com dados.
#dusk $DUSK
