Ao rever a arquitetura do Dusk novamente hoje, notei um detalhe que é relativamente fácil de ignorar!

Por que ainda manter o DuskVM?

Afinal, agora já existe o DuskEVM, e desenvolvedores podem usar diretamente ferramentas mais maduras como Solidity, Vyper, Hardhat e Foundry. Para a maioria das aplicações, a compatibilidade com EVM por si só já é bem conveniente.

Mas o Dusk não desistiu, por isso, do ambiente de execução nativo.

O DuskVM é executado diretamente no Dusk L1 e é voltado principalmente para contratos Rust/WASM. Se uma aplicação precisar acessar diretamente ativos subjacentes, modelos de transação, capacidades de privacidade ou funções relacionadas a zero knowledge (provas de conhecimento zero), então o DuskVM na verdade oferece uma opção mais “de baixo nível”.

Acredito que aqui se evidencia uma escolha técnica bem clara feita pelo Dusk.

O DuskEVM resolve “como fazer com que mais desenvolvedores entrem”; já o DuskVM resolve “quando a aplicação realmente precisa de capacidades de base, ela consegue continuar avançando?”.

Essas duas direções não são conflitantes.

Para DeFi comum ou aplicações tokenizadas, o EVM talvez já seja suficiente; mas se no futuro o mercado financeiro exigir regras de ativos mais complexas, lógica de privacidade e necessidades de liquidação, os desenvolvedores vão precisar de algo além de apenas compatibilidade.

Então, olhando para o ambiente de execução duplo do Dusk agora, eu prefiro entendê-lo como um projeto de infraestrutura de longo prazo, e não simplesmente como a adição de mais um EVM.

O que realmente vale observar talvez seja quantas aplicações no futuro vão começar a precisar dessas capacidades de baixo nível fornecidas pelo DuskVM.#dusk $DUSK @Dusk
Você acha que o ambiente de execução duplo do Dusk é necessário?