O detalhe do Crepúsculo que me fez olhar duas vezes não é a pilha ZK — é o que a carteira faz quando não sabe se uma transação blindada teve sucesso.
No Dusk Wallet v0.1.0, transações Phoenix ganharam rastreamento de “pending-nullifier reservation”. O changelog diz que essas reservas não são liberadas automaticamente após um timeout de um watcher, um status desconhecido, um status removido ou uma única falha em uma consulta ao mempool.
Por que manter deliberadamente os fundos presos após a incerteza?
Porque o Phoenix gasta notas. Se a carteira reutilizasse imediatamente o mesmo conjunto de notas gastáveis enquanto a primeira transação ainda poderia ser confirmada, ela poderia construir gastos blindados conflitantes. O Dusk também adicionou um mutex de gasto para impedir que envios Phoenix concorrentes sejam construídos contra as mesmas notas.
Fato: isso é uma lógica de segurança do lado da carteira, não uma nova regra de consenso. Minha interpretação: o Dusk está escolhendo uma UX conservadora em vez de disponibilidade otimista de saldo quando o estado da transação é ambíguo.
Essa troca importa. Sistemas de privacidade precisam de mais do que criptografia forte; o tratamento do estado da carteira precisa permanecer seguro quando a visibilidade da rede está incompleta.
Para o DUSK, estou observando se futuras versões da carteira podem encurtar esse período “incerto” sem enfraquecer a proteção. Com que agressividade uma carteira de privacidade deve desbloquear fundos quando o estado da cadeia é incerto?
@Dusk $DUSK #dusk
No Dusk Wallet v0.1.0, transações Phoenix ganharam rastreamento de “pending-nullifier reservation”. O changelog diz que essas reservas não são liberadas automaticamente após um timeout de um watcher, um status desconhecido, um status removido ou uma única falha em uma consulta ao mempool.
Por que manter deliberadamente os fundos presos após a incerteza?
Porque o Phoenix gasta notas. Se a carteira reutilizasse imediatamente o mesmo conjunto de notas gastáveis enquanto a primeira transação ainda poderia ser confirmada, ela poderia construir gastos blindados conflitantes. O Dusk também adicionou um mutex de gasto para impedir que envios Phoenix concorrentes sejam construídos contra as mesmas notas.
Fato: isso é uma lógica de segurança do lado da carteira, não uma nova regra de consenso. Minha interpretação: o Dusk está escolhendo uma UX conservadora em vez de disponibilidade otimista de saldo quando o estado da transação é ambíguo.
Essa troca importa. Sistemas de privacidade precisam de mais do que criptografia forte; o tratamento do estado da carteira precisa permanecer seguro quando a visibilidade da rede está incompleta.
Para o DUSK, estou observando se futuras versões da carteira podem encurtar esse período “incerto” sem enfraquecer a proteção. Com que agressividade uma carteira de privacidade deve desbloquear fundos quando o estado da cadeia é incerto?
@Dusk $DUSK #dusk