#dusk $DUSK @Dusk
O que me chamou a atenção não foi a mensagem de conformidade da Dusk, e sim o que uma empresa de auditoria independente encontrou dentro do Dusk plonk: o sistema de provas que protege o modelo de transação com valores ocultos (shielded) do @Dusk na DuskDS.
O mecanismo: a Phoenix usa provas PLONK para que um gasto possa ser verificado sem revelar saldos. O verificador deve checar um lote de compromissos (commitments) de polinômios contra uma chave verificada (trusted verifier key) antes de aceitar qualquer prova como válida.
A parte que eu quis confirmar: de acordo com um relatório de uma firma de segurança, quatro dessas avaliações de seletor nunca foram de fato verificadas em relação aos seus commitments. O verificador as consumiu sem validá-las. Em teoria, essa lacuna poderia permitir que uma prova forjada passasse como legítima.
Por que isso importa: isso fica diretamente abaixo do pool shielded de onde os fluxos regulados de ativos deveriam herdar privacidade. Uma prova forjada em um sistema de notas opaco é difícil de detectar depois — esse é justamente o objetivo do shield.
O detalhe que a maioria das pessoas deixaria passar: a correção foi implementada no meio de fevereiro de 2026, antes da divulgação pública em abril, então foi corrigido sem ser explorado, com base no que foi publicado. O que não está claro para mim é se isso foi identificado na revisão interna da Dusk ou por uma parte externa primeiro, e como esse cronograma foi comunicado aos parceiros que dependem dessa camada.
"Audited" (auditado) significa muito se a correção antecede a divulgação em dois meses?
$DUSK #dusk
O que me chamou a atenção não foi a mensagem de conformidade da Dusk, e sim o que uma empresa de auditoria independente encontrou dentro do Dusk plonk: o sistema de provas que protege o modelo de transação com valores ocultos (shielded) do @Dusk na DuskDS.
O mecanismo: a Phoenix usa provas PLONK para que um gasto possa ser verificado sem revelar saldos. O verificador deve checar um lote de compromissos (commitments) de polinômios contra uma chave verificada (trusted verifier key) antes de aceitar qualquer prova como válida.
A parte que eu quis confirmar: de acordo com um relatório de uma firma de segurança, quatro dessas avaliações de seletor nunca foram de fato verificadas em relação aos seus commitments. O verificador as consumiu sem validá-las. Em teoria, essa lacuna poderia permitir que uma prova forjada passasse como legítima.
Por que isso importa: isso fica diretamente abaixo do pool shielded de onde os fluxos regulados de ativos deveriam herdar privacidade. Uma prova forjada em um sistema de notas opaco é difícil de detectar depois — esse é justamente o objetivo do shield.
O detalhe que a maioria das pessoas deixaria passar: a correção foi implementada no meio de fevereiro de 2026, antes da divulgação pública em abril, então foi corrigido sem ser explorado, com base no que foi publicado. O que não está claro para mim é se isso foi identificado na revisão interna da Dusk ou por uma parte externa primeiro, e como esse cronograma foi comunicado aos parceiros que dependem dessa camada.
"Audited" (auditado) significa muito se a correção antecede a divulgação em dois meses?
$DUSK #dusk
