Algo na documentação me interrompeu hoje no meio do scroll.
Dusk Network, $DUSK , #dusk , @Dusk — o ângulo de compatibilidade com EVM é como a maioria das pessoas encontra este projeto. Portar seus contratos em Solidity, usar ferramentas familiares, carteiras EVM existentes. O repositório duskevm-genesis no GitHub foi atualizado pela última vez em 8 de agosto, mostrando trabalho ativo de configuração de rollup. Então a engrenagem está rodando. Mas a coisa mais profunda que eu não consegui ignorar está justamente nos próprios documentos de arquitetura, escondida em uma única linha: "A inclusão de transações é rápida, mas inclusão e liquidação são estágios diferentes."
Esse é o recado. DuskEVM roda no OP Stack — essencialmente op-geth como sequenciador, agregando dados de transações de volta para o DuskDS como blobs. Comportamento padrão de rollup. Mas o DuskDS, o propósito real por baixo — liquidação determinística, contratos inteligentes ZK, privacidade nativa — é um ambiente de execução totalmente separado. A documentação é explícita: construa em DuskEVM para Solidity e ferramentas familiares, ou construa nativamente no DuskDS com Rust e WASM para privacidade real no nível de protocolo e lógica de mercado customizada. Dois caminhos. Não é uma coisa unificada.
hmm… Passei tempo demais assumindo que a compatibilidade com EVM aqui significava que o código Solidity herdaria automaticamente a infraestrutura financeira do Dusk. Não herda. A ponte entre essas duas camadas é intencional e opcional, não automática.
Isso me faz pensar — quantos desenvolvedores migrando para o DuskEVM realmente vão voltar e re-arquitetar para o DuskDS quando perceberem o que deixaram de lado?
Dusk Network, $DUSK , #dusk , @Dusk — o ângulo de compatibilidade com EVM é como a maioria das pessoas encontra este projeto. Portar seus contratos em Solidity, usar ferramentas familiares, carteiras EVM existentes. O repositório duskevm-genesis no GitHub foi atualizado pela última vez em 8 de agosto, mostrando trabalho ativo de configuração de rollup. Então a engrenagem está rodando. Mas a coisa mais profunda que eu não consegui ignorar está justamente nos próprios documentos de arquitetura, escondida em uma única linha: "A inclusão de transações é rápida, mas inclusão e liquidação são estágios diferentes."
Esse é o recado. DuskEVM roda no OP Stack — essencialmente op-geth como sequenciador, agregando dados de transações de volta para o DuskDS como blobs. Comportamento padrão de rollup. Mas o DuskDS, o propósito real por baixo — liquidação determinística, contratos inteligentes ZK, privacidade nativa — é um ambiente de execução totalmente separado. A documentação é explícita: construa em DuskEVM para Solidity e ferramentas familiares, ou construa nativamente no DuskDS com Rust e WASM para privacidade real no nível de protocolo e lógica de mercado customizada. Dois caminhos. Não é uma coisa unificada.
hmm… Passei tempo demais assumindo que a compatibilidade com EVM aqui significava que o código Solidity herdaria automaticamente a infraestrutura financeira do Dusk. Não herda. A ponte entre essas duas camadas é intencional e opcional, não automática.
Isso me faz pensar — quantos desenvolvedores migrando para o DuskEVM realmente vão voltar e re-arquitetar para o DuskDS quando perceberem o que deixaram de lado?
