Ao ver @Dusk de novo com tarefas para criadores, aproveito para conversar sobre um “passado negro” bem hardcore que encontrei antes.
O relatório que a OtterSec revelou neste ano, em abril, deixou todo mundo com um aperto no coração! O problema não era uma lógica de negócio comum — na verdade, estava na etapa mais central da verificação das provas ZK (dusk-plonk). Em termos simples, na época o atacante tinha a oportunidade de falsificar a prova, emitindo tokens infinitamente do nada ou desviando ativos 🥶🤮 Para uma blockchain de privacidade focada em instituições, com privacidade e conformidade financeira, ter a camada de verificação comprometida é uma notícia gravíssima — algo que realmente balança a base.
Embora o bug já tenha sido corrigido há algum tempo e não tenha causado perdas reais, depois que eu li o relatório de auditoria fiquei com a sensação de que algo ainda não estava 100%: a parte mais crítica das provas de conhecimento zero, nas auditorias anteriores, foi realmente coberta de forma completa? A privacidade dessa cadeia vende confiança na segurança criptográfica; se os componentes centrais não passaram por repetidas “provas de estresse”, o processo de engenharia e desenvolvimento certamente precisa de melhorias.
Não estou tentando desanimar nem menosprezar, mas para projetos focados em privacidade, basta um único deslize no controle e na aplicação do código de segurança para que o custo de confiança dobre. Neste momento, eu escolho continuar observando e ver se a operação de segurança e as iterações técnicas deles vão ficar realmente firmes.
Na sua opinião, as vulnerabilidades de segurança centrais de uma blockchain de privacidade podem ser “vetadas por voto” de uma vez só? Se fosse você, ainda consideraria fazer um plano envolvendo $DUSK ? Vamos conversar nos comentários! #dusk
O relatório que a OtterSec revelou neste ano, em abril, deixou todo mundo com um aperto no coração! O problema não era uma lógica de negócio comum — na verdade, estava na etapa mais central da verificação das provas ZK (dusk-plonk). Em termos simples, na época o atacante tinha a oportunidade de falsificar a prova, emitindo tokens infinitamente do nada ou desviando ativos 🥶🤮 Para uma blockchain de privacidade focada em instituições, com privacidade e conformidade financeira, ter a camada de verificação comprometida é uma notícia gravíssima — algo que realmente balança a base.
Embora o bug já tenha sido corrigido há algum tempo e não tenha causado perdas reais, depois que eu li o relatório de auditoria fiquei com a sensação de que algo ainda não estava 100%: a parte mais crítica das provas de conhecimento zero, nas auditorias anteriores, foi realmente coberta de forma completa? A privacidade dessa cadeia vende confiança na segurança criptográfica; se os componentes centrais não passaram por repetidas “provas de estresse”, o processo de engenharia e desenvolvimento certamente precisa de melhorias.
Não estou tentando desanimar nem menosprezar, mas para projetos focados em privacidade, basta um único deslize no controle e na aplicação do código de segurança para que o custo de confiança dobre. Neste momento, eu escolho continuar observando e ver se a operação de segurança e as iterações técnicas deles vão ficar realmente firmes.
Na sua opinião, as vulnerabilidades de segurança centrais de uma blockchain de privacidade podem ser “vetadas por voto” de uma vez só? Se fosse você, ainda consideraria fazer um plano envolvendo $DUSK ? Vamos conversar nos comentários! #dusk
