Jetzt reden die meisten Menschen, die sich mit Newton beschäftigen, darüber, ob ein Agent Regeln befolgen kann, nicht manipuliert wird und nicht wiederholt (replayed) werden kann. Das stimmt alles. Aber als ich gestern die Datenstruktur einer attestation erneut angesehen habe, ist mir aufgefallen, dass sie eher wie eine Präzisionskamera ist, die aufzeichnet, „was passiert ist“, aber niemals „was hätte passieren sollen“ protokolliert — und diese Lücke ist viel schwerwiegender, als ich ursprünglich gedacht hatte.
Wir nehmen ein Szenario an: Ein Nutzer hat im Agent Marketplace eine Rebalancing-Strategie mit einem Volatilitäts-Trigger autorisiert. Die Regel der Strategie lautet: Wenn die 30-Tage-Volatilität von BTC einen bestimmten Schwellenwert überschreitet, wird das Risiko reduziert. Die Strategie wird ausgelöst, und der Operator führt den Contract-Aufruf korrekt aus; außerdem wird ein vollständiger Beweis vollständig gespeichert, und der Handel ist vollständig regelkonform. Doch später stellt der Nutzer fest, dass der Volatilitätsdaten-Feed zu diesem Zeitpunkt kurzzeitig vom Risikokontrollsystem außer Betrieb genommen wurde. Der Agent rief daraufhin stattdessen einen anderen Backup-Oracle auf, dessen Qualität deutlich schlechter war. Dadurch kam es zu einer Preisverzögerung, und der Zeitpunkt bzw. das Position-Reduzierungsniveau, an dem tatsächlich reduziert wurde, lag 2,8% unter dem Punkt, der eigentlich hätte erreicht werden sollen. Dieser Verlust von 2,8% wird in der verifizierbaren Automatisierung von Newton nicht von irgendeiner attestation als Fehler markiert. Denn jede Ausführungsschritt der Strategie entspricht den vordefinierten Regeln, auch das Backup-Oracle steht in der Whitelist, die Operator-Signatur ist gültig und die doppelte Autorisierung des Nutzers ist ebenfalls innerhalb der Gültigkeitsdauer.
Genau an dieser Stelle hänge ich fest: Verifizierbarkeit garantiert, dass der Prozess korrekt ist, nicht dass das Ergebnis vernünftig ist. Wenn der agent marketplace in Zukunft verwalten soll, über Hunderte Millionen an Kapital, dann ist das zentralste Risiko in der Finanzwelt nicht „dass jemand wahllos Knöpfe drückt“, sondern „dass niemand korrigiert, wenn der Knopf genau dann hätte gedrückt werden müssen, aber an der falschen Stelle“. Ein Nutzer, dem 2,8 % abgezogen werden, aber der keine einzige On-Chain-Evidenz finden kann, um zu erklären, warum die Marktbedingungen tatsächlich eine bessere Ausführung hätten auslösen müssen—dann bricht das Vertrauen in das gesamte System abrupt ein. Und sowohl operator als auch Entwickler würden sich herausreden: Sie hätten schließlich ihren Teil getan.
Ich denke noch eine Ebene tiefer: Könnte diese Lücke in der Verantwortlichkeit umgekehrt zu einem Nährboden für Angriffe werden? Ein böswilliger Dritter muss nicht einmal policy durchbrechen—er kann es auf die Daten-Lieferkette absehen. Zum Beispiel könnte er den Preis für ein bestimmtes oracle mit geringer Liquidität um ein paar Basispunkte nach unten drücken und dadurch eine Reihe von „regelkonformen“ Stopps/Kaskaden bei den agent-Ausführungen auslösen. Anschließend kann er mit Positionen in Derivaten daraus Gewinn ziehen. Alle Operationen werden protokolliert, operator hat nichts falsch gemacht, policy wurde nicht verletzt—und am Ende wird der Verlust jedoch punktgenau aus der Tasche der Nutzer abgezogen. Das erfordert nicht einmal die Absprache mit irgendeinem operator; es genügt, auf der Ebene der Dateneingaben genug plausiblen Lärm zu erzeugen.
Was kann Newton tun? Eine mögliche Richtung wäre, dass attestation nicht nur Beweise für die Ausführung der Transaktion enthält, sondern auch einen „Beweis für die Qualität der Ausführungsumgebung“—zum Beispiel eine Bewertungsnote für den Gesundheitszustand der Datenquelle, Gründe für das Auslösen eines Backup-oracle, und Abweichungswerte während der Aggregation. So kann der Nutzer zumindest im Nachhinein nachvollziehen, ob sein Verlust daher rührt, dass sich der Markt tatsächlich verändert hat, oder weil es in irgendeiner Stufe der Datenkette einen Austausch gab, der zwar regelkonform ist, aber von schlechter Qualität. Darüber hinaus wäre es hilfreich, wenn Nutzer eine „Mindestschwelle für Datenqualität“ festlegen könnten: Bei Ausführungen unterhalb dieser Schwelle könnte die Ausführung automatisch angehalten und an eine manuelle Prüfung übergeben werden. Das würde das Problem deutlich entschärfen—würde aber die Belastung für die agent-Automatisierungsrate erhöhen.
Ich verstehe, dass Newton derzeit auf genau dieses Thema fokussiert: „verifizierbare Ausführung“. Das ist an sich schon schwer. Aber die Geschichte im Finanzbereich lehrt uns immer wieder: Regeln können niemals alle Eventualitäten abdecken. Das wirklich Wertvolle an einem System ist nicht, dass man beweisen kann, dass alles normal läuft, sondern dass man dir sagen kann, an welcher Stelle die Abweichung von den Erwartungen des Nutzers begonnen hat, wenn etwas schiefgeht.$BTC
Ich schaue jetzt auf zwei Punkte: Erstens, ob künftige agent-Strategien ein Outcome Verification einführen—also nicht nur Aktionen verifizieren, sondern die wirtschaftliche Angemessenheit der Ausführung nachträglich bewerten. Zweitens, ob die Newton-Ökologie eine Reihe unabhängiger Audit-Knoten hervorbringen wird, die speziell für attestation noch eine zusätzliche Ebene „ökonomische Anomalie-Kennzeichnung“ hinzufügen—damit die durch Datenvergiftung entstehenden Verluste aus der Blackbox geholt und ins Licht gezerrt werden.