Ich würde zögern, einer finanziellen Entscheidung zu vertrauen, die ich kryptografisch verifizieren kann, die ich jedoch nicht sinnvoll in Frage stellen kann.
Nehmen wir an, meine Transaktion wird vor der Abwicklung abgelehnt. Meine Identität bleibt verborgen, die privaten Compliance-Daten erscheinen niemals onchain, und das System erstellt einen Nachweis, dass die erforderliche Richtlinienprüfung korrekt ausgeführt wurde.
Aus datenschutzrechtlicher Sicht könnte das eine Erfolgsgeschichte sein.
Aus meiner Perspektive als die Person, deren Handlung blockiert wurde, bleibt eine Frage:
Was soll ich als Nächstes tun?
Dieses Spannungsfeld interessiert mich an @NewtonProtocol.
Newton Mainnet Beta und VaultKit bringen Autorisierung näher an die Ausführung. Anstatt sich nur auf Warnungen im Frontend zu verlassen oder Transaktionen nach der Bewegung von Mitteln zu prüfen, kann eine Anwendung definierte Policies vor dem Settlement prüfen und eine signierte Bestätigung nutzen, um zu zeigen, dass die Auswertung stattgefunden hat.
Ich glaube, diese Richtung adressiert eine echte Schwäche im automatisierten Onchain-Finanzwesen.
Aber privatsphärenschonende Durchsetzung kann ein neues Problem erzeugen, wenn das Ergebnis nicht mehr verständlich wird.
## „Nicht autorisiert“ ist ein Ergebnis, nicht eine Erklärung
Eine Transaktion kann fehlschlagen, weil ihr Betrag eine Grenze überschreitet.
Das kann eine nicht genehmigte Ressource betreffen.
Das erforderliche Credential ist möglicherweise abgelaufen.
Die Policy kann sich geändert haben.
Eine externe Datenquelle ist möglicherweise nicht verfügbar.
Die Transaktion wurde möglicherweise unter einer älteren Policy-Version bewertet.
All diese Situationen können zum selben sichtbaren Ergebnis führen: Die Ausführung schreitet nicht fort.
Doch dafür werden vollständig unterschiedliche Antworten benötigt.
Wenn ich ein Transaktionslimit überschritten habe, kann ich möglicherweise den Betrag reduzieren.
Wenn ein Credentials abgelaufen ist, muss ich es möglicherweise erneuern.
Wenn ein Preisfeed fehlgeschlagen ist, kann ein späterer Retry das Problem lösen.
Wenn dem Vertragspartner die Durchführung untersagt ist, sollte das Wiederholen der Transaktion überhaupt nicht helfen.
Ein System, das im Namen der Privatsphäre jede Unterscheidung verbirgt, mag sensible Daten schützen, kann aber dazu führen, dass der Nutzer ein legitimes Problem nicht korrigieren kann.
Für mich ist das keine vollständige Autorisierung.
Durchsetzung ohne nutzbare Erklärung.
## KI-Agenten machen eine vage Ablehnung gefährlicher
Dieses Problem wird noch ernster, wenn der Anfragende ein automatisierter Agent statt einer Person ist.
Ein Mensch kann eine unklare Ablehnung sehen und innehalten.
Ein KI-Agent kann die gleiche Route erneut versuchen, die Menge zufällig reduzieren, Vertragspartner wechseln oder einen anderen Pfad suchen, ohne zu verstehen, warum die ursprüngliche Aktion fehlgeschlagen ist.
Dieses Verhalten kann unnötige Aktivität erzeugen und sogar das Risiko erhöhen.
Wenn die Policy die Aktion ablehnte, weil der Agent ein Ausgabenlimit erreicht hat, sollte das Umschalten von „Venues“ diese Beschränkung nicht umgehen können.
Wenn der Fehler von einer vorübergehenden Unverfügbarkeit von Daten herrührte, ist es vielleicht unnötig, die Strategie komplett aufzugeben.
Wenn die Aktion blockiert wurde, weil sie die Exposition über das Mandat hinaus erhöht hat, sollte der Agent wissen, dass die richtige Antwort darin besteht, zu stoppen – nicht nach einer clevereren Route zu suchen.
Deshalb denke ich, dass eine privatsphärenbewusste Autorisierungsschicht mehr braucht als nur eine binäre Antwort.
Es braucht genug strukturiertes Feedback, damit der autorisierte Anfragende sicher reagieren kann.
Nicht der private Identitätsdatensatz.
Nicht die vollständige Compliance-Datei.
Nicht jede Regel innerhalb der Policy.
Genau die minimale Erklärung, die nötig ist, um die Kategorie des Fehlschlags und den erlaubten nächsten Schritt zu verstehen.
## Verifizierung und Erklärung sind unterschiedliche Aufgaben
Hier denke ich, dass die $NEWT thesis differenzierter wird.
Eine signierte Bestätigung kann helfen nachzuweisen, dass der Autorisierungsprozess einer definierten Logik gefolgt ist. Das ist wertvoller Beleg.
Aber der Nachweis, dass eine Prüfung korrekt ausgeführt wurde, ist nicht automatisch eine Erklärung der Entscheidung.
Das sind zwei unterschiedliche Funktionen.
Verifizierung fragt:
„Wurde die erforderliche Policy wie vorgesehen ausgewertet?“
Erklärung fragt:
„Welche Bedingung hat diese Aktion beeinflusst, und was kann der Anfragende legitimerweise dagegen tun?“
Ein starkes System braucht beides, während es je nach Partei unterschiedliche Informationen offenlegt.
Die öffentliche Chain benötigt möglicherweise nur den Nachweis, dass die Transaktion keine gültige Autorisierung erhalten hat.
Der Nutzer benötigt möglicherweise eine private Kategorien für den Grund und einen Weg zur Behebung.
Der KI-Agent benötigt möglicherweise maschinenlesbare Anweisungen wie: stoppen, später erneut versuchen, Risiko reduzieren, Credentials aktualisieren oder eine Prüfung anfordern.
Ein autorisierter Auditor benötigt möglicherweise tiefergehende Belege dafür, welche Policy-Version und welche Datenquelle verwendet wurden.
Ich glaube nicht, dass all das öffentlich sein sollte.
Ich denke, dass das alles existieren sollte, wenn es angebracht ist.
## Privatsphäre darf nicht das Recht entfernen, einen Fehler anzufechten
Policies und Datenquellen können falsch sein.
Ein Credential-Provider kann veraltete Informationen zurückgeben.
Ein Wallet kann falsch klassifiziert werden.
Eine Policy-Aktualisierung kann unbeabsichtigt legitime Aktivitäten blockieren.
Ein Entwickler kann eine Regel erstellen, deren tatsächliches Verhalten von dem vorgesehenen Zweck abweicht.
Wenn das System nur sagt „Autorisierung fehlgeschlagen“, hat der betroffene Nutzer keine sinnvolle Möglichkeit, eine gültige Einschränkung von einem Implementierungsfehler zu unterscheiden.
Das ist wichtig, weil automatisierte Durchsetzung Fehler endgültig wirken lassen kann.
Ein manuelles Compliance-Team kann einen ungewöhnlichen Fall erneut prüfen. Eine starre Policy-Engine führt einfach die Regel aus, die sie erhält.
Ich möchte die Effizienz programmierbarer Autorisierung, aber ich möchte nicht, dass Privatsphäre zur Ausrede für nicht anfechtbare Entscheidungen wird.
Für Anwendungen, die Newton-Infrastruktur nutzen, würde ich nach einem klaren Weg zur Anfechtbarkeit suchen:
Welche Policy-Version wurde angewendet?
Waren die erforderlichen Daten aktuell?
Stammte der Fehler von der Regel selbst oder von einer nicht verfügbaren Abhängigkeit?
Kann der Nutzer eine Überprüfung anfordern, ohne private Informationen öffentlich offenzulegen?
Kann ein Auditor das Ergebnis verifizieren, ohne unnötige Details für alle anderen offenzulegen?
Diese Fragen sind keine nebensächlichen Belange der Nutzererfahrung.
Sie sind Teil davon, ob Autorisierung Vertrauen verdient.
## Die Balance, die ich sehen möchte
Zu viel Offenlegung kann Identität, Risikostatus, Strategie oder institutionelle Beziehungen offenlegen.
Zu geringe Offenlegung kann die Policy-Durchsetzung zu einer Blackbox machen.
Der hilfreiche Mittelweg ist eine selektive Erklärung.
Das System sollte so viel offenbaren, dass die betroffene Partei das Problem verstehen und darauf reagieren kann, während sensible Belege auf die Parteien beschränkt bleiben, die sie wirklich benötigen.
Für mich ist das einer der wichtigsten Tests für #Newt, während Newton Mainnet Beta sich entwickelt.
Ich beobachte nicht nur, ob Anwendungen Transaktionen vor dem Settlement blockieren können.
Ich beobachte, ob ein legitimer Nutzer eine Ablehnung verstehen kann, ohne das System dazu zu zwingen, private Informationen zu veröffentlichen.
Ich beobachte, ob ein KI-Agent genügend Kontext erhält, um sicher zu stoppen, statt wiederholt dieselbe Grenze zu testen.
Und ich beobachte, ob eine falsche Entscheidung überprüft werden kann, ohne das Privatsphärenmodell um jede andere Transaktion herum zu schwächen.
Ein privater Nachweis ist wertvoll.
Eine verifizierbare Policy ist wertvoll.
Aber die finanzielle Autorisierung wird viel stärker, wenn die von der Entscheidung betroffene Person oder der betroffene Agent verstehen kann, welche Art von Grenze erreicht wurde.
Denn Privatsphäre soll den Grund vor unnötiger Offenlegung schützen.
Es sollte nicht den Grund für die Partei löschen, die ihn wirklich wissen muss.
