Ontem à noite, quando eu folheei os documentos da Dusk, só então percebi que vinha entendendo “suporte a EVM” de um jeito simplista demais. A Dusk não coloca todo o contrato dentro de uma única máquina virtual: os aplicativos familiarizados com Solidity e Foundry podem seguir pelo DuskEVM, pagando o Gas com DUSK; os dados em lote e as garantias de estado ficam a cargo do DuskDS para a liquidação. Já quando são necessários recursos nativos de privacidade e capacidades de zero conhecimento, ou contratos com controle de ativos em nível de protocolo, então eles rodam diretamente no DuskVM usando Rust/WASM.

Eu passei a entender isso como dois painéis operacionais abertos pela mesma empresa de intermediação. Um mantém os botões familiares, para migrar mais rápido; o outro fica mais próximo do cofre de nível mais baixo, permitindo chamar regras mais nativas. No fim, os dois retornam à mesma base de liquidação para confirmar os registros. Essa escolha é mais crucial do que apenas “compatibilidade com EVM”, porque separa a eficiência de desenvolvimento das capacidades nativas.

Mas ter dois caminhos também aumenta a complexidade da ponte e das interações entre camadas, além de exigir uma avaliação precisa do estado. A documentação oficial deixa claro que o empacotamento rápido do DuskEVM não significa que a liquidação no DuskDS já tenha sido concluída; eu não vou apenas olhar a exibição na página e considerar como se tivesse terminado de fato. Depois, preciso observar se a experiência entre camadas é fluida, se as ferramentas amadurecem e se a quantidade real de contratos cresce. A arquitetura dá as opções; a adoção é que vai trazer a resposta.

@Dusk $DUSK #dusk