@Dusk
Em algum lugar no design do Piecrust existe uma admissão silenciosa de que o sandbox não é o lugar certo para tudo.
Contratos rodam como WebAssembly, o que dá à VM seu ambiente de execução controlado.
O interessante é quanto do trabalho pesado nem sequer toca aquele ambiente WASM.
O hashing é calculado nativamente.
O mesmo vale para a verificação de provas ZK, tanto PlonK quanto Groth16.
Checagens de assinatura também, Schnorr e BLS.
Nada disso roda dentro do sandbox executando o contrato.
O motivo é um número, e é um daqueles difíceis.
A pesquisa da Dusk cita que WASM fica entre 45 e 255 por cento mais lento do que código nativo quando as operações ficam complexas. Verificação criptográfica é exatamente o tipo de trabalho em que essa diferença importa.
Aplicar essa penalidade a cada transação não era um tipo de troca que a Dusk estava disposta a fazer, então essas operações são tratadas por meio de funções nativas do host.
Foi isso que me pegou.
As operações que são retiradas não são aleatórias.
Hashing, verificação de prova, assinaturas. isso é grande parte da engenharia criptográfica de que aplicações com foco em privacidade como Phoenix e Zedger dependem.
O sandbox lida com a lógica do contrato.
A matemática da privacidade roda em algum outro lugar.
Então não existe realmente uma única fronteira de execução. Há a fronteira geral da VM e, em seguida, há saídas deliberadas para as operações em que a execução nativa importa mais.
O que eu ainda quero entender é o que mantém esse caminho nativo determinístico em cada nó. WASM te dá um ambiente de execução bem explícito; uma vez que um contrato chama para fora dele, quais garantias fazem com que cada nó ainda chegue exatamente ao mesmo resultado?
$DUSK fica ainda mais interessante para mim quando essa pergunta tem uma resposta real por trás, não apenas uma função nativa fazendo o trabalho mais rápido.
#dusk
Em algum lugar no design do Piecrust existe uma admissão silenciosa de que o sandbox não é o lugar certo para tudo.
Contratos rodam como WebAssembly, o que dá à VM seu ambiente de execução controlado.
O interessante é quanto do trabalho pesado nem sequer toca aquele ambiente WASM.
O hashing é calculado nativamente.
O mesmo vale para a verificação de provas ZK, tanto PlonK quanto Groth16.
Checagens de assinatura também, Schnorr e BLS.
Nada disso roda dentro do sandbox executando o contrato.
O motivo é um número, e é um daqueles difíceis.
A pesquisa da Dusk cita que WASM fica entre 45 e 255 por cento mais lento do que código nativo quando as operações ficam complexas. Verificação criptográfica é exatamente o tipo de trabalho em que essa diferença importa.
Aplicar essa penalidade a cada transação não era um tipo de troca que a Dusk estava disposta a fazer, então essas operações são tratadas por meio de funções nativas do host.
Foi isso que me pegou.
As operações que são retiradas não são aleatórias.
Hashing, verificação de prova, assinaturas. isso é grande parte da engenharia criptográfica de que aplicações com foco em privacidade como Phoenix e Zedger dependem.
O sandbox lida com a lógica do contrato.
A matemática da privacidade roda em algum outro lugar.
Então não existe realmente uma única fronteira de execução. Há a fronteira geral da VM e, em seguida, há saídas deliberadas para as operações em que a execução nativa importa mais.
O que eu ainda quero entender é o que mantém esse caminho nativo determinístico em cada nó. WASM te dá um ambiente de execução bem explícito; uma vez que um contrato chama para fora dele, quais garantias fazem com que cada nó ainda chegue exatamente ao mesmo resultado?
$DUSK fica ainda mais interessante para mim quando essa pergunta tem uma resposta real por trás, não apenas uma função nativa fazendo o trabalho mais rápido.
#dusk
