A verdadeira vantagem do modelo de execução dual da Dusk não é compatibilidade com EVM. É uma escolha arquitetural.
@Dusk separa liquidação de execução: contratos DuskVM executam Rust/WASM diretamente na Dusk L1, enquanto DuskEVM fornece execução compatível com EVM com liquidação e disponibilidade de dados via DuskDS.
A consequência mais profunda é que os desenvolvedores podem escolher onde a lógica da aplicação deve residir, em vez de forçar todo tipo de carga a caber em um único modelo de execução.
Se um contrato precisa de acesso direto à L1 aos modelos de transação da Dusk, recursos de privacidade ou capacidades de zero-knowledge, DuskVM é o caminho nativo. Se a prioridade é Solidity, carteiras existentes e as ferramentas do ecossistema Ethereum, DuskEVM reduz a barreira de migração. A Dusk apresenta explicitamente esses dois caminhos como escolhas com base nos requisitos da aplicação.
Mas essa flexibilidade levanta uma questão arquitetural que considero mais interessante do que compatibilidade:
Onde deve residir um invariante?
Na minha visão, regras vinculadas apenas a um ambiente de execução podem permanecer locais nesse ambiente. Regras que atravessam caminhos de execução ou dependem de liquidação precisam de uma atribuição explícita de responsabilidade e de limites claros de coordenação.
Essa distinção importa porque as camadas da Dusk não são intercambiáveis. DuskDS fornece consenso, finalização, liquidação e disponibilidade de dados, enquanto DuskVM e DuskEVM fornecem ambientes de execução diferentes.
A ponte torna esse limite concreto. No fluxo documentado de saque do DuskEVM Testnet, um saque é iniciado no DuskEVM, depois é provado e finalizado na Dusk L1. O fluxo, portanto, atravessa camadas de execução em vez de se comportar como uma operação monolítica.
Minha conclusão é que modularidade não apenas reduz complexidade. Ela permite que os desenvolvedores decidam onde essa complexidade deve residir.
Para aplicações financeiras, isso pode ser uma vantagem arquitetural relevante: manter lógica específica de execução local, tratando regras entre camadas como restrições arquiteturais explícitas.
Quais regras devem permanecer dentro de um ambiente de execução e quais são importantes o suficiente para serem impostas em toda a arquitetura?
$DUSK #dusk
@Dusk separa liquidação de execução: contratos DuskVM executam Rust/WASM diretamente na Dusk L1, enquanto DuskEVM fornece execução compatível com EVM com liquidação e disponibilidade de dados via DuskDS.
A consequência mais profunda é que os desenvolvedores podem escolher onde a lógica da aplicação deve residir, em vez de forçar todo tipo de carga a caber em um único modelo de execução.
Se um contrato precisa de acesso direto à L1 aos modelos de transação da Dusk, recursos de privacidade ou capacidades de zero-knowledge, DuskVM é o caminho nativo. Se a prioridade é Solidity, carteiras existentes e as ferramentas do ecossistema Ethereum, DuskEVM reduz a barreira de migração. A Dusk apresenta explicitamente esses dois caminhos como escolhas com base nos requisitos da aplicação.
Mas essa flexibilidade levanta uma questão arquitetural que considero mais interessante do que compatibilidade:
Onde deve residir um invariante?
Na minha visão, regras vinculadas apenas a um ambiente de execução podem permanecer locais nesse ambiente. Regras que atravessam caminhos de execução ou dependem de liquidação precisam de uma atribuição explícita de responsabilidade e de limites claros de coordenação.
Essa distinção importa porque as camadas da Dusk não são intercambiáveis. DuskDS fornece consenso, finalização, liquidação e disponibilidade de dados, enquanto DuskVM e DuskEVM fornecem ambientes de execução diferentes.
A ponte torna esse limite concreto. No fluxo documentado de saque do DuskEVM Testnet, um saque é iniciado no DuskEVM, depois é provado e finalizado na Dusk L1. O fluxo, portanto, atravessa camadas de execução em vez de se comportar como uma operação monolítica.
Minha conclusão é que modularidade não apenas reduz complexidade. Ela permite que os desenvolvedores decidam onde essa complexidade deve residir.
Para aplicações financeiras, isso pode ser uma vantagem arquitetural relevante: manter lógica específica de execução local, tratando regras entre camadas como restrições arquiteturais explícitas.
Quais regras devem permanecer dentro de um ambiente de execução e quais são importantes o suficiente para serem impostas em toda a arquitetura?
$DUSK #dusk
