#newt $NEWT @NewtonProtocol #NEWT
i ch dachte, der schwierigste Teil beim Aufbau sicherer Automatisierung sei das Schreiben perfekter Policy-Logik. In letzter Zeit denke ich jedoch, dass das nur die halbe Herausforderung ist.
Was mir an Newton Protocol auffiel, ist, dass es wiederverwendbare Rego-Policy-Logik von der Konfiguration trennt, die an einen PolicyClient angehängt ist. Die Logik bleibt konsistent, während anwendungsspezifische Werte wie Exposure-Limits, Schwellenwerte und genehmigte Listen über data.params als flaches JSON übergeben werden.
Es erinnert mich ans Fahren auf verschiedenen Straßen. Die Verkehrsregeln bleiben gleich, egal ob man in einer belebten Stadt oder auf einer ruhigen Autobahn unterwegs ist, aber die Geschwindigkeitsbegrenzung ändert sich, weil sich die Umgebung ändert. Du schreibst das Gesetz nicht neu, du passt das Limit an.
Newton wendet eine ähnliche Denkweise auf Onchain-Automatisierung an.
Ein Detail, das ich besonders interessant fand, ist expireAfter. Es lässt die Parameter nicht verfallen. Stattdessen definiert es das Ausführungsfenster für eine Attestation. Mach das Fenster zu kurz, und legitime Ausführungen könnten ihre Chance verpassen. Mach es zu lang, und du erhöhst die Zeitspanne für verzögerte Ausführungen. Sicherheit ist eine Balance, keine feste Zahl.
Dann gibt es setPolicy(PolicyConfig). Jede Aktualisierung erzeugt eine brandneue policyId, sodass die vorherige Konfiguration veraltet ist, statt still und leise ersetzt zu werden. Das ist eine kleine Designentscheidung mit großen Auswirkungen auf die Auditierbarkeit.
Je mehr ich über Newton lerne, desto weniger denke ich, dass die Sicherheit von Policies nur etwas mit Code zu tun hat.
Vielleicht lautet die eigentliche Frage: Sollten wir mehr Zeit damit verbringen, die Regeln zu prüfen – oder die Parameter, die festlegen, wie diese Regeln in der realen Welt funktionieren?
#Newt
i ch dachte, der schwierigste Teil beim Aufbau sicherer Automatisierung sei das Schreiben perfekter Policy-Logik. In letzter Zeit denke ich jedoch, dass das nur die halbe Herausforderung ist.
Was mir an Newton Protocol auffiel, ist, dass es wiederverwendbare Rego-Policy-Logik von der Konfiguration trennt, die an einen PolicyClient angehängt ist. Die Logik bleibt konsistent, während anwendungsspezifische Werte wie Exposure-Limits, Schwellenwerte und genehmigte Listen über data.params als flaches JSON übergeben werden.
Es erinnert mich ans Fahren auf verschiedenen Straßen. Die Verkehrsregeln bleiben gleich, egal ob man in einer belebten Stadt oder auf einer ruhigen Autobahn unterwegs ist, aber die Geschwindigkeitsbegrenzung ändert sich, weil sich die Umgebung ändert. Du schreibst das Gesetz nicht neu, du passt das Limit an.
Newton wendet eine ähnliche Denkweise auf Onchain-Automatisierung an.
Ein Detail, das ich besonders interessant fand, ist expireAfter. Es lässt die Parameter nicht verfallen. Stattdessen definiert es das Ausführungsfenster für eine Attestation. Mach das Fenster zu kurz, und legitime Ausführungen könnten ihre Chance verpassen. Mach es zu lang, und du erhöhst die Zeitspanne für verzögerte Ausführungen. Sicherheit ist eine Balance, keine feste Zahl.
Dann gibt es setPolicy(PolicyConfig). Jede Aktualisierung erzeugt eine brandneue policyId, sodass die vorherige Konfiguration veraltet ist, statt still und leise ersetzt zu werden. Das ist eine kleine Designentscheidung mit großen Auswirkungen auf die Auditierbarkeit.
Je mehr ich über Newton lerne, desto weniger denke ich, dass die Sicherheit von Policies nur etwas mit Code zu tun hat.
Vielleicht lautet die eigentliche Frage: Sollten wir mehr Zeit damit verbringen, die Regeln zu prüfen – oder die Parameter, die festlegen, wie diese Regeln in der realen Welt funktionieren?
#Newt