Eine Sache ist mir aufgefallen, als ich in Dusk eingetaucht bin: Eine Wallet kann korrekt an eine Identität gebunden bleiben und dennoch eine Übertragung scheitern lassen, weil die für diese Übertragung zugrunde liegende Eignungsentscheidung nicht mehr aktuell ist.
Zunächst nahm ich an, das seien im Grunde nur ein Validierungsschritt.
Das sind sie nicht.
Je mehr ich mir die Architektur angesehen habe, desto mehr sah das wie ein Problem der Zustandsverwaltung aus und weniger wie ein Wallet-Problem.
Die Wallet-Bindung stellt eine kryptografische Beziehung zwischen einer Identität und einer Wallet her.
Diese Beziehung kann völlig gültig bleiben, während sich die externen Bedingungen ändern, die die Übertragungsberechtigung beeinflussen.
Stellen Sie sich eine am Montag gebundene Wallet vor. Am Dienstag ändert sich ein Compliance-Parameter außerhalb der Kette.
Die Identitätszuordnung wurde nicht widerrufen, die Wallet hat sich nicht geändert, und der Nutzer kann weiterhin nachweisen, dass er die Kontrolle darüber hat.
Aber wenn der Richtlinienzustand, der bei der Transaktionsbewertung verwendet wurde, nicht neu berechnet wurde, kann die Übertragung auf ein völlig anderes Ergebnis treffen. #dusk .
Dieser Unterschied ist leicht zu übersehen, weil die Benutzeroberfläche mehrere Prüfungen in einer einzigen Erfahrung verdichtet: „verifiziert“ bedeutet nicht unbedingt „jetzt gerade berechtigt“.
Im Hintergrund können mehrere unabhängige Zustandsübergänge liegen: Signaturprüfung, Identitätszuordnung, Status von Anmeldeinformationen oder Richtlinienstatus und die abschließende Autorisierung der Übertragung. @Dusk .
Die entscheidende technische Frage ist, wie Änderungen in externen Richtlinien in den Zustand hineinwirken, den die Transaktion tatsächlich auswertet.
Für $DUSK ergibt sich daraus ein spannender Zielkonflikt. Ein konservativer Richtlinienzustand kann das Risiko der Compliance-Belastung verringern, aber ein veralteter Zustand führt zu abgelehnten Übertragungen und zu operativen Reibungsverlusten.
Ein aggressiveres Aktualisieren verbessert die Aktualität, bringt jedoch zusätzlichen Rechenaufwand, Koordinationsaufwand und Abhängigkeiten von der Infrastruktur mit sich.
Was ich immer noch zu verstehen versuche, ist die Anreizschicht: Wenn eine gültige Wallet zu einer veralteten Berechtigung wird, wer ist dann wirtschaftlich und operativ dafür verantwortlich, diesen Zustand zu aktualisieren?
Zunächst nahm ich an, das seien im Grunde nur ein Validierungsschritt.
Das sind sie nicht.
Je mehr ich mir die Architektur angesehen habe, desto mehr sah das wie ein Problem der Zustandsverwaltung aus und weniger wie ein Wallet-Problem.
Die Wallet-Bindung stellt eine kryptografische Beziehung zwischen einer Identität und einer Wallet her.
Diese Beziehung kann völlig gültig bleiben, während sich die externen Bedingungen ändern, die die Übertragungsberechtigung beeinflussen.
Stellen Sie sich eine am Montag gebundene Wallet vor. Am Dienstag ändert sich ein Compliance-Parameter außerhalb der Kette.
Die Identitätszuordnung wurde nicht widerrufen, die Wallet hat sich nicht geändert, und der Nutzer kann weiterhin nachweisen, dass er die Kontrolle darüber hat.
Aber wenn der Richtlinienzustand, der bei der Transaktionsbewertung verwendet wurde, nicht neu berechnet wurde, kann die Übertragung auf ein völlig anderes Ergebnis treffen. #dusk .
Dieser Unterschied ist leicht zu übersehen, weil die Benutzeroberfläche mehrere Prüfungen in einer einzigen Erfahrung verdichtet: „verifiziert“ bedeutet nicht unbedingt „jetzt gerade berechtigt“.
Im Hintergrund können mehrere unabhängige Zustandsübergänge liegen: Signaturprüfung, Identitätszuordnung, Status von Anmeldeinformationen oder Richtlinienstatus und die abschließende Autorisierung der Übertragung. @Dusk .
Die entscheidende technische Frage ist, wie Änderungen in externen Richtlinien in den Zustand hineinwirken, den die Transaktion tatsächlich auswertet.
Für $DUSK ergibt sich daraus ein spannender Zielkonflikt. Ein konservativer Richtlinienzustand kann das Risiko der Compliance-Belastung verringern, aber ein veralteter Zustand führt zu abgelehnten Übertragungen und zu operativen Reibungsverlusten.
Ein aggressiveres Aktualisieren verbessert die Aktualität, bringt jedoch zusätzlichen Rechenaufwand, Koordinationsaufwand und Abhängigkeiten von der Infrastruktur mit sich.
Was ich immer noch zu verstehen versuche, ist die Anreizschicht: Wenn eine gültige Wallet zu einer veralteten Berechtigung wird, wer ist dann wirtschaftlich und operativ dafür verantwortlich, diesen Zustand zu aktualisieren?
