#dusk $DUSK
$GPS bereit, höher zu fliegen und noch höher — bald wird es den Himmel berühren. Aber die Zeile, die mich aufgehalten hat, war in @Dusk ’s W3sper-Dokumentation nicht das Thema Unterschreiben.

Es ging um die Warnung, dass ein Transaction Builder (Transaktions-Builder) keine Wallet ist.

W3sper stellt einer Anwendung Low-Level-Tools bereit, um sich mit Rusk zu verbinden, den Status abzufragen und Transaktionen zu erstellen. Aber wenn ein Client ohne eine Wallet-Erweiterung signieren möchte, muss er die Bausteine liefern, für die W3sper sich ausdrücklich nicht verantwortlich macht.

Dazu gehören ein speicherbarer, wiederherstellbarer Key-Storage und ein synchronisiertes Treasury hinter seinem „Bookkeeper“ — einschließlich der Kontostands- und Nonce-State-Daten, die benötigt werden, um eine gültige Transaktion zu bauen.

Ein neu generiertes Profil allein reicht nicht aus.

Es kann die Identität enthalten, die nötig ist, um ein Konto abzuleiten, aber es hat keinen synchronisierten „Bookkeeper“-Eintrag. Ohne den aktuellen Zustand kann der Transaktions-Builder die für die Übertragung erforderlichen Gelder oder die Nonce nicht zuverlässig bestimmen.

Das war die Grenze, die ich fast übersehen hätte.

Signieren zeigt, welcher Schlüssel eine Transaktion autorisiert hat.

Synchronisation sagt dem Signer, was er gerade jetzt gültig autorisieren kann.

Ich mag, dass W3sper die Bausteine offenlegt, ohne stillschweigend so zu tun, als würde es sicheren Storage und Wallet-Recovery heimlich lösen. Aber eine Headless-Anwendung, die diese Kontrolle wählt, übernimmt diese Verantwortlichkeiten eben auch explizit.

Macht die Trennung von Transaktionskonstruktion vom Wallet-Status W3sper zu sichererer Infrastruktur — oder macht sie Custom Signer leichter, die man falsch bauen kann??

#dusk @Dusk

Dusk W3sper’s Trennung ist…

$VELVET wieder ausgeschüttet — kompletter Desaster