Enterrado na própria documentação do DuskEVM está um detalhe que muda a forma como eu penso na pergunta “qual camada é construída para quê”: atualmente, o DuskEVM roda sem mempool pública — apenas o sequenciador.
Isso é uma escolha arquitetural de verdade, não um erro de arredondamento. Em quase todas as cadeias EVM, transações pendentes ficam em um mempool visível antes da inclusão, e é exatamente essa superfície que bots MEV e frontrunners exploram. O DuskEVM ignora isso totalmente: executa através de um único sequenciador e, depois, publica os dados em lotes de volta para o DuskDS para liquidação e disponibilidade. O DuskVM, por outro lado, executa diretamente os contratos nativos em Rust/WASM do Dusk contra os modelos de transação do Phoenix/Moonlight — sem ferramentas EVM, mas com privacidade nativa, e não “adicionada por fora”.
O que me puxou para aprofundar: o incidente da ponte em 16 de agosto. Uma carteira gerenciada pela equipe usada para operações de bridge foi sinalizada, os endereços foram desativados e os serviços de bridge foram pausados — a mesma ponte que move DUSK entre DuskDS e DuskEVM para o gás. É um lembrete de que a camada conectiva entre essas duas VMs ainda é uma dependência operacional, e não uma transição totalmente imposta pelo protocolo.
O que eu não consigo confirmar: contagens reais de transações do testnet do DuskEVM ou volume de implantação de contratos nesta semana — as estatísticas do Blockscout não retornaram sem uma sessão renderizada em JS, então estou me baseando na arquitetura documentada, não na vazão ao vivo.
Qual camada os builders estão escolhendo agora, e por quê?
@Dusk_Foundation $DUSK #dusk
Isso é uma escolha arquitetural de verdade, não um erro de arredondamento. Em quase todas as cadeias EVM, transações pendentes ficam em um mempool visível antes da inclusão, e é exatamente essa superfície que bots MEV e frontrunners exploram. O DuskEVM ignora isso totalmente: executa através de um único sequenciador e, depois, publica os dados em lotes de volta para o DuskDS para liquidação e disponibilidade. O DuskVM, por outro lado, executa diretamente os contratos nativos em Rust/WASM do Dusk contra os modelos de transação do Phoenix/Moonlight — sem ferramentas EVM, mas com privacidade nativa, e não “adicionada por fora”.
O que me puxou para aprofundar: o incidente da ponte em 16 de agosto. Uma carteira gerenciada pela equipe usada para operações de bridge foi sinalizada, os endereços foram desativados e os serviços de bridge foram pausados — a mesma ponte que move DUSK entre DuskDS e DuskEVM para o gás. É um lembrete de que a camada conectiva entre essas duas VMs ainda é uma dependência operacional, e não uma transição totalmente imposta pelo protocolo.
O que eu não consigo confirmar: contagens reais de transações do testnet do DuskEVM ou volume de implantação de contratos nesta semana — as estatísticas do Blockscout não retornaram sem uma sessão renderizada em JS, então estou me baseando na arquitetura documentada, não na vazão ao vivo.
Qual camada os builders estão escolhendo agora, e por quê?
@Dusk_Foundation $DUSK #dusk