#dusk $DUSK @Dusk #dusk $DUSK @Dusk
Eis uma decisão de design sobre o Dusk que eu não tinha visto enquadrada corretamente em lugar nenhum.
O DuskVM executa contratos Rust/WASM no Wasmtime, diretamente na L1. Tudo bem, essa é uma escolha de stack. O que acho mais interessante é o que o nó expõe para esses contratos.
Verificar uma prova de conhecimento zero dentro de um contrato, instrução por instrução, é brutalmente caro. Então o Dusk levou isso um nível abaixo: o rusk-abi fornece para os contratos funções de host para verificação de provas, incluindo verify_groth16. O host atualmente suporta dois sistemas de provas — Groth16 e PLONK.
Isso é uma capacidade real. Significa que um contrato no Dusk pode aceitar uma prova ZK como entrada e verificá-la a um custo próximo ao nativo. Em a maioria das redes, isso é impossível ou é destrutivo em termos de custos.
Mas repare também no que isso significa. O conjunto de sistemas de prova disponível para você, como construtor, é fixo na camada de protocolo, não é escolhido pela sua aplicação. Quer um esquema diferente porque o seu circuito se encaixa melhor nele? Você está pedindo uma mudança no protocolo, não “importando” uma biblioteca.
Esse é o trade em uma frase: a verificação no nível do host dá custo, e cobra opcionalidade.
Para uma cadeia voltada a finanças reguladas, eu de fato acho que esse é o lado correto do trade. O software institucional quer um conjunto pequeno, auditado e estável de primitivas — não cinquenta dialetos criptográficos. Mas isso também significa que o time do protocolo, não o mercado, decide em quais criptografias o ecossistema pode construir, e essa decisão se acumula ao longo dos anos.
Também vale lembrar que a própria VM tem seu histórico de auditoria — Piecrust foi revisado em julho de 2024, antes de existir a maior parte da arquitetura atual.
Sistemas de prova devem ser primitivas de nível de protocolo que todo mundo compartilha, ou escolhas de nível de aplicação que cada equipe faz por conta própria?
Eis uma decisão de design sobre o Dusk que eu não tinha visto enquadrada corretamente em lugar nenhum.
O DuskVM executa contratos Rust/WASM no Wasmtime, diretamente na L1. Tudo bem, essa é uma escolha de stack. O que acho mais interessante é o que o nó expõe para esses contratos.
Verificar uma prova de conhecimento zero dentro de um contrato, instrução por instrução, é brutalmente caro. Então o Dusk levou isso um nível abaixo: o rusk-abi fornece para os contratos funções de host para verificação de provas, incluindo verify_groth16. O host atualmente suporta dois sistemas de provas — Groth16 e PLONK.
Isso é uma capacidade real. Significa que um contrato no Dusk pode aceitar uma prova ZK como entrada e verificá-la a um custo próximo ao nativo. Em a maioria das redes, isso é impossível ou é destrutivo em termos de custos.
Mas repare também no que isso significa. O conjunto de sistemas de prova disponível para você, como construtor, é fixo na camada de protocolo, não é escolhido pela sua aplicação. Quer um esquema diferente porque o seu circuito se encaixa melhor nele? Você está pedindo uma mudança no protocolo, não “importando” uma biblioteca.
Esse é o trade em uma frase: a verificação no nível do host dá custo, e cobra opcionalidade.
Para uma cadeia voltada a finanças reguladas, eu de fato acho que esse é o lado correto do trade. O software institucional quer um conjunto pequeno, auditado e estável de primitivas — não cinquenta dialetos criptográficos. Mas isso também significa que o time do protocolo, não o mercado, decide em quais criptografias o ecossistema pode construir, e essa decisão se acumula ao longo dos anos.
Também vale lembrar que a própria VM tem seu histórico de auditoria — Piecrust foi revisado em julho de 2024, antes de existir a maior parte da arquitetura atual.
Sistemas de prova devem ser primitivas de nível de protocolo que todo mundo compartilha, ou escolhas de nível de aplicação que cada equipe faz por conta própria?