Passei uma hora rastreando a ativação do PLONK V3 da Dusk no bloco 3,590,904; depois, uma linha de segurança de uma carteira me afastou. O repositório diz que nenhuma auditoria externa foi concluída ainda.
Isso não torna a criptografia da Dusk fraca. Isso torna a métrica de superfície errada para o talento criptográfico sério.
Um verificador de provas pode rejeitar pontos malformados inconsistentes com as entradas públicas e circuitos comprimidos perfeitamente, enquanto a transação do usuário ainda depende da derivação de senha do código de extensão, das permissões de memória do JavaScript, do endpoint do nó e do prompt de assinatura.
A extensão usa PBKDF2 com 900.000 iterações e AES-GCM-256; o caminho nativo usa Stronghold mais Argon2. Caminhos diferentes, suposições de confiança diferentes.
Então eu avaliaria o comportamento: quantas builds independentes geram verifiers Solidity idênticos byte a byte? Qual prova malformada consome mais gás antes da rejeição? O CLI expõe o mesmo aviso de destinatário sinalizado que a Web Wallet? E o caminho de assinatura recebeu um escrutínio comparável ao do PLONK?
Alguma assimetria é normal. Carteiras de navegador não conseguem garantir a zeroização da memória do JavaScript e uma implantação mais simples do verificador tem valor mesmo que o custo de gás não diminua.
Mas a segurança institucional da Dusk será determinada pelo componente de autoridade mais fraco que a suporta, não por sua matemática mais elegante. Estou observando se as auditorias acompanham todo o caminho da transação, ponta a ponta.
#dusk $DUSK @Dusk
Isso não torna a criptografia da Dusk fraca. Isso torna a métrica de superfície errada para o talento criptográfico sério.
Um verificador de provas pode rejeitar pontos malformados inconsistentes com as entradas públicas e circuitos comprimidos perfeitamente, enquanto a transação do usuário ainda depende da derivação de senha do código de extensão, das permissões de memória do JavaScript, do endpoint do nó e do prompt de assinatura.
A extensão usa PBKDF2 com 900.000 iterações e AES-GCM-256; o caminho nativo usa Stronghold mais Argon2. Caminhos diferentes, suposições de confiança diferentes.
Então eu avaliaria o comportamento: quantas builds independentes geram verifiers Solidity idênticos byte a byte? Qual prova malformada consome mais gás antes da rejeição? O CLI expõe o mesmo aviso de destinatário sinalizado que a Web Wallet? E o caminho de assinatura recebeu um escrutínio comparável ao do PLONK?
Alguma assimetria é normal. Carteiras de navegador não conseguem garantir a zeroização da memória do JavaScript e uma implantação mais simples do verificador tem valor mesmo que o custo de gás não diminua.
Mas a segurança institucional da Dusk será determinada pelo componente de autoridade mais fraco que a suporta, não por sua matemática mais elegante. Estou observando se as auditorias acompanham todo o caminho da transação, ponta a ponta.
#dusk $DUSK @Dusk