#dusk $DUSK @Dusk Zuvor dachte ich, dass eine Blockchain-Übertragung nur zwei mögliche Ergebnisse hat: Sie gelingt oder sie scheitert. „Erfolg“ bedeutete, dass der Wert übertragen wurde. „Fehlschlag“ bedeutete, dass etwas kaputtging. Doch je tiefer ich mir angesehen habe, wie Dusk regulierte Asset-Transfers beschreibt, desto mehr wurde mir klar, dass dieses Modell für Finanzmärkte zu grob ist.
Auf einer normalen Kette sagt dir eine abgelehnte Transaktion fast nichts. Das Gas ist ausgegangen, eine require-Anweisung ist ausgelöst, der Zustand hat sich unter dir verändert. Du bleibst im Unklaren, welches Problem es genau war.
Bei einem regulierten Asset ist diese Mehrdeutigkeit nicht akzeptabel. Die Dokumentation von Dusk beschreibt Übertragungsprüfungen, die mit klaren Gründen fehlschlagen, und — der Teil, den ich besonders interessant fand — Prüfungen, die simuliert werden können, bevor überhaupt eine Transaktion eingereicht wird.
Was ich daran besonders bemerkenswert fand, ist die Implikation dieses zweiten Punktes. Das bedeutet: Die Eignung ist nichts, das man entdeckt, indem man einen Transfer versucht und beobachtet, wie er scheitert. Man kann die Frage zuerst stellen und erhält eine Antwort, ohne überhaupt die Ledger zu berühren.
Das entspricht auch daran, wie die traditionelle Seite bereits funktioniert. Ein Broker sendet keine Order und hofft darauf, dass das Compliance-System es zulässt. Die Prüfung passiert vorher, und wenn ein Trade abgelehnt wird, kann jemand genau erklären, warum — die Gegenpartei war nicht akkreditiert, die Haltedauer war noch nicht abgelaufen, die Gerichtsbarkeit war eingeschränkt. „Abgelehnt“ ohne Begründung ist in einem regulierten Prozess keine verwertbare Antwort.
Scheitern wird zu Information statt zu einem Zufall. Und eine Ablehnung, die einen Grund mitliefert, ist vermutlich nützlicher als ein Erfolg, der keinen hat.
Ich kann immer noch nicht beurteilen, wie detailliert diese Gründe in der Praxis sind oder wie viel davon heute für eine Anwendung verfügbar ist, statt es lediglich als Designziel zu beschreiben.
Von hier aus habe ich begonnen, das Design anders zu sehen. Compliance On-Chain ist möglicherweise nicht in erster Linie dazu da, schlechte Transaktionen zu blockieren. Es könnte vielmehr darum gehen, das Ergebnis vorhersehbar zu machen, bevor sich irgendjemand darauf festlegt.
Auf einer normalen Kette sagt dir eine abgelehnte Transaktion fast nichts. Das Gas ist ausgegangen, eine require-Anweisung ist ausgelöst, der Zustand hat sich unter dir verändert. Du bleibst im Unklaren, welches Problem es genau war.
Bei einem regulierten Asset ist diese Mehrdeutigkeit nicht akzeptabel. Die Dokumentation von Dusk beschreibt Übertragungsprüfungen, die mit klaren Gründen fehlschlagen, und — der Teil, den ich besonders interessant fand — Prüfungen, die simuliert werden können, bevor überhaupt eine Transaktion eingereicht wird.
Was ich daran besonders bemerkenswert fand, ist die Implikation dieses zweiten Punktes. Das bedeutet: Die Eignung ist nichts, das man entdeckt, indem man einen Transfer versucht und beobachtet, wie er scheitert. Man kann die Frage zuerst stellen und erhält eine Antwort, ohne überhaupt die Ledger zu berühren.
Das entspricht auch daran, wie die traditionelle Seite bereits funktioniert. Ein Broker sendet keine Order und hofft darauf, dass das Compliance-System es zulässt. Die Prüfung passiert vorher, und wenn ein Trade abgelehnt wird, kann jemand genau erklären, warum — die Gegenpartei war nicht akkreditiert, die Haltedauer war noch nicht abgelaufen, die Gerichtsbarkeit war eingeschränkt. „Abgelehnt“ ohne Begründung ist in einem regulierten Prozess keine verwertbare Antwort.
Scheitern wird zu Information statt zu einem Zufall. Und eine Ablehnung, die einen Grund mitliefert, ist vermutlich nützlicher als ein Erfolg, der keinen hat.
Ich kann immer noch nicht beurteilen, wie detailliert diese Gründe in der Praxis sind oder wie viel davon heute für eine Anwendung verfügbar ist, statt es lediglich als Designziel zu beschreiben.
Von hier aus habe ich begonnen, das Design anders zu sehen. Compliance On-Chain ist möglicherweise nicht in erster Linie dazu da, schlechte Transaktionen zu blockieren. Es könnte vielmehr darum gehen, das Ergebnis vorhersehbar zu machen, bevor sich irgendjemand darauf festlegt.