Im Handelsprozess von Dusk gibt es einen sehr entscheidenden, aber oft übersehenen Schritt: Wie das System mit einer Transaktion umgeht, wenn die Beweisgenerierung fehlschlägt oder die Validierung nicht bestanden wird. Dies ist kein Randproblem, sondern eines der Kernelemente, das entscheidet, ob Dusk wirklich regulierte Vermögenswerte akzeptieren kann.
Bei Dusk bedeutet ein gescheiterter Handel nicht "halb ausgeführt und dann zurückgerollt", sondern wird bereits vor dem Zustandetransfer blockiert. Wenn ein Benutzer oder ein Vertrag eine Transaktion initiiert, verlangt das System zunächst die Generierung eines Beweises, um nachzuweisen, dass diese Transaktion allen aktuellen Regeln entspricht. Solange der Beweis nicht generiert werden kann oder der generierte Beweis die On-Chain-Validierung nicht besteht, wird diese Transaktion nicht in die Ausführungsphase eintreten und keinen Zustand ändern.
Der entscheidende Punkt hier ist: Das Scheitern selbst hat eine Struktur. Ein Beweisfehler ist kein vages "ungültig", sondern entspricht dem Nichterfüllen spezifischer Bedingungen. Zum Beispiel, wenn ein Vermögenswert noch in der Sperrfrist ist, ein Konto nicht die Berechtigung für den aktuellen Vermögenswert hat, oder eine Regel nach einer Aktualisierung ausdrücklich verboten wurde. Diese Misserfolge sind nicht zufällig, sondern stehen in direktem Zusammenhang mit spezifischen Regeln.
Warum ist dieser Punkt bei Dusk besonders wichtig? Weil in einem System für regulierte Vermögenswerte die Aussage "Transaktion abgelehnt" selbst ein Verhalten ist, das erklärt und geprüft werden muss. Das System muss in der Lage sein, zu antworten: Warum wurde diese Transaktion abgelehnt, welche Regel trat in Kraft, und wann trat die Ablehnung ein? Wenn eine Transaktion einfach fehlschlägt, ohne eine klare Regelzuordnung, ist eine nachfolgende Compliance-Prüfung nahezu unmöglich.
Dusk verfolgt den Ansatz, auch das "Scheitern" in den überprüfbaren Prozess einzubeziehen. Obwohl gescheiterte Transaktionen den Status von Vermögenswerten oder Konten nicht ändern, müssen die Gründe für das Scheitern auf Regelbasis reproduzierbar sein. Das bedeutet, dass die Ausdrucksweise der Regeln ausreichend klar sein muss, und die Beweisbeschränkungen müssen ausreichend detailliert sein, sonst können Entwickler und Nutzende nicht unterscheiden, ob es sich um einen logischen Fehler, einen Regelkonflikt oder einen ausgelösten Compliance-Beschränkung handelt.
Dieses Design zwingt alle Regeln dazu, Bedingungen zu sein, die "bewiesen und widerlegt" werden können. Wenn die Regeln unklar geschrieben sind, kann der Beweis nicht stabil generiert werden; wenn der Beweis instabil ist, wird der Transaktionspfad häufig unterbrochen.
