#dusk $DUSK
Nestes dois dias, reli mais uma vez a documentação de arquitetura de @Dusk , e há uma questão que, na verdade, eu tinha simplificado demais lá atrás.
No fim, o DuskEVM também volta para o settlement do DuskDS; então por que ainda manter o DuskVM separadamente?
No começo, eu achava que era só por causa da diferença de linguagem de desenvolvimento: um em Solidity, outro em Rust/WASM.
Mas, ao continuar lendo, a diferença real está no caminho de execução.
O DuskVM roda diretamente na L1.
O DuskEVM não. A transação primeiro passa pelo sequencer, é executada na camada EVM, e depois ainda há batch, state commitment, para então reconectar ao DuskDS.
Então, mesmo que no fim tudo chegue à mesma settlement layer, o que acontece no meio é totalmente diferente.
Acho que essa diferença é bem importante.
Se você já tem um produto em Solidity e quer migrar com poucas mudanças de código, então o DuskEVM faz muito sentido. As ferramentas e os hábitos de desenvolvimento já são, em grande parte, familiares.
Mas, se a aplicação precisa tocar diretamente a L1, ou usar a capacidade nativa de execução do Dusk e a lógica em nível de protocolo, talvez não seja necessário forçar o uso da camada EVM.
Por isso, agora eu já não fico muito preso à ideia de quem é “mais avançado” entre DuskEVM e DuskVM.
Parece mais duas rotas.
Uma facilita a entrada de desenvolvedores EVM já existentes.
A outra fica para quem, desde o início, quer usar diretamente as capacidades Dusk-native.
No fim, ambas conseguem se conectar ao DuskDS, mas o execution path não é a mesma coisa.
É também por isso que acho a arquitetura do Dusk mais interessante de estudar do que “apenas mais uma L1 compatível com EVM”.
Nestes dois dias, reli mais uma vez a documentação de arquitetura de @Dusk , e há uma questão que, na verdade, eu tinha simplificado demais lá atrás.
No fim, o DuskEVM também volta para o settlement do DuskDS; então por que ainda manter o DuskVM separadamente?
No começo, eu achava que era só por causa da diferença de linguagem de desenvolvimento: um em Solidity, outro em Rust/WASM.
Mas, ao continuar lendo, a diferença real está no caminho de execução.
O DuskVM roda diretamente na L1.
O DuskEVM não. A transação primeiro passa pelo sequencer, é executada na camada EVM, e depois ainda há batch, state commitment, para então reconectar ao DuskDS.
Então, mesmo que no fim tudo chegue à mesma settlement layer, o que acontece no meio é totalmente diferente.
Acho que essa diferença é bem importante.
Se você já tem um produto em Solidity e quer migrar com poucas mudanças de código, então o DuskEVM faz muito sentido. As ferramentas e os hábitos de desenvolvimento já são, em grande parte, familiares.
Mas, se a aplicação precisa tocar diretamente a L1, ou usar a capacidade nativa de execução do Dusk e a lógica em nível de protocolo, talvez não seja necessário forçar o uso da camada EVM.
Por isso, agora eu já não fico muito preso à ideia de quem é “mais avançado” entre DuskEVM e DuskVM.
Parece mais duas rotas.
Uma facilita a entrada de desenvolvedores EVM já existentes.
A outra fica para quem, desde o início, quer usar diretamente as capacidades Dusk-native.
No fim, ambas conseguem se conectar ao DuskDS, mas o execution path não é a mesma coisa.
É também por isso que acho a arquitetura do Dusk mais interessante de estudar do que “apenas mais uma L1 compatível com EVM”.