Uma cadeia de chaves foi regenerada, mas isso não significa que a carteira já tenha sido restaurada. Vi no documento da W3sper da Dusk um aviso bem duro: não use diretamente o novo Profile gerado para construir uma transferência, porque ele não possui os registros do Bookkeeper após a sincronização; assim, não é possível obter o saldo e o nonce necessários. A W3sper descreve os limites com muita clareza: o cliente que assina por conta própria, além de manter o armazenamento de chaves recuperáveis, também precisa manter o estado sincronizado dos ativos, incluindo o nonce das contas públicas e as notes shielded. Esse detalhe separa “eu tenho a chave privada” de “eu consigo gastar com segurança este dinheiro”.
A pressão costuma acontecer após a recuperação. Se um aplicativo limpar os dados locais e regenerar a identidade, a página ainda pode exibir a conta original; naturalmente, o usuário vai achar que tudo voltou ao normal. Porém, enquanto a sincronização não tiver concluído, a transferência não consegue ser construída corretamente. Os ativos não desapareceram, mas o usuário fica preso primeiro em um problema que parece um saldo insuficiente ou falha de rede. Se desenvolvedores fizerem apenas a recuperação de chaves e não exibirem a recuperação do estado, o custo de investigação acaba ficando com o usuário e o suporte. Isso não é uma falha do protocolo do $DUSK ; pelo contrário, mostra que o estado “disponível para gastar” de ativos shielded não pode ser substituído por uma string de endereço. @Dusk O ecossistema precisa separar a exibição de “identidade recuperada” de “estado dos fundos sincronizado” e, antes de concluir o segundo, bloquear explicitamente a realização de transferências. #dusk