Der nächste Angriffspunkt für Crypto ist möglicherweise kein Code.
Vielleicht handelt es sich um Konfiguration, die sich als Governance tarnt.
Die PolicyClient-Architektur des Newton Protocols stellt eine härtere Sicherheitsfrage: Nicht, ob die Policy-Logik korrekt ist, sondern wer die Autorität besitzt, zu definieren, was diese Logik bedeuten darf.
Die Rego-Policy kann weiterhin öffentlich, deterministisch, wiederverwendbar und unverändert bleiben. Doch ihr Durchsetzungs-Perimeter wird von flachen JSON-Werten umgeschrieben, die über data.params übergeben werden, ohne den Code anzurühren.
Das bedeutet: Identischer Policy-Code kann radikal unterschiedliche Berechtigungsregime über verschiedene Apps hinweg erzeugen.
Ein Eigentümer kann enge Schwellen für Trade-Volumina auferlegen, strikte Expositionsgrenzen und eng kuratierte Address-Allowlists. Ein anderer kann dieselbe Rego mit permissiven Parametern bereitstellen und das System „policy gesichert“ nennen.
Gleiche Logik. Unterschiedliche Souveränität.
expireAfter rotiert diese Parameter nicht, aktualisiert sie nicht und macht sie nicht ungültig. Es definiert lediglich das Ausführungsfenster einer Attestation.
Der Aufruf von setPolicy(PolicyConfig) erstellt eine neue policyId. Die vorherige ID wird veraltet, und die Validierung lehnt jede Attestation ab, deren policyId nicht mehr zur aktiven Konfiguration des PolicyClient passt.
So werden Konfigurationsänderungen kryptografisch sichtbar.
Doch Sichtbarkeit ist keine Durchdringung.
Die Control Plane ist von der Contract-Logik in eigentümergeführte Einstellungen, Update-Rechte und die Auswahl von Parametern verlagert worden.
Ist konfigurierbare Sicherheit wirklich stärker – oder wurde Governance einfach in JSON-Felder komprimiert, die die meisten Nutzer, Auditoren und Märkte niemals prüfen?
@NewtonProtocol
#newt $NEWT
Vielleicht handelt es sich um Konfiguration, die sich als Governance tarnt.
Die PolicyClient-Architektur des Newton Protocols stellt eine härtere Sicherheitsfrage: Nicht, ob die Policy-Logik korrekt ist, sondern wer die Autorität besitzt, zu definieren, was diese Logik bedeuten darf.
Die Rego-Policy kann weiterhin öffentlich, deterministisch, wiederverwendbar und unverändert bleiben. Doch ihr Durchsetzungs-Perimeter wird von flachen JSON-Werten umgeschrieben, die über data.params übergeben werden, ohne den Code anzurühren.
Das bedeutet: Identischer Policy-Code kann radikal unterschiedliche Berechtigungsregime über verschiedene Apps hinweg erzeugen.
Ein Eigentümer kann enge Schwellen für Trade-Volumina auferlegen, strikte Expositionsgrenzen und eng kuratierte Address-Allowlists. Ein anderer kann dieselbe Rego mit permissiven Parametern bereitstellen und das System „policy gesichert“ nennen.
Gleiche Logik. Unterschiedliche Souveränität.
expireAfter rotiert diese Parameter nicht, aktualisiert sie nicht und macht sie nicht ungültig. Es definiert lediglich das Ausführungsfenster einer Attestation.
Der Aufruf von setPolicy(PolicyConfig) erstellt eine neue policyId. Die vorherige ID wird veraltet, und die Validierung lehnt jede Attestation ab, deren policyId nicht mehr zur aktiven Konfiguration des PolicyClient passt.
So werden Konfigurationsänderungen kryptografisch sichtbar.
Doch Sichtbarkeit ist keine Durchdringung.
Die Control Plane ist von der Contract-Logik in eigentümergeführte Einstellungen, Update-Rechte und die Auswahl von Parametern verlagert worden.
Ist konfigurierbare Sicherheit wirklich stärker – oder wurde Governance einfach in JSON-Felder komprimiert, die die meisten Nutzer, Auditoren und Märkte niemals prüfen?
@NewtonProtocol
#newt $NEWT