Ich habe eine Weile darüber nachgedacht, wofür @NewtonProtocol -Operatoren tatsächlich verantwortlich sind, sobald eine Richtlinienaufgabe sich durch das Netzwerk bewegt.
Zunächst wirkte die Antwort ganz einfach.
Operatoren werten die Richtlinie aus.
Sie prüfen die erforderlichen Bedingungen.
Sie leisten Unterschriften für den endgültigen Beweis.
Einfach.
Doch je mehr ich mir den Ausführungsfluss von Newton ansah, desto schwieriger wurde es, die Genehmigung der Richtlinie und die operative Verantwortung als dasselbe zu behandeln.
Denn Newtons Architektur scheint sie sehr sorgfältig voneinander zu trennen.
Eine Richtlinienaufgabe kann eine Bewertung bestehen.
Die nachgelagerte Aktion kann dennoch fehlschlagen.
Dieser Unterschied ist viel bedeutsamer, als ich zuerst dachte.
Newtons dokumentierter Ablauf trennt die Richtlinienbewertung von der Transaktionsausführung über mehrere Komponenten hinweg. Operatoren rufen die erforderlichen Daten ab, bewerten die Rego-Richtlinie und leisten BLS-Signaturen für einen aggregierten Nachweis, der bestätigt, dass die ausgewerteten Bedingungen erfüllt waren.
Ein PolicyClient kann dann den aggregierten Nachweis verifizieren, bevor er die geschützte Transaktion oder Operation fortsetzt.
Auf den ersten Blick ist es leicht, sich diesen gesamten Ablauf gedanklich zu einer einzigen Idee zusammenzudrücken:
„Das Netzwerk hat die Aktion genehmigt.“
Doch diese Einordnung verschweigt stillschweigend eine wichtige Grenze.
Das Operatorennetzwerk bewertet, ob die definierten Richtlinienbedingungen zum Zeitpunkt der Bewertung erfüllt waren.
Es übernimmt nicht automatisch die Verantwortung für alles, was danach geschieht.
Das klingt offensichtlich, bis man den Lebenszyklus der Ausführung genauer verfolgt.
Ein nachgelagerter Vertrag kann dennoch zurückrollen.
Eine externe Abhängigkeit kann dennoch ausfallen.
Eine Transaktion kann dennoch aus Gas laufen.
Ein erforderlicher Dienst kann dennoch vorübergehend nicht verfügbar sein.
Die Richtlinienbewertung kann weiterhin gültig bleiben, während das operative Ergebnis später irgendwo entlang des Ausführungspfads bricht.
Auffällig war nicht das Vorhandensein von Fehlern.
Verteilte Systeme enthalten immer Fehlergrenzen.
Auffällig war, wo Newton offenbar die Verantwortung für diese Ausfälle verortet.
Das Richtliniennetzwerk beweist, dass die Operatoren den definierten Regelumfang ausgewertet und sich kollektiv über das Bewertungsergebnis verständigt haben.
Doch die operative Verantwortung verbleibt weiterhin teilweise in der umgebenden Anwendungsumgebung, der Implementierung des PolicyClient, den nachgelagerten Verträgen, den Infrastrukturabhängigkeiten, den Ausführungsannahmen sowie der Logik, die all dies miteinander verbindet.
Das schafft eine klarere Trennung, als ich zunächst erwartet hatte.
Die kollektive Bewertung zentralisiert nicht automatisch die operative Haftung.
Ich komme immer wieder auf diesen Unterschied zurück.
Denn moderne Infrastruktursysteme verwischen diese Grenzen häufig miteinander.
Nutzer sehen eine genehmigte Aktion und gehen davon aus, dass der gesamte Workflow selbst durchgehend vertrauenswürdig geworden ist.
Doch Newtons Architektur wirkt in dieser Hinsicht noch genauer.
Die Bewertungsebene beweist, dass die definierten Richtlinienbedingungen während der Bewertung erfüllt waren.
Es garantiert nicht, dass jede nachgelagerte Abhängigkeit, jede Ausführungsumgebung oder jedes externe System danach weiterhin korrekt funktioniert.
Das sind unterschiedliche Sicherheitsfragen.
Und ehrlich gesagt: Getrennt halten könnte für Infrastruktursysteme langfristig gesünder sein.
Denn sobald Richtlinienbewertung, Ausführungsumgebungen, externe Abhängigkeiten und die Logik der Anwendung beginnen, kontinuierlich miteinander zu interagieren, kann das so zu tun, als würden sie identische Verantwortungsgrenzen teilen, noch mehr Verwirrung stiften.
Vor allem, sobald adaptive Systeme beginnen, Aktionen schneller zu koordinieren, als Menschen jeden einzelnen operativen Schritt in Echtzeit manuell prüfen können.
Ein gültiges Richtlinienergebnis kann dennoch in eine ungesunde Ausführungsumgebung gelangen.
Eine korrekt bewertete Aufgabe kann dennoch von unzuverlässiger nachgelagerter Infrastruktur abhängen.
Eine genehmigte Operation kann dennoch fehlschlagen, weil sich die umgebenden Bedingungen nach dem Zeitpunkt der Bewertung geändert haben.
Das Netzwerk kann Bedingungen validieren.
Das kann die Realität um sie herum nicht einfrieren.
Das fühlt sich an wie einer der wichtigsten Unterschiede, der sich in Newtons Architektur versteckt.
Und es verändert auch, wie die Verantwortung Nutzern kommuniziert werden muss, die auf diesen Systemen aufbauen.
Der Konsens über den Operatoren kann belegen, dass eine Richtlinie korrekt bewertet wurde.
Es erklärt nicht automatisch, wohin sich die operative Verantwortung verlagert, sobald die Ausführung die Bewertungsgrenze verlässt und in den weiteren Lebenszyklus der Anwendung übergeht.
Das ist nicht notwendigerweise ein Mangel.
In vielerlei Hinsicht könnte es ein ehrlicheres Infrastrukturbild sein.
Die verteilte Bewertung von Richtlinien kann Annahmen über mangelndes Vertrauen im Hinblick auf Autorisierungsentscheidungen reduzieren, ohne so zu tun, als würde kryptografische Übereinstimmung magisch jedes betriebliche Risiko aus dem Rest des Systems entfernen.
Trotzdem erzeugt die Trennung wichtige Fragen zur Infrastruktur.
Wenn eine nachgelagerte Abhängigkeit nach der Richtlinienfreigabe ausfällt, wie sollten Anwendungen diesen Unterschied den Nutzern kommunizieren?
Wo sollte die Verantwortung für Retries angesiedelt sein?
Wie viel operative Vertrauenswürdigkeit liegt noch außerhalb der bewerteten Richtliniengrenze?
Und sobald autonome Finanzsysteme beginnen, Aktionen kontinuierlich über mehrere Umgebungen hinweg zu koordinieren: Werden Nutzer klar verstehen, welche Ebene tatsächlich fehlschlug?
Newtons Architektur scheint eine Frage sehr sorgfältig zu beantworten:
ob Richtlinienbedingungen gemeinsam bewertet und verifiziert wurden.
Die schwierigere Frage beginnt möglicherweise erst danach.
Wohin verlagert sich die operative Verantwortung tatsächlich, sobald verifiziertes Ausführen in die reale Welt eintritt?