#dusk $DUSK @Dusk
Por que a verificação de prova saiu do sandbox para ganhar velocidade
Tenho comparado o caminho de verificação criptográfica do Dusk com o que uma alternativa totalmente em sandbox exigiria, desde que “moved outside WASM” (moveu-se para fora do WASM) é afirmado sem muito embasamento numérico em grande parte do que li.
Os próprios materiais do Dusk confirmam que o Piecrust expõe operações de hashing, verificação PLONK, verificação Groth16 e verificações de assinatura como funções host — código nativo que o runtime chama diretamente, ignorando totalmente a máquina virtual WASM para essas operações específicas. Em seguida, descobri que o Phoenix usa especificamente uma variante de assinatura Schnorr dupla, descrita no próprio repositório do Dusk como uma introdução nova que delega o cálculo da prova sem expor a chave secreta do signatário — ou seja, mesmo a camada de assinatura, e não apenas a camada da prova ZK, foi construída para passar por esse caminho nativo.
Faça as contas sobre o que fica dentro do WASM versus o que não fica. A lógica geral do contrato — mudanças de estado, regras de negócio — roda em sandbox. Toda primitiva criptográfica de que uma transação do Phoenix realmente depende roda nativamente em vez disso.
Ainda assim, isso é uma hipótese que vale formular com precisão: eu não encontrei um benchmark publicado, em percentuais especificamente quantificando o quanto mais lenta seria a verificação do Phoenix caso essas verificações ficassem dentro do WASM em vez de rodarem como funções host no setup atual do Dusk.
O que mudou na minha leitura: eu havia assumido que isso era apenas uma escolha de otimização. Também é uma escolha de limite de segurança — código nativo carrega propriedades de superfície de ataque diferentes do código WASM em sandbox, que o enquadramento de desempenho sozinho não captura.
Por que a verificação de prova saiu do sandbox para ganhar velocidade
Tenho comparado o caminho de verificação criptográfica do Dusk com o que uma alternativa totalmente em sandbox exigiria, desde que “moved outside WASM” (moveu-se para fora do WASM) é afirmado sem muito embasamento numérico em grande parte do que li.
Os próprios materiais do Dusk confirmam que o Piecrust expõe operações de hashing, verificação PLONK, verificação Groth16 e verificações de assinatura como funções host — código nativo que o runtime chama diretamente, ignorando totalmente a máquina virtual WASM para essas operações específicas. Em seguida, descobri que o Phoenix usa especificamente uma variante de assinatura Schnorr dupla, descrita no próprio repositório do Dusk como uma introdução nova que delega o cálculo da prova sem expor a chave secreta do signatário — ou seja, mesmo a camada de assinatura, e não apenas a camada da prova ZK, foi construída para passar por esse caminho nativo.
Faça as contas sobre o que fica dentro do WASM versus o que não fica. A lógica geral do contrato — mudanças de estado, regras de negócio — roda em sandbox. Toda primitiva criptográfica de que uma transação do Phoenix realmente depende roda nativamente em vez disso.
Ainda assim, isso é uma hipótese que vale formular com precisão: eu não encontrei um benchmark publicado, em percentuais especificamente quantificando o quanto mais lenta seria a verificação do Phoenix caso essas verificações ficassem dentro do WASM em vez de rodarem como funções host no setup atual do Dusk.
O que mudou na minha leitura: eu havia assumido que isso era apenas uma escolha de otimização. Também é uma escolha de limite de segurança — código nativo carrega propriedades de superfície de ataque diferentes do código WASM em sandbox, que o enquadramento de desempenho sozinho não captura.
Pure optimization
0%
Also a security tradeoff
0%
0 Votos • Votação encerrada