Quando vi pela primeira vez o diagrama da arquitetura do DUSK, fiquei com uma dúvida: por que são necessários dois ambientes virtuais? O DuskVM executa contratos nativos, enquanto o DuskEVM executa contratos compatíveis com o Ethereum — isso não aumenta a complexidade? Mas, ao me aprofundar, percebi que esse design na verdade existe para resolver um problema bem real: a troca entre segurança e desempenho.
O DuskVM é a máquina virtual nativa do DUSK; ele roda diretamente sobre a camada de consenso e consegue acessar todas as funcionalidades de base, como provas de conhecimento zero, transações de privacidade, o protocolo Phoenix e outros recursos. Já o DuskEVM é baseado no OP Stack: ele executa contratos inteligentes do Ethereum, mas a liquidação final é feita pelo DuskDS. A diferença-chave é que, no DuskVM, os contratos ficam vinculados diretamente à segurança do consenso do DUSK; enquanto no DuskEVM, os contratos dependem de uma camada de ponte externa.
Isso gera uma divisão bem interessante: ativos sensíveis (por exemplo, tokens de RWA, ativos de conformidade) devem ficar no DuskVM, porque eles precisam aproveitar diretamente os recursos de privacidade e conformidade do DUSK; enquanto aplicações DeFi comuns (por exemplo, exchanges descentralizadas, protocolos de empréstimo) podem ficar no DuskEVM, porque os desenvolvedores só precisam migrar o código existente do Ethereum, evitando o trabalho de reescrever contratos.
Eu consultei o feedback de desenvolvedores: no DuskEVM, implantar um clone do Uniswap V2 requer apenas a modificação de cerca de 20 linhas de código (principalmente para adaptar parâmetros de rede). Já, para desenvolver do zero no DuskVM, seriam necessárias centenas de linhas. Além disso, as transações no DuskVM são mais rápidas (em média, 1,5 segundo por bloco) e não exigem o pagamento de taxas de ponte. No fim, isso é uma escolha entre “eficiência de desenvolvimento vs. desempenho”.
Outro ponto que vale observar é o isolamento de segurança. Os dados do DuskVM e do DuskEVM são separados fisicamente, e os contratos do DuskEVM não conseguem acessar diretamente o estado de privacidade do DuskVM. Isso evita ataques do tipo “flash loan” explorando vulnerabilidades de acesso entre camadas. Na auditoria de segurança do DUSK em setembro de 2025, eles testaram com foco as chamadas entre VMs e constataram que todas as chamadas precisam passar por um “gateway de sandbox”; esse gateway verifica as permissões e o tipo do chamador, impedindo que códigos maliciosos se infiltrem. $BTC
Mas eu acho que essa arquitetura dupla também traz riscos potenciais: se houver vulnerabilidades na lógica de ponte entre as duas VMs, elas podem ser exploradas. Por exemplo, um atacante poderia falsificar uma chamada de um contrato do DuskEVM para consumir recursos do DuskVM.
#dusk @Dusk $DUSK