Eu estava olhando a arquitetura do Dusk hoje, e uma coisa ficou mais clara depois de eu me aprofundar:
O Dusk não força cada desenvolvedor a trabalhar no mesmo ambiente de execução.
Em vez disso, ele separa settlement (assentamento) de execução.
Na base está o DuskDS, que lida com consenso, finalização e disponibilidade de dados.
Depois, há dois caminhos diferentes por cima.
O DuskVM executa contratos Rust/WASM diretamente na Dusk L1.
O DuskEVM oferece um ambiente compatível com EVM para Solidity e Vyper, enquanto ainda faz o settlement através do DuskDS.
No começo, ter dois ambientes pareceu para mim uma complexidade desnecessária.
Mas o motivo ficou mais evidente.
Uma aplicação que precisa de acesso direto aos modelos nativos de transação do Dusk, recursos de privacidade ou de capacidades de zero conhecimento pode usar o DuskVM.
Uma equipe que já vive dentro do ecossistema de desenvolvimento Ethereum pode usar o DuskEVM, com ferramentas familiares e Solidity, em vez de reconstruir todo o fluxo de desenvolvimento.
Esse é um tipo de troca interessante.
O Dusk não está realmente pedindo que os desenvolvedores escolham entre infraestrutura nativa e compatibilidade com EVM.
Ele está tentando manter ambos, colocando o settlement por baixo deles.
A pergunta que ainda tenho é a mais importante:
Ter ambos os caminhos de execução vai realmente atrair tempo suficiente de builders diferentes para justificar a complexidade arquitetural adicionada?
Para mim, isso é algo mais interessante de observar do que simplesmente chamar o Dusk de “compatível com EVM”.
#dusk $DUSK @Dusk
O Dusk não força cada desenvolvedor a trabalhar no mesmo ambiente de execução.
Em vez disso, ele separa settlement (assentamento) de execução.
Na base está o DuskDS, que lida com consenso, finalização e disponibilidade de dados.
Depois, há dois caminhos diferentes por cima.
O DuskVM executa contratos Rust/WASM diretamente na Dusk L1.
O DuskEVM oferece um ambiente compatível com EVM para Solidity e Vyper, enquanto ainda faz o settlement através do DuskDS.
No começo, ter dois ambientes pareceu para mim uma complexidade desnecessária.
Mas o motivo ficou mais evidente.
Uma aplicação que precisa de acesso direto aos modelos nativos de transação do Dusk, recursos de privacidade ou de capacidades de zero conhecimento pode usar o DuskVM.
Uma equipe que já vive dentro do ecossistema de desenvolvimento Ethereum pode usar o DuskEVM, com ferramentas familiares e Solidity, em vez de reconstruir todo o fluxo de desenvolvimento.
Esse é um tipo de troca interessante.
O Dusk não está realmente pedindo que os desenvolvedores escolham entre infraestrutura nativa e compatibilidade com EVM.
Ele está tentando manter ambos, colocando o settlement por baixo deles.
A pergunta que ainda tenho é a mais importante:
Ter ambos os caminhos de execução vai realmente atrair tempo suficiente de builders diferentes para justificar a complexidade arquitetural adicionada?
Para mim, isso é algo mais interessante de observar do que simplesmente chamar o Dusk de “compatível com EVM”.
#dusk $DUSK @Dusk