Eu executo um pequeno script Python no meu laptop em Islamabad que faz uma grande quantidade de hashing para um projeto paralelo, e uma vez tentei movê-lo para um ambiente isolado (sandbox) achando que ele rodaria tão rápido quanto, já que a lógica não mudava. Ele rodou de forma perceptivelmente mais lenta, e até eu ler sobre a VM Piecrust da Dusk eu nunca entendi de fato por que isso acontece em nível técnico.
Eu assumi que toda a execução de contratos inteligentes dentro de uma máquina virtual WASM roda aproximadamente com velocidade nativa, já que o WASM normalmente é comercializado como tendo desempenho próximo ao nativo.
Isso não é preciso para operações criptográficas especificamente. Pesquisas citadas no whitepaper mostram que a execução em WASM pode rodar de 45 a 255 por cento mais devagar do que código nativo para aplicações complexas, principalmente por causa da gerência de memória virtualizada e do tratamento adicional de instruções dentro do sandbox.
É exatamente por isso que a Piecrust não executa coisas como verificação de prova ZK, hashing ou checagens de assinatura dentro do sandbox WASM. Em vez disso, ela expõe funções do host: chamadas nativas diretas para operações como hash, verify_plonk, verify_groth16_bn254, verify_schnorr e verify_bls. O contrato faz chamadas para o código nativo para o trabalho criptográfico mais caro e, então, volta para o WASM para todo o resto. Isso é uma divisão arquitetural deliberada, não um workaround.
O que o whitepaper admite diretamente é que a Dusk ainda não quantificou as economias reais de consumo de energia a partir dessa configuração. Então eu não consigo te dizer um número real de eficiência, porque a própria Dusk não publicou um.
O teste real para a DUSK é se essa abordagem baseada em função de host continua valendo conforme a complexidade do contrato cresce na mainnet.
Alguém fez benchmarks das chamadas de função host da Piecrust em comparação com a execução pura em WASM por conta própria?
@Dusk #dusk $DUSK
Eu assumi que toda a execução de contratos inteligentes dentro de uma máquina virtual WASM roda aproximadamente com velocidade nativa, já que o WASM normalmente é comercializado como tendo desempenho próximo ao nativo.
Isso não é preciso para operações criptográficas especificamente. Pesquisas citadas no whitepaper mostram que a execução em WASM pode rodar de 45 a 255 por cento mais devagar do que código nativo para aplicações complexas, principalmente por causa da gerência de memória virtualizada e do tratamento adicional de instruções dentro do sandbox.
É exatamente por isso que a Piecrust não executa coisas como verificação de prova ZK, hashing ou checagens de assinatura dentro do sandbox WASM. Em vez disso, ela expõe funções do host: chamadas nativas diretas para operações como hash, verify_plonk, verify_groth16_bn254, verify_schnorr e verify_bls. O contrato faz chamadas para o código nativo para o trabalho criptográfico mais caro e, então, volta para o WASM para todo o resto. Isso é uma divisão arquitetural deliberada, não um workaround.
O que o whitepaper admite diretamente é que a Dusk ainda não quantificou as economias reais de consumo de energia a partir dessa configuração. Então eu não consigo te dizer um número real de eficiência, porque a própria Dusk não publicou um.
O teste real para a DUSK é se essa abordagem baseada em função de host continua valendo conforme a complexidade do contrato cresce na mainnet.
Alguém fez benchmarks das chamadas de função host da Piecrust em comparação com a execução pura em WASM por conta própria?
@Dusk #dusk $DUSK
