#dusk $DUSK @Dusk
Estive comparando o caminho de verificação criptográfica do Dusk com aquilo que uma alternativa totalmente isolada em sandbox exigiria, desde que "movido para fora do WASM" é dito sem uma base numérica sólida em quase todos os lugares que li.
Os próprios materiais do Dusk confirmam que o Piecrust expõe hashing, verificação do PLONK, verificação do Groth16 e verificações de assinatura como funções host — código nativo que o runtime chama diretamente, ignorando a máquina virtual WASM para essas operações específicas. Separadamente, descobri que a Phoenix usa especificamente uma variante de assinatura dupla-Schnorr, descrita no próprio repositório do Dusk como uma introdução inovadora que delega o cálculo das provas sem expor a chave secreta do signatário — ou seja, até a camada de assinaturas, 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 isolada. Cada primitiva criptográfica da qual uma transação da Phoenix realmente depende roda nativamente.
Ainda é uma hipótese que vale ser enunciada com precisão: não encontrei um benchmark publicado — em porcentagem especificamente — quantificando o quanto a verificação da Phoenix ficaria mais lenta se essas checagens permanecessem dentro do WASM, em vez de serem executadas como funções host no setup atual do Dusk.
O que mudou na minha leitura: eu tinha presumido que isso era apenas uma escolha de otimização. Também é uma escolha de fronteira de segurança — código nativo carrega propriedades de superfície de ataque diferentes do código WASM isolado, que o enquadramento apenas de desempenho não captura.
Estive comparando o caminho de verificação criptográfica do Dusk com aquilo que uma alternativa totalmente isolada em sandbox exigiria, desde que "movido para fora do WASM" é dito sem uma base numérica sólida em quase todos os lugares que li.
Os próprios materiais do Dusk confirmam que o Piecrust expõe hashing, verificação do PLONK, verificação do Groth16 e verificações de assinatura como funções host — código nativo que o runtime chama diretamente, ignorando a máquina virtual WASM para essas operações específicas. Separadamente, descobri que a Phoenix usa especificamente uma variante de assinatura dupla-Schnorr, descrita no próprio repositório do Dusk como uma introdução inovadora que delega o cálculo das provas sem expor a chave secreta do signatário — ou seja, até a camada de assinaturas, 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 isolada. Cada primitiva criptográfica da qual uma transação da Phoenix realmente depende roda nativamente.
Ainda é uma hipótese que vale ser enunciada com precisão: não encontrei um benchmark publicado — em porcentagem especificamente — quantificando o quanto a verificação da Phoenix ficaria mais lenta se essas checagens permanecessem dentro do WASM, em vez de serem executadas como funções host no setup atual do Dusk.
O que mudou na minha leitura: eu tinha presumido que isso era apenas uma escolha de otimização. Também é uma escolha de fronteira de segurança — código nativo carrega propriedades de superfície de ataque diferentes do código WASM isolado, que o enquadramento apenas de desempenho não captura.
Pure optimization
100%
Also a security tradeoff
0%
1 Votos • Votação encerrada