Ursprünglich dachte ich, dass es bei @NewtonProtocol vor allem um programmierbare Compliance geht. Nachdem ich mehr Zeit mit der Architektur verbracht hatte, stellte ich jedoch fest, dass ich weniger auf einzelne Policies achtete und mehr darauf, wo diese Policies tatsächlich verortet sind. Dieser Wandel veränderte, wie ich das Protokoll betrachtete.

Das Design trennt Autorisierung von der Anwendungsausführung, statt Geschäftsregeln direkt in jedem Smart Contract einzubetten. In Rego geschriebene Policies definieren die Autorisierungslogik, während einzelne Anwendungen ihre eigenen operativen Rahmenbedingungen über die PolicyClient-Konfiguration bereitstellen. Ausgabenlimits, genehmigte Empfänger, jurisdiktionsbezogene Einschränkungen und ähnliche Anforderungen werden zu strukturierter Laufzeitkonfiguration, statt dauerhaft in der Policy-Logik kodiert zu sein.

Dieser Unterschied wirkt bedeutsamer, als es zunächst scheint. Eine einzelne Policy kann weiterhin wiederverwendbar bleiben, während verschiedene Anwendungen innerhalb unterschiedlicher Autorisierungsgrenzen arbeiten, indem einfach die Konfiguration geändert wird. Die Policy beschreibt den Entscheidungsprozess. Die Anwendung liefert den Kontext. Diese Verantwortlichkeiten sind bewusst voneinander unabhängig.

Aber da ließ mich etwas nicht los.

Wiederverwendbarkeit funktioniert nur, wenn die Autorisierung an die exakten Annahmen gebunden bleibt, aus denen sie hervorgegangen ist. Newton löst das, indem es bei Änderungen an der PolicyClient-Konfiguration eine neue Policy-ID erzeugt. Attestierungen, die unter einer früheren Konfiguration erstellt wurden, gelten nicht mehr, sobald sich die referenzierte Policy-ID ändert. Die Autorisierung ist daher nicht nur an die Policy-Logik, sondern auch an die genaue Konfiguration gekoppelt, die zum Zeitpunkt der Genehmigung vorhanden war.

Das Design verschiebt die Grenze.

Statt den Anwendungscode jedes Mal zu ändern, wenn sich die betrieblichen Anforderungen weiterentwickeln, passen Entwickler Policies oder Konfigurationen an, während sie die Anwendungslogik beibehalten. Das kann die Wartung über mehrere Anwendungen hinweg vereinfachen, verlagert aber auch die Verantwortung hin zur Policy-Verwaltung. Die Konfiguration wird selbst Teil des Sicherheitsmodells statt nur ein Bereitstellungsdetail. Externe Informationen fügen eine weitere Verantwortungsebene hinzu. PolicyData-Oracles werden als isolierte WASM-Komponenten ausgeführt und liefern strukturierte Laufzeitdaten zurück, die Policies deterministisch auswerten. Die Laufzeit schränkt den Netzwerkzugriff absichtlich ein, und Fehler werden je nach ihrem Auftretensort unterschiedlich behandelt. Strukturierte Anwendungsfehler bleiben für die Policy-Auswertung sichtbar, während Ausführungsfehler zu DataProviderError-Ereignissen werden, die die Autorisierung vollständig stoppen, statt eine normale Entscheidung zu erzeugen.

Das beseitigt kein Vertrauen. Es verlagert es nur.

Das Ablaufdatum von Attestierungen führt zu einer weiteren operativen Entscheidung. Kurze Genehmigungsfenster verringern die Möglichkeiten für Replay, während längere Fenster den Nutzern mehr Flexibilität geben, bevor die Ausführung stattfindet. Keine der beiden Optionen sind Ablaufzeiträume, die Replay-Resistenz gegen Nutzbarkeit abwägen. Letztlich interagieren die Nutzer mit Attestierungen, deren Gültigkeit sowohl die Policy-Version als auch den Ausführungskontext widerspiegelt, statt allein den Vertragszustand.

So betrachtet wirkt Newton weniger darauf aus, die Smart-Contract-Logik zu ersetzen, als vielmehr darauf, dorthin zu verlagern, wo sich die Autorisierung entwickelt – nämlich als sich die Anforderungen an die Anwendung ändern.

Vereinfach das Verlegen der Policy-Weiterentwicklung weg von bereitgestellten Verträgen die langfristige Sicherheit, oder schafft es lediglich eine andere Ebene, in der sich operative Komplexität ansammelt?

$NEWT #Newt $SUI $ETH