Hoje em dia, os notebooks mexidos por IA estão absurdamente caros. Antes, o meu notebook travava demais e eu queria trocar por um novo, mas estava caro demais. Então pedi para alguém investigar a causa da lentidão. Ao checar, descobriu-se que era uma avalanche de softwares, cada um chamando funções do nível mais baixo do sistema, brigando entre si pelos mesmos recursos. O mestre teve uma ideia diferente: pegar as poucas operações que mais consomem recursos e transformá-las em aceleração por hardware, em vez de ficar simulando via software. A velocidade mudou imediatamente.
A VM do Dusk, o Piecrust, faz algo parecido. O código dos contratos inteligentes roda em uma sandbox WASM, buscando segurança e portabilidade, mas com o custo de ser lento — especialmente em operações criptográficas como hash, verificação de assinatura e provas de conhecimento zero, que têm um gasto alto ao serem executadas dentro da sandbox. A abordagem do Dusk é separar essas operações de alta frequência e transformá-las em "host functions", chamando diretamente o código nativo de baixo nível, sem ficar calculando pesado dentro do WASM.
As principais operações separadas são: hash com Blake2b e Poseidon; verificação com verify_plonk (prova PlonK), verify_groth16_bn254; e também verify_schnorr e verify_bls para verificação de assinaturas. Essas opções basicamente cobrem as operações criptográficas que o próprio Dusk usa no seu sistema inteiro de privacidade e consenso. Em outras palavras, é como se tivessem aberto uma porta para escapar do caminho convencional da sandbox, focando nas partes mais difíceis.
Esse projeto traz eficiência de execução, mas também significa que a correção da implementação dessas host functions é extremamente crítica — se houver uma vulnerabilidade nessas funções nativas, o impacto é mais direto do que em falhas do lado do software, porque todos os contratos compartilham o mesmo canal de aceleração em nível de base.
$DUSK
#dusk @Dusk
A VM do Dusk, o Piecrust, faz algo parecido. O código dos contratos inteligentes roda em uma sandbox WASM, buscando segurança e portabilidade, mas com o custo de ser lento — especialmente em operações criptográficas como hash, verificação de assinatura e provas de conhecimento zero, que têm um gasto alto ao serem executadas dentro da sandbox. A abordagem do Dusk é separar essas operações de alta frequência e transformá-las em "host functions", chamando diretamente o código nativo de baixo nível, sem ficar calculando pesado dentro do WASM.
As principais operações separadas são: hash com Blake2b e Poseidon; verificação com verify_plonk (prova PlonK), verify_groth16_bn254; e também verify_schnorr e verify_bls para verificação de assinaturas. Essas opções basicamente cobrem as operações criptográficas que o próprio Dusk usa no seu sistema inteiro de privacidade e consenso. Em outras palavras, é como se tivessem aberto uma porta para escapar do caminho convencional da sandbox, focando nas partes mais difíceis.
Esse projeto traz eficiência de execução, mas também significa que a correção da implementação dessas host functions é extremamente crítica — se houver uma vulnerabilidade nessas funções nativas, o impacto é mais direto do que em falhas do lado do software, porque todos os contratos compartilham o mesmo canal de aceleração em nível de base.
$DUSK
#dusk @Dusk