Ich hatte heute früher einen fehlgeschlagenen Vorgang bei einer Transaktion – völlig unabhängig von einem anderen Projekt. Irgendeine Genehmigung ist einfach nicht durchgegangen, ohne ersichtlichen Grund. Ich saß dann kurz ein bisschen genervt da, bin aber danach wie üblich einfach weiter mit meinem Tag.

Später, aus reiner Neugier, bin ich dann wieder in die Aufgabe zum Newton-Protokoll gegangen – und diese fehlgeschlagene Transaktion ließ mich die ganze Zeit nicht los, aus Gründen, mit denen ich nicht gerechnet hatte.

Denn hier ist das, was am Ende tatsächlich komisch gelandet ist: Ich glaube, ich habe jahrelang „Transaktion erfolgreich“ als das gute Ergebnis betrachtet und „Transaktion blockiert“ als das nervige. Jede Wallet-UX, jede Designentscheidung verstärkt das. Grünes Häkchen gut, roter Fehler schlecht. Aber wenn man sich Newtons ganzen Ansatz mit den Berechtigungsbereichen anschaut, habe ich angefangen zu überlegen, ob ich das vielleicht öfter vertauscht habe, als ich zugeben möchte. Eine blockierte Transaktion ist kein Versagen des Systems. Manchmal ist es das System, das genau die eine sinnvolle Sache macht, für die es gedacht ist.

Einfache Version des Mechanismus: Leute gehen davon aus, dass die Aufgabe einer Wallet darin besteht, auszuführen, was man anfordert — reibungslos, jedes Mal — und dass alles, was das unterbricht, Reibung oder ein Bug ist. Was bei umrahmten (scoped) Berechtigungen tatsächlich passiert, ist anders: Die Wallet fragt nicht „Kann ich das ausführen?“, sondern „Liegt das innerhalb dessen, was ich bereits zu erlauben zugestimmt habe?“. Wenn es nicht passt, ist die Ablehnung kein Glitch, sondern die funktionierende Berechtigungsebene wie vorgesehen. Ich hatte jede blockierte Aktion gedanklich unter „nervig“ verbucht, nie unter „korrekt“.

Aber hier ist der Teil, der mich stört — und ich bin damit noch nicht durch. Wenn eine Ablehnung plötzlich normal aussieht und sogar gut ist: Wie unterscheidet man dann zwischen „das wurde blockiert, weil es außerhalb des sicheren Rahmens lag“ und „das wurde blockiert, weil der Rahmen im ersten Schritt falsch gesetzt wurde“? Beide sehen aus Benutzersicht identisch aus — eine fehlgeschlagene Transaktion. Ich dachte, wenn ich eine Weile mit dieser Idee verweile, würde sich diese Unterscheidung für mich klären. Hat es nicht. Ich bin wirklich unsicher, wie eine Nutzerin oder ein Nutzer eine intelligente Ablehnung von einer kaputten unterscheiden soll, ohne in die Policy selbst hineinzuschauen — was die meisten Leute nicht tun.

Warum das wichtig ist, denke ich, hängt stark davon ab, wer sich die blockierte Transaktion ansieht. Für einen Builder oder jemanden, der die Berechtigungslogik prüft, ist eine Ablehnung Daten — nützlich, erwartet, manchmal der ganze Zweck. Für eine durchschnittliche Nutzerin oder einen durchschnittlichen Nutzer, die oder der einfach etwas Wiederkehrendes erledigen will, ist eine Ablehnung nur Reibung, Punkt. Diese Lücke zwischen den beiden Reaktionen auf exakt dasselbe Ereignis fühlt sich wichtiger an als der Mechanismus selbst.

Kurzer Moment — nach meiner eigenen fehlgeschlagenen Transaktion vorhin bin ich tatsächlich losgegangen und habe aus Gewohnheit den Genehmigungsumfang überprüft, weil ich einen Bug erwartete. War keiner. Ich hatte das damals vor Monaten einfach zu eng eingestellt und das vergessen. In meinem eigenen Fall waren also das „sicherste“ Ergebnis und das „nervige“ Ergebnis wörtlich dasselbe Ereignis — und nur meine eigene Unaufmerksamkeit entschied, wie es sich anfühlte.

Wie auch immer. Ich lande hier nicht auf einem sauberen Ergebnis. Vielleicht behalte ich einfach im Blick, ob die Ablehnungsnachrichten sich weiterentwickeln, um sich tatsächlich zu erklären, oder ob sie so vage bleiben wie jetzt.

@NewtonProtocol #Newt $NEWT