Já eram onze e meia quando consegui fazer a criança dormir. Faltei meia hora para evitar ficar no celular: abri e dei uma olhada na documentação da camada de execução do Dusk. Eu pretendia apenas passar os olhos e ir dormir, mas acabei travando num detalhe e não consegui pegar no sono.

O Piecrust é a máquina virtual de contratos inteligentes do Dusk, baseada em WASM — nisso ele não tem nada de especial, já que muitos novos blockchains fazem escolhas parecidas. O que o torna diferente é como ele lida com operações criptográficas: em vez de entregar ao bytecode do WASM tarefas pesadas como cálculo de hashes e verificação de provas de conhecimento zero, ele transforma isso em funções de host e chama diretamente uma implementação em Rust de baixo nível para calcular. Ou seja, o código do contrato roda na sandbox da VM para a lógica comum, mas ao se deparar com cálculos criptográficos mais pesados, ele “sai” da sandbox e entrega o trabalho ao código nativo; depois que termina, devolve o resultado de volta.

À primeira vista, essa divisão parece apenas uma otimização de engenharia, mas pensar um pouco mostra que é necessário. Colocar a verificação de provas de conhecimento zero para rodar em uma VM interpretativa causa perdas de desempenho na escala de “ordens de grandeza”. Especialmente no Dusk, que por padrão segue o caminho de transações criptográficas, quase toda transação precisa passar por essa verificação de prova. Se essa parte ficar no gargalo, o throughput da cadeia inteira é simplesmente sufocado. Transferir para código nativo a parte que consome mais recursos é, na essência, um meio-termo entre dois objetivos: “turing-completude do contrato” e “computação privada não pode destruir o desempenho”.

O que travou a minha dúvida foi: essas interfaces de chamada das funções de host quem define? E isso pode ser expandido no futuro? Se, a cada nova primitiva criptográfica, for preciso mexer no código interno da VM, então a variedade de primitivas de privacidade que os desenvolvedores podem usar fica, em certa medida, presa ao ritmo de atualização do time central — ou seja, não está aberta para expansão livre dentro do ecossistema. Isso entra um pouco em contradição com a narrativa de uma blockchain em que “turing-completa e os desenvolvedores podem criar livremente”; só que essa contradição fica escondida no nível mais baixo, então normalmente não dá para sentir.

Quando pensei nisso, perdi a vontade de continuar lendo. Anotei primeiro e, quando tiver uma chance, vou verificar até que ponto as funções de host são realmente abertas.

Vocês acham que, ao separar os cálculos criptográficos centrais da sandbox para rodar código nativo, essa decisão de “priorizar desempenho” traz um custo maior do que parece?

@Dusk_Foundation #dusk $DUSK