#dusk $DUSK @Dusk Esta semana, consultei o índice do whitepaper da Dusk — página 2 de 22, apenas o sumário. Mas a estrutura me disse algo. A Seção 4, “Transactions (Transações)”, se divide em duas: Moonlight (página 13) e Phoenix (página 14). Dois modelos de transação no mesmo documento.

Vou ser transparente sobre o que eu realmente sei versus o que estou supondo. Apenas pelo índice, posso confirmar que a Dusk documenta dois tipos de transação sob uma mesma cadeia. Eu não li o texto completo dessas seções, então não posso verificar com certeza como elas diferem mecanicamente — estou inferindo, com base na convenção de nomenclatura e em padrões gerais da indústria, que uma provavelmente é transparente baseada em conta e a outra é que preserva a privacidade. Isso é uma suposição, não um fato confirmado por esta fonte.

O que é confirmado pelo índice: o consenso tem seis subseções completas (3.1–3.9, páginas 6–11) — provisioners, committees, attestations, sortition, emergency mode, fallback, rolling finality, incentives. Essa é uma estrutura densa apenas para a finalidade (finality). Eu não consigo verificar a partir de um índice se esse projeto foi testado sob condições adversariais em escala — isso exigiria o conteúdo técnico real, auditorias ou dados de mainnet, nenhum dos quais eu tenho diante de mim agora.

Então, aqui vai minha posição honesta: a estrutura do artigo sugere uma separação deliberada entre o tratamento de transações transparentes e confidenciais, o que importa para casos de uso de finanças reguladas. Mas alegações sobre tolerância a falhas ou resiliência de comitês precisam de verificação independente — auditorias, histórico de incidentes ou revisão de terceiros — antes que eu as trate como algo consolidado.

Alguém realmente já viu o mecanismo de consenso da Dusk ser revisado por uma auditoria independente de segurança, ou isso ainda está pendente? $TAC.US
$SOON