#dusk $DUSK @Dusk
Há muitos projetos no mercado que se dizem compatíveis com ZK, mas, quando se aprofunda nos detalhes da camada de execução, percebe-se que a grande maioria é apenas um trabalho superficial: transforma o ZK em um patch adicional, em vez de incorporá-lo como capacidade nativa da base. Muita gente compara apenas o tempo de geração das provas do ZK, mas presta pouca atenção aos custos adicionais de gas quando se chama a lógica do ZK em contratos, nem às latências de chamada — esses custos implícitos embutidos no ambiente de execução é que, na prática, determinam se aplicações de finanças privadas conseguem escalar.
A rota mais comum das blockchains para lidar com validações ZK é a abordagem “外挂”: ou dependem de contratos pré-compilados, ou empurram toda a computação pesada de prova para fora da cadeia (off-chain). Esse caminho tem baixa barreira e sobe rápido, mas as deficiências são bem claras: a cada validação ZK, o contrato precisa iniciar uma chamada entre módulos; cada camada extra de interação acrescenta mais uma rodada de consumo de gas. Em testes, o custo adicional de gas por chamada frequentemente começa na casa de dezenas de milhares. Além disso, quando há congestionamento nos serviços off-chain, a latência para transmitir o resultado da prova de volta também trava diretamente os negócios on-chain. Os pontos de falha ficam distribuídos; quanto maior a cadeia de comunicação, maior a probabilidade de erro. Em essência, o ZK vira apenas um recurso “enfeite”, com prioridade menor do que a lógica base na cadeia.
A arquitetura de máquina virtual da Dusk segue exatamente o caminho oposto: em vez de ficar “por cima”, ela aprofunda diretamente toda a capacidade de validação criptográfica na base do runtime. Diversas lógicas de validação de provas de conhecimento zero, algoritmos de hash e componentes de assinaturas agregadas principais são encapsulados como funções nativas do hospedeiro. Assim, os contratos podem chamá-los diretamente, evitando o desperdício com saltos entre pré-compilações e idas e vindas de comunicação off-chain. Com a mesma lógica de validação ZK, o consumo de gas na camada de contrato pode ser reduzido em quase 30%, e a latência de chamada fica no nível de milissegundos.
Na base, não foi reaproveitado o modelo de memória do EVM; em vez disso, o layout de memória foi redesenhado sobre o WASM. O modelo nativo de memória do EVM é otimizado para contratos inteligentes comuns. Ao executar operações ZK com leituras e escritas frequentes, ele gera muitas cópias redundantes de memória. Em alguns cenários mais complexos de prova, o uso de memória pode disparar várias vezes. Já o WASM tem granularidade de memória mais flexível, capaz de se adaptar às características de ZK com muitos hashes em loop e operações polinomiais. O uso de memória pode cair até 40%, com melhora evidente de eficiência de execução.
Mais importante ainda é a integração ponta a ponta: a capacidade ZK não é um componente isolado. A interface do contrato e os primitivos de transações privadas na cadeia são integrados. Assim, validação de prova, transferência de ativos e lógica de privacidade podem fechar o ciclo inteiro na mesma trilha de transação, sem precisar “montar” com múltiplos sistemas.
Há muitos projetos no mercado que se dizem compatíveis com ZK, mas, quando se aprofunda nos detalhes da camada de execução, percebe-se que a grande maioria é apenas um trabalho superficial: transforma o ZK em um patch adicional, em vez de incorporá-lo como capacidade nativa da base. Muita gente compara apenas o tempo de geração das provas do ZK, mas presta pouca atenção aos custos adicionais de gas quando se chama a lógica do ZK em contratos, nem às latências de chamada — esses custos implícitos embutidos no ambiente de execução é que, na prática, determinam se aplicações de finanças privadas conseguem escalar.
A rota mais comum das blockchains para lidar com validações ZK é a abordagem “外挂”: ou dependem de contratos pré-compilados, ou empurram toda a computação pesada de prova para fora da cadeia (off-chain). Esse caminho tem baixa barreira e sobe rápido, mas as deficiências são bem claras: a cada validação ZK, o contrato precisa iniciar uma chamada entre módulos; cada camada extra de interação acrescenta mais uma rodada de consumo de gas. Em testes, o custo adicional de gas por chamada frequentemente começa na casa de dezenas de milhares. Além disso, quando há congestionamento nos serviços off-chain, a latência para transmitir o resultado da prova de volta também trava diretamente os negócios on-chain. Os pontos de falha ficam distribuídos; quanto maior a cadeia de comunicação, maior a probabilidade de erro. Em essência, o ZK vira apenas um recurso “enfeite”, com prioridade menor do que a lógica base na cadeia.
A arquitetura de máquina virtual da Dusk segue exatamente o caminho oposto: em vez de ficar “por cima”, ela aprofunda diretamente toda a capacidade de validação criptográfica na base do runtime. Diversas lógicas de validação de provas de conhecimento zero, algoritmos de hash e componentes de assinaturas agregadas principais são encapsulados como funções nativas do hospedeiro. Assim, os contratos podem chamá-los diretamente, evitando o desperdício com saltos entre pré-compilações e idas e vindas de comunicação off-chain. Com a mesma lógica de validação ZK, o consumo de gas na camada de contrato pode ser reduzido em quase 30%, e a latência de chamada fica no nível de milissegundos.
Na base, não foi reaproveitado o modelo de memória do EVM; em vez disso, o layout de memória foi redesenhado sobre o WASM. O modelo nativo de memória do EVM é otimizado para contratos inteligentes comuns. Ao executar operações ZK com leituras e escritas frequentes, ele gera muitas cópias redundantes de memória. Em alguns cenários mais complexos de prova, o uso de memória pode disparar várias vezes. Já o WASM tem granularidade de memória mais flexível, capaz de se adaptar às características de ZK com muitos hashes em loop e operações polinomiais. O uso de memória pode cair até 40%, com melhora evidente de eficiência de execução.
Mais importante ainda é a integração ponta a ponta: a capacidade ZK não é um componente isolado. A interface do contrato e os primitivos de transações privadas na cadeia são integrados. Assim, validação de prova, transferência de ativos e lógica de privacidade podem fechar o ciclo inteiro na mesma trilha de transação, sem precisar “montar” com múltiplos sistemas.