Só depois de comparar com a documentação de desenvolvimento mais recente @Dusk é que eu desfaço um mal-entendido comum: DuskEVM e DuskVM não são a mesma máquina virtual com dois nomes, nem é “um novo EVM que acabou com as chains nativas”. O que a documentação oferece aos desenvolvedores são dois caminhos de execução — quem já está familiarizado com Solidity, Foundry e Hardhat usa DuskEVM; quem precisa lidar diretamente com ativos de L1, a lógica de Phoenix/Moonlight, Rust/WASM ou capacidades de zero conhecimento usa DuskVM.
O DuskEVM segue a linha do OP Stack: a execução e as ferramentas são o mais próximas possível do ecossistema Ethereum; e a liquidação e a publicação de dados ficam a cargo do DuskDS, mantendo $DUSK como “gas”. Já o DuskVM roda contratos WASM diretamente no L1, ficando mais perto do modelo de transações nativo e das capacidades de protocolo. O primeiro reduz o custo de migração; o segundo preserva a capacidade de diferenciação. Um resolve “os desenvolvedores vão vir?”, o outro resolve “quando vierem, será que dá para fazer coisas ‘sujas’ que um EVM comum não conseguiria?”.
Mas os dois caminhos também criam novos custos. Como os ativos atravessam camadas, onde a mesma aplicação armazena o estado, e como aplicações EVM se integram ao fluxo sigiloso do Hedger — nada disso se completa automaticamente só porque está escrito “modular”. O guia oficial de ponte intercamadas do DuskEVM atualmente deixa claro apenas o processo em testnet; saques ainda exigem três ações on-chain — iniciar, provar e confirmação final — não dá para antecipar um diagrama de arquitetura como se fosse uma experiência sem atrito na mainnet.
Ao pontuar o roteiro multicamadas de #dusk , eu não vou só contar quantas linguagens são suportadas; vou observar em que camada a aplicação realmente vai rodar, como recuperar quando falhas ocorrerem ao atravessar camadas e se os recursos de privacidade são chamáveis diretamente por desenvolvedores. A nova chain deve primeiro usar EVM para ganhar velocidade de ecossistema, ou primeiro preservar a integridade das tecnologias nativas?
O DuskEVM segue a linha do OP Stack: a execução e as ferramentas são o mais próximas possível do ecossistema Ethereum; e a liquidação e a publicação de dados ficam a cargo do DuskDS, mantendo $DUSK como “gas”. Já o DuskVM roda contratos WASM diretamente no L1, ficando mais perto do modelo de transações nativo e das capacidades de protocolo. O primeiro reduz o custo de migração; o segundo preserva a capacidade de diferenciação. Um resolve “os desenvolvedores vão vir?”, o outro resolve “quando vierem, será que dá para fazer coisas ‘sujas’ que um EVM comum não conseguiria?”.
Mas os dois caminhos também criam novos custos. Como os ativos atravessam camadas, onde a mesma aplicação armazena o estado, e como aplicações EVM se integram ao fluxo sigiloso do Hedger — nada disso se completa automaticamente só porque está escrito “modular”. O guia oficial de ponte intercamadas do DuskEVM atualmente deixa claro apenas o processo em testnet; saques ainda exigem três ações on-chain — iniciar, provar e confirmação final — não dá para antecipar um diagrama de arquitetura como se fosse uma experiência sem atrito na mainnet.
Ao pontuar o roteiro multicamadas de #dusk , eu não vou só contar quantas linguagens são suportadas; vou observar em que camada a aplicação realmente vai rodar, como recuperar quando falhas ocorrerem ao atravessar camadas e se os recursos de privacidade são chamáveis diretamente por desenvolvedores. A nova chain deve primeiro usar EVM para ganhar velocidade de ecossistema, ou primeiro preservar a integridade das tecnologias nativas?
