Ich habe gestern Abend @NewtonProtocol von Newton Mainnet Beta erneut durchgesehen, und diesmal ist mir die Multi-Oracle-Policy aufgefallen. Newton Protocol ermöglicht, dass eine Regel gleichzeitig auf mehrere Datenquellen zugreift: zum Beispiel erst das Vault-Risiko prüfen, dann eine Sanktions-Überprüfung durchführen und anschließend den Health-Status der Oracles checken; am Ende werden daraus ein Allow/Deny-Ergebnis und eine Attestation zusammengeführt. Für eine AI-driven Strategy und einen Agent Marketplace ist das deutlich zuverlässiger als nur einer Datenquelle zu vertrauen.$NEWT
Aber ich bin der offiziellen Empfehlung für Fail-Closed-Logik gefolgt und habe noch eine Ebene weitergedacht: Je mehr Datenquellen angebunden sind, desto vollständiger die Beurteilung – aber desto geringer kann auch die Systemverfügbarkeit sein. Wenn Entwickler jedes Oracle als „obligatorisch“ konfigurieren, führt schon ein Fehler oder Timeout eines einzelnen Oracles dazu, dass die gesamte Operation abgelehnt wird. Wenn dann noch Sicherheitsmodule ganz am Ende daraufsetzen, kann es zu dem Effekt kommen: „Die schwächste Abhängigkeit bestimmt die gesamte Kette“.
Ich habe das mal grob ausgerechnet. Angenommen, die Verfügbarkeit jedes Oracles liegt bei 99,5%, und eine Policy hängt gleichzeitig von 4 Oracles ab, dann beträgt die Wahrscheinlichkeit, dass alles durchgehend normal läuft, nur etwa 98%. Wenn ein automatisierter Agent täglich 10.000 Aufgaben ausführt, könnten theoretisch fast 200 Fälle allein wegen externer Abhängigkeiten nicht freigegeben werden. Für AI-Developer ist das nicht nur ein sporadischer Fehler – es bedeutet auch Kosten durch Retries, Support und das Verpassen von Ausführungsfenstern.
Ich habe einen Freund gefragt, der im Backend- und Risk-Control-Bereich arbeitet. Er meinte, dass klassische Systeme typischerweise Degradierung (Degradation) vorsehen: Wenn eine Preisdatenquelle ausfällt, wird auf eine Backup-Quelle umgeschaltet; bei Low-Risk-Operationen laufen dann zunächst nur die Basischecks. Aber wenn Newton bei allen Anomalien direkt „deny“ macht, ist es zwar sicherer – könnte aber auch normale Transaktionen gleich mit einfrieren. Wenn man Degradierung erlaubt, muss man zudem erneut beantworten: „Wenn wir eine Prüfung weglassen, gilt das noch als konform?“
Daher ist mein aktuelles Fazit zu Newton Mainnet Beta: Multi-Oracle ist sehr gut für große Vaults, RWA und Unternehmenszahlungen – also für Szenarien, bei denen man lieber langsam ist als etwas Falsches zuzulassen. Für automatisches Rebalancing, Sparpläne (DCA) und Hochfrequenzstrategien braucht man jedoch gestufte Regeln, statt dass alle Datenquellen in einem einzigen Votum alles verwerfen.
Als Nächstes sehe ich vor allem auf zwei Punkte: Erstens, ob eine Policy zwischen Kern-Oracles und unterstützenden Oracles unterscheiden kann. Zweitens, ob das System bei Ausfall einer Datenquelle automatisch auf eine Backup-Quelle umschalten kann und den Degradierungsprozess im Explorer dokumentiert. Verifizierbare Automatisierung heißt nicht nur, dass man mehr prüft – sondern auch, dass, wenn ein Prüfer ausfällt, das gesamte System nicht gleich mit stillsteht.#Newt
Aber ich bin der offiziellen Empfehlung für Fail-Closed-Logik gefolgt und habe noch eine Ebene weitergedacht: Je mehr Datenquellen angebunden sind, desto vollständiger die Beurteilung – aber desto geringer kann auch die Systemverfügbarkeit sein. Wenn Entwickler jedes Oracle als „obligatorisch“ konfigurieren, führt schon ein Fehler oder Timeout eines einzelnen Oracles dazu, dass die gesamte Operation abgelehnt wird. Wenn dann noch Sicherheitsmodule ganz am Ende daraufsetzen, kann es zu dem Effekt kommen: „Die schwächste Abhängigkeit bestimmt die gesamte Kette“.
Ich habe das mal grob ausgerechnet. Angenommen, die Verfügbarkeit jedes Oracles liegt bei 99,5%, und eine Policy hängt gleichzeitig von 4 Oracles ab, dann beträgt die Wahrscheinlichkeit, dass alles durchgehend normal läuft, nur etwa 98%. Wenn ein automatisierter Agent täglich 10.000 Aufgaben ausführt, könnten theoretisch fast 200 Fälle allein wegen externer Abhängigkeiten nicht freigegeben werden. Für AI-Developer ist das nicht nur ein sporadischer Fehler – es bedeutet auch Kosten durch Retries, Support und das Verpassen von Ausführungsfenstern.
Ich habe einen Freund gefragt, der im Backend- und Risk-Control-Bereich arbeitet. Er meinte, dass klassische Systeme typischerweise Degradierung (Degradation) vorsehen: Wenn eine Preisdatenquelle ausfällt, wird auf eine Backup-Quelle umgeschaltet; bei Low-Risk-Operationen laufen dann zunächst nur die Basischecks. Aber wenn Newton bei allen Anomalien direkt „deny“ macht, ist es zwar sicherer – könnte aber auch normale Transaktionen gleich mit einfrieren. Wenn man Degradierung erlaubt, muss man zudem erneut beantworten: „Wenn wir eine Prüfung weglassen, gilt das noch als konform?“
Daher ist mein aktuelles Fazit zu Newton Mainnet Beta: Multi-Oracle ist sehr gut für große Vaults, RWA und Unternehmenszahlungen – also für Szenarien, bei denen man lieber langsam ist als etwas Falsches zuzulassen. Für automatisches Rebalancing, Sparpläne (DCA) und Hochfrequenzstrategien braucht man jedoch gestufte Regeln, statt dass alle Datenquellen in einem einzigen Votum alles verwerfen.
Als Nächstes sehe ich vor allem auf zwei Punkte: Erstens, ob eine Policy zwischen Kern-Oracles und unterstützenden Oracles unterscheiden kann. Zweitens, ob das System bei Ausfall einer Datenquelle automatisch auf eine Backup-Quelle umschalten kann und den Degradierungsprozess im Explorer dokumentiert. Verifizierbare Automatisierung heißt nicht nur, dass man mehr prüft – sondern auch, dass, wenn ein Prüfer ausfällt, das gesamte System nicht gleich mit stillsteht.#Newt