Adicionar suporte a EVM geralmente é apresentado como um ganho de compatibilidade: mais carteiras, mais ferramentas e mais desenvolvedores Solidity. Mas esse enquadramento esconde uma questão arquitetural maior — a familiaridade do desenvolvedor deve também determinar onde um sistema financeiro se assenta?
A pilha atual da Dusk separa essas escolhas. DuskEVM fornece execução compatível com EVM, liquidada via DuskDS, enquanto DuskVM executa contratos Rust/WASM diretamente na L1. A DuskDS permanece a base de liquidação e disponibilidade de dados. Isso faz com que a compatibilidade com EVM seja uma opção de execução, e não a definição da camada base.
A implicação é mais interessante do que “a Dusk oferece duas VMs”. Um aplicativo regulado pode escolher ferramentas EVM familiares sem exigir que a camada de liquidação precise se tornar moldada por EVM.
Enquanto isso, fluxos de trabalho que precisam de acesso direto à L1 aos modelos de transação da Dusk, capacidades de privacidade ou de zero conhecimento podem permanecer nativos.
O trade-off é a coordenação. Dois caminhos de execução não tornam suas capacidades idênticas, e os criadores ainda precisam decidir quais garantias pertencem à execução e quais devem ser ancoradas na liquidação.
Assim, o verdadeiro teste de modularidade não é em quantos ambientes a Dusk oferece suporte. É se a execução pode variar sem fragmentar as premissas de liquidação sob elas.
@Dusk_Foundation $DUSK #dusk $BTW $ROBO
A pilha atual da Dusk separa essas escolhas. DuskEVM fornece execução compatível com EVM, liquidada via DuskDS, enquanto DuskVM executa contratos Rust/WASM diretamente na L1. A DuskDS permanece a base de liquidação e disponibilidade de dados. Isso faz com que a compatibilidade com EVM seja uma opção de execução, e não a definição da camada base.
A implicação é mais interessante do que “a Dusk oferece duas VMs”. Um aplicativo regulado pode escolher ferramentas EVM familiares sem exigir que a camada de liquidação precise se tornar moldada por EVM.
Enquanto isso, fluxos de trabalho que precisam de acesso direto à L1 aos modelos de transação da Dusk, capacidades de privacidade ou de zero conhecimento podem permanecer nativos.
O trade-off é a coordenação. Dois caminhos de execução não tornam suas capacidades idênticas, e os criadores ainda precisam decidir quais garantias pertencem à execução e quais devem ser ancoradas na liquidação.
Assim, o verdadeiro teste de modularidade não é em quantos ambientes a Dusk oferece suporte. É se a execução pode variar sem fragmentar as premissas de liquidação sob elas.
@Dusk_Foundation $DUSK #dusk $BTW $ROBO