Antes eu achava que, quanto mais ambientes de execução uma blockchain pública colocasse, no máximo seria só mais uma alternativa para os desenvolvedores. Mas depois que a arquitetura do @Dusk foi desmembrada, percebi que a relação entre o DuskVM e o DuskEVM não é tão simples: eles se parecem mais com dois portais voltados para necessidades diferentes.$DUSK
O DuskVM roda diretamente no Dusk L1, usando Rust/WASM; é adequado para chamar ativos nativos, recursos de privacidade e capacidades de ZK. Já o DuskEVM funciona mais como uma ponte de migração, permitindo que desenvolvedores Solidity continuem usando carteiras, frameworks e ferramentas de teste com as quais já estão familiarizados. No final, os resultados de ambos os lados são encaminhados para o DuskDS, que fica responsável pela liquidação.#dusk
Isso significa que o papel do DuskEVM não é apenas reduzir a barreira de migração. Por exemplo: um aplicativo financeiro comum que queira primeiro integrar uma cadeia de ferramentas EVM madura pode começar pelo DuskEVM; porém, se o que você está construindo envolve títulos privados, transferências de ativos controlados, ou precisa acionar recursos nativos confidenciais do Dusk, não dá para ficar somente no nível EVM — muitas lógicas ainda precisam do DuskVM.
Aí surge a questão. Suponha que um aplicativo precise tanto integrar contratos Solidity quanto lidar com ativos nativos de privacidade do Dusk: onde fica o estado central? Como sincronizar entre os dois ambientes? Quem valida as chamadas entre camadas? Se algo der errado, o desenvolvedor vai precisar investigar se é um problema do contrato, do ambiente de execução ou da camada de liquidação?$BTC
Por isso, hoje eu vejo o modelo de múltiplos ambientes de execução da Dusk não como algo que eu deva entender apenas como uma vantagem de compatibilidade. Por um lado, ele permite que mais desenvolvedores entrem; por outro, ele transfere para a equipe de desenvolvimento as dificuldades de design do sistema. O que realmente vale a pena observar não é quantas formas de execução a Dusk oferece, e sim se esses ambientes conseguem estabelecer fronteiras claras entre si — para que os desenvolvedores façam menos escolhas inúteis —, em vez de, para conseguir chamar capacidades diferentes ao mesmo tempo, empilhar a arquitetura do aplicativo cada vez mais complexa.$ETH
O DuskVM roda diretamente no Dusk L1, usando Rust/WASM; é adequado para chamar ativos nativos, recursos de privacidade e capacidades de ZK. Já o DuskEVM funciona mais como uma ponte de migração, permitindo que desenvolvedores Solidity continuem usando carteiras, frameworks e ferramentas de teste com as quais já estão familiarizados. No final, os resultados de ambos os lados são encaminhados para o DuskDS, que fica responsável pela liquidação.#dusk
Isso significa que o papel do DuskEVM não é apenas reduzir a barreira de migração. Por exemplo: um aplicativo financeiro comum que queira primeiro integrar uma cadeia de ferramentas EVM madura pode começar pelo DuskEVM; porém, se o que você está construindo envolve títulos privados, transferências de ativos controlados, ou precisa acionar recursos nativos confidenciais do Dusk, não dá para ficar somente no nível EVM — muitas lógicas ainda precisam do DuskVM.
Aí surge a questão. Suponha que um aplicativo precise tanto integrar contratos Solidity quanto lidar com ativos nativos de privacidade do Dusk: onde fica o estado central? Como sincronizar entre os dois ambientes? Quem valida as chamadas entre camadas? Se algo der errado, o desenvolvedor vai precisar investigar se é um problema do contrato, do ambiente de execução ou da camada de liquidação?$BTC
Por isso, hoje eu vejo o modelo de múltiplos ambientes de execução da Dusk não como algo que eu deva entender apenas como uma vantagem de compatibilidade. Por um lado, ele permite que mais desenvolvedores entrem; por outro, ele transfere para a equipe de desenvolvimento as dificuldades de design do sistema. O que realmente vale a pena observar não é quantas formas de execução a Dusk oferece, e sim se esses ambientes conseguem estabelecer fronteiras claras entre si — para que os desenvolvedores façam menos escolhas inúteis —, em vez de, para conseguir chamar capacidades diferentes ao mesmo tempo, empilhar a arquitetura do aplicativo cada vez mais complexa.$ETH