Quando uma blockchain pública adiciona compatibilidade EVM, eu normalmente presumo que o ambiente de execução nativo vai perdendo prioridade gradualmente. As ferramentas de EVM atraem mais desenvolvedores, Solidity vira o padrão e um runtime nativo separado começa a parecer uma sobrecarga de manutenção que é discretamente despriorizada.
Mas a arquitetura atualizada de @Dusk evita deliberadamente esse padrão.
Agora, o DuskDS cuida do settlement e da disponibilidade de dados na base, o DuskEVM executa aplicações compatíveis com EVM e o DuskVM permanece na L1 especificamente para contratos em Rust e WASM que precisam de acesso direto à privacidade nativa e a funcionalidades de ZK.
Eu inicialmente interpretei isso como duplicação desnecessária, mas acho que é o oposto: está tratando a integração de desenvolvedores e a capacidade do protocolo como dois problemas distintos que não devem ser forçados a ficar no mesmo lugar.
O DuskEVM lida com a parte de onboarding. Contratos Solidity, carteiras existentes e ferramentas do ecossistema Ethereum funcionam aqui sem modificação. O DuskVM lida com algo diferente: quando uma aplicação precisa do modelo nativo de transação da Dusk, de recursos de confidencialidade ou de provas de ZK, ela não precisa traduzir tudo isso para código compatível com EVM. A documentação oficial posiciona o DuskVM como um ambiente de execução WASM rodando nativamente na L1 da Dusk.
Isso me ajudou a repensar o que #dusk está realmente construindo.
Não é apenas separar a cadeia em camadas. É reconhecer algo mais específico: o EVM é uma porta de entrada eficaz para a adoção por desenvolvedores, mas talvez não seja o lugar certo para carregar capacidades que são destinadas a ser nativas do próprio protocolo.
O que realmente vale a pena observar não é se $DUSK consegue operar dois ambientes de execução ao mesmo tempo, mas se os desenvolvedores vão, de fato, escolher caminhos diferentes com base no que precisam.
Se a maior parte do desenvolvimento continuar no EVM, o DuskVM vira uma capacidade que existe, mas é pouco usada. Se aplicações nativas de privacidade e protocolos financeiros começarem a rotear pelo caminho de execução nativo porque o EVM não consegue atender a esses requisitos, a complexidade de manter dois ambientes passa a ter algum valor.
Mas a arquitetura atualizada de @Dusk evita deliberadamente esse padrão.
Agora, o DuskDS cuida do settlement e da disponibilidade de dados na base, o DuskEVM executa aplicações compatíveis com EVM e o DuskVM permanece na L1 especificamente para contratos em Rust e WASM que precisam de acesso direto à privacidade nativa e a funcionalidades de ZK.
Eu inicialmente interpretei isso como duplicação desnecessária, mas acho que é o oposto: está tratando a integração de desenvolvedores e a capacidade do protocolo como dois problemas distintos que não devem ser forçados a ficar no mesmo lugar.
O DuskEVM lida com a parte de onboarding. Contratos Solidity, carteiras existentes e ferramentas do ecossistema Ethereum funcionam aqui sem modificação. O DuskVM lida com algo diferente: quando uma aplicação precisa do modelo nativo de transação da Dusk, de recursos de confidencialidade ou de provas de ZK, ela não precisa traduzir tudo isso para código compatível com EVM. A documentação oficial posiciona o DuskVM como um ambiente de execução WASM rodando nativamente na L1 da Dusk.
Isso me ajudou a repensar o que #dusk está realmente construindo.
Não é apenas separar a cadeia em camadas. É reconhecer algo mais específico: o EVM é uma porta de entrada eficaz para a adoção por desenvolvedores, mas talvez não seja o lugar certo para carregar capacidades que são destinadas a ser nativas do próprio protocolo.
O que realmente vale a pena observar não é se $DUSK consegue operar dois ambientes de execução ao mesmo tempo, mas se os desenvolvedores vão, de fato, escolher caminhos diferentes com base no que precisam.
Se a maior parte do desenvolvimento continuar no EVM, o DuskVM vira uma capacidade que existe, mas é pouco usada. Se aplicações nativas de privacidade e protocolos financeiros começarem a rotear pelo caminho de execução nativo porque o EVM não consegue atender a esses requisitos, a complexidade de manter dois ambientes passa a ter algum valor.
