Eine Kette von Schlüsseln wird neu generiert, aber das bedeutet nicht, dass das Wallet bereits wiederhergestellt ist. In den W3sper-Dokumenten von Dusk habe ich eine sehr harte Erinnerung gelesen: Nimm nicht einfach das neu generierte Profile, um eine Überweisung zu konstruieren, denn es besitzt noch keine synchronisierten Bookkeeper-Einträge. Dadurch erhält man nicht die benötigten Guthaben und den Nonce. W3sper beschreibt die Grenzen sehr klar: Der von dir signierte Client muss zusätzlich zum wiederherstellbaren Schlüssel-Speicher auch den synchronisierten Vermögensstatus pflegen – einschließlich des Nonce öffentlicher Konten und der geschützten Notes (shielded notes). Dieser Detailunterschied trennt „Ich habe den privaten Schlüssel“ von „Ich kann dieses Geld sicher ausgeben“ in zwei verschiedene Dinge.
Der Druck entsteht typischerweise nach einer Wiederherstellung. Wenn eine App lokale Daten löscht und anschließend die Identität neu generiert, aber die Seite noch das ursprüngliche Konto anzeigt, geht der Nutzer natürlich davon aus, dass alles wieder da ist. Wenn die Synchronisierung jedoch noch nicht abgeschlossen ist, kann die Überweisung nicht korrekt konstruiert werden. Das Vermögen ist nicht verschwunden, aber der Nutzer wird erst von einem Problem aufgehalten, das wie ein Guthaben- oder Netzwerkfehler aussieht. Wenn Entwickler nur die Schlüsselwiederherstellung umsetzen, aber keine Statuswiederherstellung anzeigen, bleibt die Such- und Fehlersuche bei den Nutzern und dem Support hängen. Das ist kein Mangel im Protokoll von $DUSK – im Gegenteil zeigt es, dass der ausgebbare Zustand von shielded Assets nicht durch reine Adressstrings ersetzt werden kann. @Dusk s Ökosystem muss „Identität wiedergefunden“ und „Geldstatus ist synchronisiert“ getrennt anzeigen und die Überweisung eindeutig blockieren, bis der zweite Punkt abgeschlossen ist. #dusk