Achei que DuskVM e DuskEVM eram, basicamente, duas formas de construir a mesma coisa.
Depois passei algum tempo olhando para os caminhos reais de desenvolvimento e não é bem assim.
Se você constrói através do DuskVM, fica muito mais perto do @Dusk lado nativo. Contratos são escritos em Rust, compilados para WASM e executados diretamente na L1. Isso te dá acesso aos próprios modelos de transação da Dusk e a recursos de privacidade/ZK em nível mais baixo.
O DuskEVM parece o oposto dessa troca.
Você ganha Solidity, Foundry, Hardhat e carteiras EVM normais.. basicamente as ferramentas que desenvolvedores Ethereum já conhecem. Mas a execução ainda volta para ser liquidada via DuskDS.
O ponto que fez sentido para mim foi que isso não está realmente pedindo que os builders escolham a VM “melhor”.
Está perguntando do que a aplicação realmente precisa.
Se eu precisar de controle direto da L1, lógica nativa de privacidade ou execução em nível de protocolo, o DuskVM faz mais sentido.
Se eu já tenho um app EVM e só quero uma forma familiar de entrar na stack da Dusk, forçar uma reescrita em Rust seria uma fricção desnecessária.
Então sim, duas opções de ambiente de execução pareceram redundantes para mim no começo.
Agora parece mais que a Dusk está tentando evitar que compatibilidade com desenvolvedores e controle nativo disputem entre si.
Mesmo ecossistema, pontos de entrada bem diferentes.
Estou curioso para saber qual lado os builders realmente vão escolher quando mais apps começarem a migrar.
$DUSK #dusk
Depois passei algum tempo olhando para os caminhos reais de desenvolvimento e não é bem assim.
Se você constrói através do DuskVM, fica muito mais perto do @Dusk lado nativo. Contratos são escritos em Rust, compilados para WASM e executados diretamente na L1. Isso te dá acesso aos próprios modelos de transação da Dusk e a recursos de privacidade/ZK em nível mais baixo.
O DuskEVM parece o oposto dessa troca.
Você ganha Solidity, Foundry, Hardhat e carteiras EVM normais.. basicamente as ferramentas que desenvolvedores Ethereum já conhecem. Mas a execução ainda volta para ser liquidada via DuskDS.
O ponto que fez sentido para mim foi que isso não está realmente pedindo que os builders escolham a VM “melhor”.
Está perguntando do que a aplicação realmente precisa.
Se eu precisar de controle direto da L1, lógica nativa de privacidade ou execução em nível de protocolo, o DuskVM faz mais sentido.
Se eu já tenho um app EVM e só quero uma forma familiar de entrar na stack da Dusk, forçar uma reescrita em Rust seria uma fricção desnecessária.
Então sim, duas opções de ambiente de execução pareceram redundantes para mim no começo.
Agora parece mais que a Dusk está tentando evitar que compatibilidade com desenvolvedores e controle nativo disputem entre si.
Mesmo ecossistema, pontos de entrada bem diferentes.
Estou curioso para saber qual lado os builders realmente vão escolher quando mais apps começarem a migrar.
$DUSK #dusk