Als ich mir dieses Mal die Asset-Überweisungsregeln von Dusk angesehen habe, ist mir stattdessen eine recht unscheinbare Handlung aufgefallen: Warum führt es zuerst eine Prüfung und Simulation durch, bevor die Transaktion wirklich eingereicht wird?
Früher, wenn ich On-Chain-Überweisungen betrachtet habe, war mein Standardablauf: signieren, senden, das Ergebnis abwarten.
Aber regulierte Assets funktionieren nicht so.
Ein Investor kann zwar einen Kontostand haben, aber nicht berechtigt sein, eine bestimmte Art von Asset zu halten; eine Adresse kann zwar Zahlungen empfangen können, aber nach den aktuellen Regeln ist es ihr dennoch nicht erlaubt, dieses Asset zu empfangen. Das offizielle Design von Dusk verlagert solche Berechtigungen und Transferprüfungen in den Prozess im Voraus: Transaktionen können noch vor ihrer offiziellen Einreichung geprüft oder simuliert werden.
> Ich glaube, dass diese Stufe das wirklich löst, nicht die vier Wörter „Transaktion fehlgeschlagen“, sondern verhindert, dass falsche Handlungen erst zu einer On-Chain-Tatsache werden.
Aus der Perspektive des Emittenten oder eines Handelsplatzes macht dieser Unterschied einen großen Unterschied.
Die klassische On-Chain-Logik ist eher so:
Zuerst einreichen.
Wenn es fehlschlägt, dann damit umgehen.
Dusk will stattdessen:
Zuerst prüfen.
Wenn es nicht mit den Regeln übereinstimmt, so weit wie möglich bereits vor dem Einreichen blockieren.
Das führt natürlich zu einer zusätzlichen Prüflogik, und die Asset-Übertragung sieht dann nicht nur nach Kontostand und Signatur aus wie bei gewöhnlichen Tokens.
Aber der Gewinn ist, dass viele Compliance-Entscheidungen, die früher durch manuelles Backoffice hätten nachgebessert werden müssen, im Voraus in den On-Chain-Prozess eingebettet werden.
Ich finde, genau das ist das eigentlich Spannende an Dusk.
Es ist nicht einfach nur das „Wertpapier“ auf die Kette zu bringen, sondern zu versuchen, dass „wer transferieren kann, wer empfangen kann und in welchen Fällen etwas abgelehnt werden sollte“ selbst zu einem Teil der Regeln für den Asset-Betrieb wird.
Wenn du der Emittent bist: Würdest du lieber eine zusätzliche vorgelagerte Prüfung akzeptieren, oder lieber den einfachen Ablauf beibehalten, wie bei gewöhnlichen Tokens—zuerst transferieren und dann Ausnahmen behandeln?@Dusk
#dusk $DUSK
Früher, wenn ich On-Chain-Überweisungen betrachtet habe, war mein Standardablauf: signieren, senden, das Ergebnis abwarten.
Aber regulierte Assets funktionieren nicht so.
Ein Investor kann zwar einen Kontostand haben, aber nicht berechtigt sein, eine bestimmte Art von Asset zu halten; eine Adresse kann zwar Zahlungen empfangen können, aber nach den aktuellen Regeln ist es ihr dennoch nicht erlaubt, dieses Asset zu empfangen. Das offizielle Design von Dusk verlagert solche Berechtigungen und Transferprüfungen in den Prozess im Voraus: Transaktionen können noch vor ihrer offiziellen Einreichung geprüft oder simuliert werden.
> Ich glaube, dass diese Stufe das wirklich löst, nicht die vier Wörter „Transaktion fehlgeschlagen“, sondern verhindert, dass falsche Handlungen erst zu einer On-Chain-Tatsache werden.
Aus der Perspektive des Emittenten oder eines Handelsplatzes macht dieser Unterschied einen großen Unterschied.
Die klassische On-Chain-Logik ist eher so:
Zuerst einreichen.
Wenn es fehlschlägt, dann damit umgehen.
Dusk will stattdessen:
Zuerst prüfen.
Wenn es nicht mit den Regeln übereinstimmt, so weit wie möglich bereits vor dem Einreichen blockieren.
Das führt natürlich zu einer zusätzlichen Prüflogik, und die Asset-Übertragung sieht dann nicht nur nach Kontostand und Signatur aus wie bei gewöhnlichen Tokens.
Aber der Gewinn ist, dass viele Compliance-Entscheidungen, die früher durch manuelles Backoffice hätten nachgebessert werden müssen, im Voraus in den On-Chain-Prozess eingebettet werden.
Ich finde, genau das ist das eigentlich Spannende an Dusk.
Es ist nicht einfach nur das „Wertpapier“ auf die Kette zu bringen, sondern zu versuchen, dass „wer transferieren kann, wer empfangen kann und in welchen Fällen etwas abgelehnt werden sollte“ selbst zu einem Teil der Regeln für den Asset-Betrieb wird.
Wenn du der Emittent bist: Würdest du lieber eine zusätzliche vorgelagerte Prüfung akzeptieren, oder lieber den einfachen Ablauf beibehalten, wie bei gewöhnlichen Tokens—zuerst transferieren und dann Ausnahmen behandeln?@Dusk
#dusk $DUSK