Eu costumava achar que o funcionamento do contrato no DuskVM dependia principalmente de o código em Rust compilar ou não, mas depois que li a documentação do DuskVM do @Dusk entendi que os pontos que mais facilmente travam ficam mais próximos do limite da chamada: o contrato precisa expor uma área de argbuf de 64KB, e a função de entrada deve receber o tamanho da entrada no formato fn foo(u32) -> u32, processar os dados e então retornar o tamanho da saída. A correção da lógica interna não significa que a chamada externa consiga alimentá-lo corretamente. Esse desenho me fez repensar o custo de desenvolvimento: o DuskVM não substitui o desenvolvedor ao impor a lógica do negócio, mas delega ao contrato a responsabilidade pelos limites de memória de entrada e saída. O que o chamador passa não é uma sequência de “parâmetros que podem ser lidos de qualquer jeito”, e sim dados já colocados em um buffer e cujo intervalo de leitura é determinado pelo comprimento. Se em algum lugar a serialização, a verificação do tamanho ou a gravação de retorno não estiverem alinhadas, o problema talvez não apareça como um erro de negócio claramente perceptível; o front-end apenas receberá uma falha única na chamada do contrato.
O cenário sob pressão é bem concreto: no teste local, o app de ativos funciona quando se passa apenas um número simples; ao colocar em produção, ao trocar por credenciais, pedidos ou dados de permissões mais longos, o contrato ainda pode ser chamado, mas lê apenas parte dos dados ou retorna resultados truncados. O usuário vê que o status não foi atualizado, e o desenvolvedor precisa voltar para investigar a ABI, o buffer e o “data driver”. O custo não é de uma máquina virtual abstrata, mas sim do usuário que está esperando o resultado e do time que mantém a integração.
Então, quando olho o DuskVM do $DUSK , eu não me limito a perguntar se ele consegue executar Rust ou WASM; primeiro verifico se os testes do contrato cobrem o comprimento dos parâmetros, o comprimento da saída e as entradas nos limites. O @Dusk deixa o acordo de chamada bem claro; por trás do desempenho e do controle, também há uma responsabilidade de memória. Para o desenvolvedor Dusk, o que realmente vale a pena validar é se, depois que dados complexos de negócios entram no contrato, os limites continuam previsíveis. #dusk
O cenário sob pressão é bem concreto: no teste local, o app de ativos funciona quando se passa apenas um número simples; ao colocar em produção, ao trocar por credenciais, pedidos ou dados de permissões mais longos, o contrato ainda pode ser chamado, mas lê apenas parte dos dados ou retorna resultados truncados. O usuário vê que o status não foi atualizado, e o desenvolvedor precisa voltar para investigar a ABI, o buffer e o “data driver”. O custo não é de uma máquina virtual abstrata, mas sim do usuário que está esperando o resultado e do time que mantém a integração.
Então, quando olho o DuskVM do $DUSK , eu não me limito a perguntar se ele consegue executar Rust ou WASM; primeiro verifico se os testes do contrato cobrem o comprimento dos parâmetros, o comprimento da saída e as entradas nos limites. O @Dusk deixa o acordo de chamada bem claro; por trás do desempenho e do controle, também há uma responsabilidade de memória. Para o desenvolvedor Dusk, o que realmente vale a pena validar é se, depois que dados complexos de negócios entram no contrato, os limites continuam previsíveis. #dusk
