O bug PLONK do Dusk — a camada de privacidade avaliada em US$ 600 mil quase foi rompida por uma falsificação de prova
Depois que terminei de ler o relatório de segurança divulgado pela OtterSec em 30 de abril de 2026, fiquei paralisado por uns cinco minutos. O verificador do dusk-plonk nunca validou as quatro comitências de polinômios fornecidas pelo provador. Em outras palavras: o atacante pode forjar uma prova ZK falsa, sem precisar de quaisquer ativos reais, cunhar tokens DUSK e transferir os ganhos ilegais. Um protocolo de privacidade pensado para mercados financeiros regulados — cujo núcleo criptográfico tem uma falha que permite ao atacante criar tokens do nada. Uma infraestrutura que se diz feita para dar tranquilidade a instituições, mas que tem uma deficiência fundamental na camada de privacidade.
A narrativa de conformidade descrita no whitepaper é bonita, mas o código quase abriu uma “porta dos fundos” para cunhagem infinita. Você pode dizer que a falha foi corrigida. Mas esse tipo de falha aparece justamente no componente de verificação da camada de privacidade — isso é um tapa na cara da proposta “privacidade em primeiro lugar”. Um projeto que vive de ZK teve um problema na implementação de ZK. A primeira pergunta que me veio depois de ler o relatório foi: — uma blockchain de privacidade que vive de ZK, com uma implementação desse tipo de bug, o que mais não daria problema?
O valor de mercado do Dusk já caiu bastante desde o pico. US$ 600 mil, convertido pela cotação da época, significa que se o atacante usasse essa falha para cunhar grandes quantidades de tokens, o preço poderia ser diretamente derrubado. @Dusk
Procurei e encontrei um relatório de auditoria do Dusk para revisar. A empresa auditora foi a Dust Labs, e o escopo da auditoria cobriu apenas parte dos módulos. A lógica de verificação do dusk-plonk estava dentro do escopo da auditoria? Eu não encontrei uma explicação clara. Se o código central da camada de privacidade foi omitido na auditoria, ou se a própria auditoria não cobriu a área relevante, então o valor desse relatório precisa ser reavaliado. Auditoria não é algo que se faz uma vez e pronto.
Não estou dizendo que o Dusk não seja confiável, mas um projeto que coloca “privacidade” no nome, e que apresenta esse tipo de falha fundamental na camada central de verificação ZK, torna muito difícil eu me convencer a continuar segurando. Vamos ver primeiro se o núcleo criptográfico passa por mais rodadas de validação. Por enquanto, vou colocá-lo de volta na lista de observação para ver se surgem novas divulgações de falhas. Se o mesmo módulo voltar a apresentar problemas, não será apenas um problema técnico — será um problema de processo.
#dusk $DUSK
Depois que terminei de ler o relatório de segurança divulgado pela OtterSec em 30 de abril de 2026, fiquei paralisado por uns cinco minutos. O verificador do dusk-plonk nunca validou as quatro comitências de polinômios fornecidas pelo provador. Em outras palavras: o atacante pode forjar uma prova ZK falsa, sem precisar de quaisquer ativos reais, cunhar tokens DUSK e transferir os ganhos ilegais. Um protocolo de privacidade pensado para mercados financeiros regulados — cujo núcleo criptográfico tem uma falha que permite ao atacante criar tokens do nada. Uma infraestrutura que se diz feita para dar tranquilidade a instituições, mas que tem uma deficiência fundamental na camada de privacidade.
A narrativa de conformidade descrita no whitepaper é bonita, mas o código quase abriu uma “porta dos fundos” para cunhagem infinita. Você pode dizer que a falha foi corrigida. Mas esse tipo de falha aparece justamente no componente de verificação da camada de privacidade — isso é um tapa na cara da proposta “privacidade em primeiro lugar”. Um projeto que vive de ZK teve um problema na implementação de ZK. A primeira pergunta que me veio depois de ler o relatório foi: — uma blockchain de privacidade que vive de ZK, com uma implementação desse tipo de bug, o que mais não daria problema?
O valor de mercado do Dusk já caiu bastante desde o pico. US$ 600 mil, convertido pela cotação da época, significa que se o atacante usasse essa falha para cunhar grandes quantidades de tokens, o preço poderia ser diretamente derrubado. @Dusk
Procurei e encontrei um relatório de auditoria do Dusk para revisar. A empresa auditora foi a Dust Labs, e o escopo da auditoria cobriu apenas parte dos módulos. A lógica de verificação do dusk-plonk estava dentro do escopo da auditoria? Eu não encontrei uma explicação clara. Se o código central da camada de privacidade foi omitido na auditoria, ou se a própria auditoria não cobriu a área relevante, então o valor desse relatório precisa ser reavaliado. Auditoria não é algo que se faz uma vez e pronto.
Não estou dizendo que o Dusk não seja confiável, mas um projeto que coloca “privacidade” no nome, e que apresenta esse tipo de falha fundamental na camada central de verificação ZK, torna muito difícil eu me convencer a continuar segurando. Vamos ver primeiro se o núcleo criptográfico passa por mais rodadas de validação. Por enquanto, vou colocá-lo de volta na lista de observação para ver se surgem novas divulgações de falhas. Se o mesmo módulo voltar a apresentar problemas, não será apenas um problema técnico — será um problema de processo.
#dusk $DUSK
