Letzter Nacht wurde ich von den von mir selbst festgelegten Risk-Controls ausgesperrt und musste eine halbe Stunde lang am Tresortor herumbasteln, bis man mich wieder durchließ. Ich starrte auf die Zeile mit der Meldung „Validierung fehlgeschlagen“, und der erste Gedanke, der mir durch den Kopf schoss, war: Zählt das als selbstverschuldeter Ärger?
Nachdem ich die Logs durchgegangen war, stellte sich heraus, dass mich genau das Setup von @NewtonProtocol mit der auf Rego basierenden automatischen Risk-Control gestoppt hatte. Letzte Woche hatte ich das Limit nach unten angepasst – und in der vergangenen Nacht hat dann ein AI-Agent einen hochfrequenten Refill-Antrag ausgelöst, der direkt abgefangen wurde. Effizient ist das wirklich. Aber das Gefühl, von selbst gebauten Käfigen eingeschlossen zu werden, ist auch irgendwie eigenartig.
Genau wegen dieses Vorfalls konnte ich mich dann wirklich hinsetzen und mir das Newton-Gesamtkonzept komplett von Grund auf durchdenken.
EigenLayer-Betreiber-Netzwerk als Fundament, TEE-Ausführungsumgebung als Rückversicherung, sowie eine kombinierte Validierung aus mehreren Off-Chain-Datenquellen: Die Idee ist, dass nach dem Einreichen erst die Bewertung durch den Betreiber erfolgt, dann ein Berechtigungsnachweis generiert und erst danach die Ausführung angestoßen wird. Auf den ersten Blick wirkt der gesamte Risk-Control-Loop makellos. Ehrlich gesagt macht mich jedoch gerade die ausgefeilte Konstruktion misstrauisch, wie sie sich in extremen Marktphasen schlägt. Mehr Off-Chain-Validierung bedeutet mehr Latenz – und wenn die Volatilität anzieht, kann der Sekundenunterschied zwischen Angebot und Ausführung schnell ein paar Prozentpunkte Verlust bedeuten. Die Offenlegung des Betreiber-Signatur-Ansatzes ist außerdem nicht detailliert genug, und Sicherheitsvorfälle in der TEE-Hardware-Historie kann ich mir auch mehrere auflisten. Beim Thema Privacy-Verification ist die Informationslage bislang zu dünn, als dass ich mich wirklich vollständig darauf verlassen könnte. Automatisches Risk-Management verlagert am Ende nur die Entscheidungsbefugnis von Institutionen zu Code – mehr Freiheit ist dadurch nicht zwingend wirklich gewonnen.
Trotzdem muss ich zugeben: In der Beta gibt es ein Design, das einen wunden Punkt tatsächlich trifft – komplexen Berechtigungs-Code in eine für Normalpersonen verständliche Autorisierungs-Checkliste zu übersetzen, das Risiko also nach vorne zu verlagern. Das gleicht auch die Schwäche aus, dass ZK-Nachweise zwar nur die Ausführung prüfen lassen, man aber die Autorisierungsgrenzen nicht durchschauen kann. Das ist auch der konkreteste Wert von $NEWT : Für Leute wie mich, die mit einem AI-Agent handeln wollen, aber Angst vor Fehltritten haben, gibt es wenigstens noch eine zusätzliche, gut lesbare Schutzebene.
Aber das Design für IPFS-Online-Updates der Regeln halte ich für einen versteckten Minenfall. Bei Agent-Iterationen können die Regeln still und leise Anpassungen an Transaktionslimits und dem Vertragsumfang vornehmen – wo sollte ein normaler Nutzer schon die Möglichkeit haben, Codeänderungen jede einzelne Zeile betreffend nachzuvollziehen? Wenn man einmal unaufmerksam ist, landet man unweigerlich in der Falle des passiven Blind-Signing. Wenn man das wirklich lösen will, müssen die Versionshistorie der Regeln vollständig erfasst werden. Updates in Form von Bugfixes und Updates zur Erweiterung von Berechtigungen müssen getrennt behandelt werden, und Letztere müssen zwingend eine erneute Bestätigung durch den Nutzer erfordern.
Ich finde, dass das Newton-Konzept DeFi-AI-Agenten tatsächlich um ein Stück Sicherheitspuzzle ergänzt. #Newt
Nachdem ich die Logs durchgegangen war, stellte sich heraus, dass mich genau das Setup von @NewtonProtocol mit der auf Rego basierenden automatischen Risk-Control gestoppt hatte. Letzte Woche hatte ich das Limit nach unten angepasst – und in der vergangenen Nacht hat dann ein AI-Agent einen hochfrequenten Refill-Antrag ausgelöst, der direkt abgefangen wurde. Effizient ist das wirklich. Aber das Gefühl, von selbst gebauten Käfigen eingeschlossen zu werden, ist auch irgendwie eigenartig.
Genau wegen dieses Vorfalls konnte ich mich dann wirklich hinsetzen und mir das Newton-Gesamtkonzept komplett von Grund auf durchdenken.
EigenLayer-Betreiber-Netzwerk als Fundament, TEE-Ausführungsumgebung als Rückversicherung, sowie eine kombinierte Validierung aus mehreren Off-Chain-Datenquellen: Die Idee ist, dass nach dem Einreichen erst die Bewertung durch den Betreiber erfolgt, dann ein Berechtigungsnachweis generiert und erst danach die Ausführung angestoßen wird. Auf den ersten Blick wirkt der gesamte Risk-Control-Loop makellos. Ehrlich gesagt macht mich jedoch gerade die ausgefeilte Konstruktion misstrauisch, wie sie sich in extremen Marktphasen schlägt. Mehr Off-Chain-Validierung bedeutet mehr Latenz – und wenn die Volatilität anzieht, kann der Sekundenunterschied zwischen Angebot und Ausführung schnell ein paar Prozentpunkte Verlust bedeuten. Die Offenlegung des Betreiber-Signatur-Ansatzes ist außerdem nicht detailliert genug, und Sicherheitsvorfälle in der TEE-Hardware-Historie kann ich mir auch mehrere auflisten. Beim Thema Privacy-Verification ist die Informationslage bislang zu dünn, als dass ich mich wirklich vollständig darauf verlassen könnte. Automatisches Risk-Management verlagert am Ende nur die Entscheidungsbefugnis von Institutionen zu Code – mehr Freiheit ist dadurch nicht zwingend wirklich gewonnen.
Trotzdem muss ich zugeben: In der Beta gibt es ein Design, das einen wunden Punkt tatsächlich trifft – komplexen Berechtigungs-Code in eine für Normalpersonen verständliche Autorisierungs-Checkliste zu übersetzen, das Risiko also nach vorne zu verlagern. Das gleicht auch die Schwäche aus, dass ZK-Nachweise zwar nur die Ausführung prüfen lassen, man aber die Autorisierungsgrenzen nicht durchschauen kann. Das ist auch der konkreteste Wert von $NEWT : Für Leute wie mich, die mit einem AI-Agent handeln wollen, aber Angst vor Fehltritten haben, gibt es wenigstens noch eine zusätzliche, gut lesbare Schutzebene.
Aber das Design für IPFS-Online-Updates der Regeln halte ich für einen versteckten Minenfall. Bei Agent-Iterationen können die Regeln still und leise Anpassungen an Transaktionslimits und dem Vertragsumfang vornehmen – wo sollte ein normaler Nutzer schon die Möglichkeit haben, Codeänderungen jede einzelne Zeile betreffend nachzuvollziehen? Wenn man einmal unaufmerksam ist, landet man unweigerlich in der Falle des passiven Blind-Signing. Wenn man das wirklich lösen will, müssen die Versionshistorie der Regeln vollständig erfasst werden. Updates in Form von Bugfixes und Updates zur Erweiterung von Berechtigungen müssen getrennt behandelt werden, und Letztere müssen zwingend eine erneute Bestätigung durch den Nutzer erfordern.
Ich finde, dass das Newton-Konzept DeFi-AI-Agenten tatsächlich um ein Stück Sicherheitspuzzle ergänzt. #Newt