#dusk $DUSK
A frase "funções host" continuou aparecendo no whitepaper do Dusk e eu continuei tratando isso como um detalhe de implementação. Quando eu realmente li a seção de desempenho, descobri que era uma decisão arquitetural mais deliberada do que eu imaginava.
Executar ZK dentro de uma VM WASM: o whitepaper cita pesquisas mostrando que a execução em WASM pode ser 45-255% mais lenta em comparação com código nativo para aplicações complexas. A sobrecarga vem do gerenciamento de memória virtualizado e do tratamento adicional de instruções dentro de um ambiente isolado (sandboxed). Para hashing e validação de assinatura, isso é incômodo. Para verificação de provas ZK, que roda a cada transação, 45-255% mais lento é um problema significativo de throughput.
Funções host: o Dusk expõe um conjunto de funções que rodam nativamente na máquina hospedeira, fora do sandbox do WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls e hash. O contrato inteligente chama essas funções diretamente; o trabalho criptográfico pesado acontece em velocidade nativa. O resultado é replicado entre nós da mesma forma que qualquer outra computação.
Então, por que não é isso que todas as cadeias que rodam ZK fazem.
Mover a computação para fora da VM reduz a garantia de sandboxing. Em um modelo de execução WASM puro, um contrato com bug ou malicioso fica isolado dentro do limite da VM. Quando você adiciona funções host, está expondo acesso em nível nativo a operações específicas — e um bug ou má configuração na camada das funções host pode ter consequências que um contrato sandboxed, sozinho, não conseguiria causar. Você está trocando isolamento por throughput.
Eu pessoalmente acho mais interessante o argumento de eficiência energética do que o de velocidade — o whitepaper enquadra funções host parcialmente como uma forma de reduzir os custos de energia por nó, e não apenas a latência. Isso é uma forma incomum de enquadrar um documento de design de blockchain.
O que eu não vi explicado é como o Dusk lida com versionamento de funções host — se uma mudança no comportamento de uma função host constitui uma mudança de protocolo que exige consenso, ou se os operadores podem atualizar as implementações de forma independente. @Dusk
$DUSK #dusk
A frase "funções host" continuou aparecendo no whitepaper do Dusk e eu continuei tratando isso como um detalhe de implementação. Quando eu realmente li a seção de desempenho, descobri que era uma decisão arquitetural mais deliberada do que eu imaginava.
Executar ZK dentro de uma VM WASM: o whitepaper cita pesquisas mostrando que a execução em WASM pode ser 45-255% mais lenta em comparação com código nativo para aplicações complexas. A sobrecarga vem do gerenciamento de memória virtualizado e do tratamento adicional de instruções dentro de um ambiente isolado (sandboxed). Para hashing e validação de assinatura, isso é incômodo. Para verificação de provas ZK, que roda a cada transação, 45-255% mais lento é um problema significativo de throughput.
Funções host: o Dusk expõe um conjunto de funções que rodam nativamente na máquina hospedeira, fora do sandbox do WASM. verify_plonk, verify_groth16_bn254, verify_schnorr, verify_bls e hash. O contrato inteligente chama essas funções diretamente; o trabalho criptográfico pesado acontece em velocidade nativa. O resultado é replicado entre nós da mesma forma que qualquer outra computação.
Então, por que não é isso que todas as cadeias que rodam ZK fazem.
Mover a computação para fora da VM reduz a garantia de sandboxing. Em um modelo de execução WASM puro, um contrato com bug ou malicioso fica isolado dentro do limite da VM. Quando você adiciona funções host, está expondo acesso em nível nativo a operações específicas — e um bug ou má configuração na camada das funções host pode ter consequências que um contrato sandboxed, sozinho, não conseguiria causar. Você está trocando isolamento por throughput.
Eu pessoalmente acho mais interessante o argumento de eficiência energética do que o de velocidade — o whitepaper enquadra funções host parcialmente como uma forma de reduzir os custos de energia por nó, e não apenas a latência. Isso é uma forma incomum de enquadrar um documento de design de blockchain.
O que eu não vi explicado é como o Dusk lida com versionamento de funções host — se uma mudança no comportamento de uma função host constitui uma mudança de protocolo que exige consenso, ou se os operadores podem atualizar as implementações de forma independente. @Dusk
$DUSK #dusk
