#dusk $DUSK @Dusk
A pilha inteira da Dusk é construída de forma modular. DuskDS é a camada de settlement e disponibilidade de dados — ela executa o consenso de Succinct Attestation, faz o staking e mantém o ativo base DUSK. DuskEVM é uma camada de execução separada, compatível com Solidity, construída sobre o OP Stack (um sequenciador executando op-geth, além de um batcher que publica os dados das transações de volta ao DuskDS como blobs). Em seguida, ela faz o settlement de volta no DuskDS, em vez de depender de sua própria segurança independente. DuskVM é um ambiente nativo de execução ainda mais, porém em evolução, para contratos em Rust/WASM, voltado a aplicações que precisam de privacidade nativa ou de integração em nível de protocolo. Piecrust é o runtime WASM (construído sobre Wasmer) que originalmente foi embutido no DuskDS e agora está sendo extraído para o DuskVM. A rede roda no Kadcast — um protocolo de broadcast estruturado, no estilo de Kademlia, em vez de um gossip aleatório.
A lógica por trás dessa arquitetura é que "um único ambiente de execução para tudo" não funciona para uma cadeia que precisa atender, ao mesmo tempo, composabilidade estilo DeFi e emissão de ativos regulamentados. Em vez de forçar desenvolvedores Solidity a migrarem para um ambiente nativo Rust/WASM, ou forçar aplicações nativas de privacidade às restrições da EVM, settlement e consenso ficam sobre uma camada base compartilhada, enquanto ambientes de execução se especializam acima dela. O Kadcast se encaixa na mesma lógica — broadcast estruturado significa mais previsibilidade de largura de banda e latência, o que importa mais para uma cadeia que reivindica finalização determinística do que para uma que trata a finalização de forma probabilística.
Separar execução de settlement também significa que as garantias do DuskEVM são tão fortes quanto forem a bridge e o mecanismo de batching que o conectam de volta ao DuskDS. Conforme o DuskVM amadurece junto com o DuskEVM, a rede acaba rodando três superfícies de execução sobre uma única camada de settlement. Essa separação realmente reduz o atrito de integração para desenvolvedores, ou apenas desloca a complexidade de "qual VM eu uso" para "qual camada realmente mantém minha garantia"?
A pilha inteira da Dusk é construída de forma modular. DuskDS é a camada de settlement e disponibilidade de dados — ela executa o consenso de Succinct Attestation, faz o staking e mantém o ativo base DUSK. DuskEVM é uma camada de execução separada, compatível com Solidity, construída sobre o OP Stack (um sequenciador executando op-geth, além de um batcher que publica os dados das transações de volta ao DuskDS como blobs). Em seguida, ela faz o settlement de volta no DuskDS, em vez de depender de sua própria segurança independente. DuskVM é um ambiente nativo de execução ainda mais, porém em evolução, para contratos em Rust/WASM, voltado a aplicações que precisam de privacidade nativa ou de integração em nível de protocolo. Piecrust é o runtime WASM (construído sobre Wasmer) que originalmente foi embutido no DuskDS e agora está sendo extraído para o DuskVM. A rede roda no Kadcast — um protocolo de broadcast estruturado, no estilo de Kademlia, em vez de um gossip aleatório.
A lógica por trás dessa arquitetura é que "um único ambiente de execução para tudo" não funciona para uma cadeia que precisa atender, ao mesmo tempo, composabilidade estilo DeFi e emissão de ativos regulamentados. Em vez de forçar desenvolvedores Solidity a migrarem para um ambiente nativo Rust/WASM, ou forçar aplicações nativas de privacidade às restrições da EVM, settlement e consenso ficam sobre uma camada base compartilhada, enquanto ambientes de execução se especializam acima dela. O Kadcast se encaixa na mesma lógica — broadcast estruturado significa mais previsibilidade de largura de banda e latência, o que importa mais para uma cadeia que reivindica finalização determinística do que para uma que trata a finalização de forma probabilística.
Separar execução de settlement também significa que as garantias do DuskEVM são tão fortes quanto forem a bridge e o mecanismo de batching que o conectam de volta ao DuskDS. Conforme o DuskVM amadurece junto com o DuskEVM, a rede acaba rodando três superfícies de execução sobre uma única camada de settlement. Essa separação realmente reduz o atrito de integração para desenvolvedores, ou apenas desloca a complexidade de "qual VM eu uso" para "qual camada realmente mantém minha garantia"?