#dusk Quando eu estava pesquisando novamente a divulgação seletiva do Dusk, minha atenção foi, aos poucos, saindo de “prova” e indo para “chave”.
Quando as pessoas falam de privacidade, o foco quase todo é se a prova de conhecimento zero consegue esconder valores e relações.
Mas no Phoenix de @Dusk , o que realmente controla “quem pode ver” é a viewing key.
A note criptografada oculta os detalhes da transação; a viewing key, por sua vez, funciona como uma chave de observação que pode ser concedida de forma direcionada — entregue ao auditor, ela permite ver exatamente aquele trecho do registro.
Essa arquitetura é muito elegante.$BTC
O outro lado da elegância é que a própria chave vira um novo ponto de risco.
Uma viewing key, uma vez entregue, é difícil de recolher.
Depois que a auditoria termina, a chave ainda está nas mãos do outro — ele passa a ter, para sempre, acesso de visibilidade ao histórico?
Se a chave vazar, o atacante não obtém apenas ativos, mas algo ainda mais sensível do que eles: o histórico completo das transações.
Se as permissões forem amplas demais, a privacidade só troca de porta e vaza; se forem estreitas demais, o processo de conformidade trava.
Por isso, quando olho para a privacidade de #dusk , não me limito mais a perguntar se o sistema de provas é seguro.
Me preocupo mais com três coisas no nível operacional: se a viewing key consegue ser concedida com autorização mínima por intervalos de tempo ou por registro; se as chaves podem ser revogadas ou rotacionadas; e se a própria ação de divulgação deixa logs rastreáveis.
A maturidade real da tecnologia de privacidade não está em conseguir esconder o quanto.
Está em, quando você é forçado a entregar parte da visibilidade, conseguir controlar com precisão aquela parte e conseguir recolhê-la depois.
$DUSK Para servir instituições, o que a instituição teme não é nunca ver — e sim “as pessoas certas terem visto demais e por tempo demais”.
Os limites de gerenciamento dessa chave foram realmente desenhados com seriedade?
#dusk @Dusk $DUSK