Als ich zum ersten Mal mit programmierbarer Autorisierung anfing, nahm ich an, dass das Ändern einer Regel das Ändern des Smart Contracts bedeuten würde, der sie durchsetzt. Das schien unvermeidlich.
Wenn ein Tresor seine maximale Exponierung senkte, eine eingeschränkte Adresse hinzufügte, einen zulässigen Risikowert änderte oder eine neue Compliance-Bedingung einführte, müsste der Vertrag, der den Tresor schützt, sicherlich neu geschrieben und erneut bereitgestellt werden.
Je tiefer ich in @NewtonProtocolMainnet Beta hineinschaute, desto mehr begann sich diese Annahme verkehrt anzufühlen. Newton trennt die zu schützende Anwendung von der Richtlinie, die entscheidet, was die Anwendung tun darf.
Wie eine Newton-Policy die Intention einer Transaktion bewertet
Eine Newton-Policy bewertet eine Transaktionsintention mithilfe von drei verschiedenen Arten von Informationen:
die Transaktion selbst
Konfigurierbare Werte unter „data.params
Live-Informationen, die von Daten-Orakeln unter „data.wasm“ zurückgegeben werden
Die Policy kann daher dieselbe angeforderte Aktion mit sich ändernden Schwellen, Allowlists, Identitätsergebnissen, Preisen oder Risikosignalen vergleichen, ohne all diese Logik direkt in den Anwendungskontrakt zu schieben.
Was bleibt dauerhaft?
Diese Unterscheidung klingt technisch. In Wahrheit verändert sie, was dauerhaft bestehen bleiben muss.
Die Durchsetzungsgrenze kann mit der Anwendung verbunden bleiben, während sich die Regeln hinter dieser Grenze weiterentwickeln. In der eigenen Dokumentation von Newton werden Policies als aktualisierbar beschrieben, ohne dass der geschützte Vertrag erneut bereitgestellt werden muss, während die Ankündigung zum Mainnet Beta Beispiele nennt, etwa eine überarbeitete Schwelle oder eine neue Anforderung an Sanktionen, die ohne Umschreiben des Anwendungskontrakts wirksam werden.
Was meine Aufmerksamkeit geweckt hat, ist, dass Newton nicht wirklich zwischen unveränderlichem Code und flexibler Policy auswählt. Es versucht, jedem davon eine unterschiedliche Aufgabe zu geben:
Der Anwendungskontrakt: definiert, wo die Autorisierung stattfinden muss.
Die Policy definiert, welche Bedingungen aktuell erfüllt sein müssen.
Oracle-Daten: können sich für jede Transaktion unterscheiden.
Aber das Orakel, die Policy und der Smart Contract müssen nicht alle gleichzeitig geändert werden. Der Smart Contract selbst kann über Jahre hinweg bestehen bleiben. Eine Risikoschwelle könnte sich nächsten Monat ändern. Ein Ergebnis einer Sanktion oder ein Signal zur Marktgesundheit könnte sich ändern, bevor die nächste Transaktion eintrifft. Wenn man alle drei hart in denselben Vertrag eincodiert, würde der langsamste Teil des Systems für Informationen verantwortlich gemacht, die sich viel schneller ändern.
Newton trennt sie auseinander. Das könnte wichtiger sein, als es zuerst den Anschein hat.
Ein präziseres Governance-Problem
Beim traditionellen Smart-Contract-Design wird Upgradefähigkeit oft wie ein Problem auf Vertragsebene behandelt. Entweder der Vertrag ist fest, oder jemand hat die Erlaubnis, ihn zu aktualisieren.
Newton führt zwischen diese beiden Entscheidungen eine zusätzliche Ebene ein. Die geschützte Anwendung kann stabil bleiben, während die Autorisierungsbedingungen für bestimmte Aktionen separat angepasst werden.
Damit hört die Frage auf zu sein: Kann dieser Vertrag aktualisiert werden?
Und wird zu: Welche Teile des Autorisierungsprozesses dürfen sich ändern, wer kontrolliert diese Änderungen und welche Teile bleiben dauerhaft mit der Ausführung verbunden?
Das ist viel eher ein präziseres Governance-Problem.
Der Trade-off der Flexibilität
Flexibilität bedeutet nicht immer mehr Sicherheit. Eine Policy, die sich schnell aktualisiert, kann sich an neue Gesetze, Marktveränderungen oder Sicherheitsbedrohungen anpassen. Aber sie kann auch die Regeln ändern, die die Nutzer ursprünglich akzeptiert haben.
Das Senken einer Risikogrenze kann Kapital schützen.
Stilles Erweitern einer Allowlist oder Abschwächen einer Sicherheitsanforderung könnte das Gegenteil bewirken.
Die Gefahr verschwindet nicht, nur weil die Policy vom Vertrag getrennt ist; sie verlagert sich hin zur Policy-Governance.
Wer darf die Parameter aktualisieren?
Wie sichtbar ist die Änderung?
Können Nutzer die aktuell die Anwendung schützende Policy inspizieren?
Sind frühere Versionen noch verständlich, nachdem eine neue sie ersetzt?
Diese Fragen werden genauso wichtig wie die Rego-Logik selbst. Genau an diesen Punkt komme ich immer wieder zurück.
Fazit: Dauerhaftigkeit der Durchsetzung
Newton macht finanzielle Regeln nicht dauerhaft. Echte Compliance-Anforderungen, Risikotoleranzen und Sicherheitsbedingungen ändern sich dafür zu oft.
Was es dauerhaft festzulegen versucht, ist die Anforderung, dass geschützte Aktionen immer durch Autorisierung laufen müssen
Die Regel kann sich ändern
Die Daten können sich ändern.
Die Schwelle kann sich ändern.
Aber die Anwendung darf nicht still aufhören, um Erlaubnis zu bitten.
Für mich ist das eine interessantere Form von Konsistenz als das dauerhafte Hardcoding jeder Regel. Newton friert die Policy nicht ein. Es fixiert den Punkt, an dem Policy eine Rolle spielen muss.
