#dusk $DUSK @Dusk
Eu rastreei como o DuskVM e o DuskEVM realmente dividem o trabalho no Dusk, já que ambos executam contratos, mas claramente não são intercambiáveis.
O DuskVM executa contratos em Rust/WASM, construídos sobre o Wasmtime, diretamente no L1 do Dusk. é o caminho preparado para contratos que precisam de acesso direto aos próprios modelos de transação do Dusk, recursos de privacidade ou capacidades de zero-knowledge — as funções de host amigáveis a ZK do Piecrust (PLONK, Groth16, BLS) vivem aqui especificamente.
O DuskEVM roda em algum outro lugar completamente. é um ambiente equivalente a EVM baseado no OP Stack — o ID de chain da testnet foi confirmado como 745 nas próprias docs do Dusk — permitindo que desenvolvedores implantem contratos Solidity padrão usando MetaMask, Hardhat ou Foundry, enquanto assentam e publicam dados de volta através do DuskDS como blobs, via um sequenciador e um batcher, em vez de rodarem de forma independente.
Eu isolei o que os separa além de apenas linguagem. contratos do DuskVM recebem privacidade e primitivas de ZK nativamente, na camada de execução. contratos do DuskEVM recebem compatibilidade total com as ferramentas e os usuários pagam gás em DUSK lá também, mas por meio de uma camada que assenta em outro lugar, em vez de rodar nativamente junto aos próprios modelos de transação do Dusk.
ambos assentam pelo mesmo base — DuskDS — e ambos, no fim, pagam gás em DUSK. nenhum substitui o outro; cada um existe porque o outro não consegue cobrir bem sua função específica.
então a escolha real para quem constrói não é "qual é melhor". é se o contrato precisa de execução com privacidade nativa ou de ferramentas familiares de EVM, verificáveis por ID de chain — e o Dusk criou duas pistas separadas em vez de forçar um único ambiente a fazer tudo.
manter dois ambientes de execução genuinamente separados ajuda mais os construtores do que escolher um e otimizá-lo totalmente?
Eu rastreei como o DuskVM e o DuskEVM realmente dividem o trabalho no Dusk, já que ambos executam contratos, mas claramente não são intercambiáveis.
O DuskVM executa contratos em Rust/WASM, construídos sobre o Wasmtime, diretamente no L1 do Dusk. é o caminho preparado para contratos que precisam de acesso direto aos próprios modelos de transação do Dusk, recursos de privacidade ou capacidades de zero-knowledge — as funções de host amigáveis a ZK do Piecrust (PLONK, Groth16, BLS) vivem aqui especificamente.
O DuskEVM roda em algum outro lugar completamente. é um ambiente equivalente a EVM baseado no OP Stack — o ID de chain da testnet foi confirmado como 745 nas próprias docs do Dusk — permitindo que desenvolvedores implantem contratos Solidity padrão usando MetaMask, Hardhat ou Foundry, enquanto assentam e publicam dados de volta através do DuskDS como blobs, via um sequenciador e um batcher, em vez de rodarem de forma independente.
Eu isolei o que os separa além de apenas linguagem. contratos do DuskVM recebem privacidade e primitivas de ZK nativamente, na camada de execução. contratos do DuskEVM recebem compatibilidade total com as ferramentas e os usuários pagam gás em DUSK lá também, mas por meio de uma camada que assenta em outro lugar, em vez de rodar nativamente junto aos próprios modelos de transação do Dusk.
ambos assentam pelo mesmo base — DuskDS — e ambos, no fim, pagam gás em DUSK. nenhum substitui o outro; cada um existe porque o outro não consegue cobrir bem sua função específica.
então a escolha real para quem constrói não é "qual é melhor". é se o contrato precisa de execução com privacidade nativa ou de ferramentas familiares de EVM, verificáveis por ID de chain — e o Dusk criou duas pistas separadas em vez de forçar um único ambiente a fazer tudo.
manter dois ambientes de execução genuinamente separados ajuda mais os construtores do que escolher um e otimizá-lo totalmente?
