Haseeb Ghiffari

Ich habe immer wieder das Wort „Marktplatz“ im Zusammenhang mit Newtons Model Registry gesehen und es eine Weile beim Wort genommen: konkurrierende Operatoren, ein Reputationssystem, Nutzer, die durch eine Bibliothek von Agenten stöbern und den auswählen, der zu ihrer Strategie passt. Dann habe ich nachgesehen, was in diesem Registry heute tatsächlich gelistet ist, und das Bild ist deutlich kleiner als die Sprache darum herum.
Derzeit läuft das Registry mit einem einzelnen Live-Agenten, einem „Recurring Buy Agent“. Die Roadmap rahmt den Schritt hin zu einem komponierbaren Ökosystem aus mehreren Agenten ausdrücklich als etwas, das noch bevorsteht – nicht als etwas, das bereits ausgeliefert wurde. Das Ziel ist, ein komponierbares Ökosystem verifizierbarer Agenten zu fördern und sich über den anfänglichen Einzelagenten, den „Recurring Buy Agent“, hinauszubewegen. In der Zwischenzeit beschreibt die breitere Marktplatz-Beschreibung, die in unabhängigen Veröffentlichten auftaucht, ein Orderbuch-basiertes System: Nutzer übermitteln Automatisierungs-Intents mit angehängten Gebühren, und Operatoren konkurrieren darum, diese effizient und verifizierbar auszuführen. Das Protokoll funktioniert als Orderbuch-Marktplatz, der Automatisierungsanfragen zwischen Nutzern und Operatoren matcht. Operatoren konkurrieren dabei, um Aufgaben effizient und verifizierbar auszuführen, während Validatoren Ausführungsbeweise verifizieren, bevor sie Zustandsübergänge abschließen. Das ist ein echtes Design – aber ein Design, das eine gewisse Vielfalt braucht, um wie beschrieben zu funktionieren. Wettbewerb und Reputation sind relative Konzepte. Sie bedeuten erst etwas, wenn es mehr als eine Option gibt, gegen die man konkurrieren oder eine Reputation aufbauen kann.

Lustige Sache ist letzte Woche passiert: Ich habe einen Arbeitslaptop zurückgesetzt, der nach einem BIOS-Update ständig beim Secure Boot scheiterte. Irgendeine Einstellung war umgesprungen, und die Maschine weigerte sich, ihrer eigenen Firmware zu vertrauen, bis ich sie manuell wieder aktiviert habe. Ich brauchte zwanzig Minuten Googeln, um überhaupt zu verstehen, was „measured boot“ bedeutet. Und natürlich hat mein Gehirn offenbar keine Fähigkeit mehr, sich ordentlich zu sortieren: Durch diese Umleitung bin ich direkt wieder in die Doku von Newton Protocol zurückgesprungen – in den Abschnitt, den ich bei jeder früheren Gelegenheit einfach überflogen hatte: die Oracle Adapter Layer.

Ich bin fast an diesem Punkt vorbeigegangen. Er ist auf der eigenen Roadmap von Newton als „in Kürze“ aufgeführt und leicht zu übersehen neben den lauteren Ankündigungen zu Tresoren und Identitäts-Oracles. Aber die Idee hinter dem Multichain Newton Keystore Rollup ist größer als die Vermarktung: Ein einziges zkPermissions-Rollup, das programmierbare Berechtigungen einmalig und günstig verwaltet und es jeder Kette ermöglicht, die an Newton andockt, auf denselben Datensatz zu verweisen, statt dieselbe Richtlinienlogik auf jeder einzelnen Kette neu zu deployen und separat neu zu verifizieren.
Das Problem, das es löst, ist real. Im Moment muss, wenn eine Richtlinie auf Ethereum, Base und überall dort, wo Newton als Nächstes expandiert, angewendet werden soll, so eine Logik irgendwo existieren, ausgewertet und auf jeder Kette einzeln dafür bezahlt werden. Das ist redundante Rechenleistung, redundante Gas-Kosten und eine wachsende Angriffs-/Fehlerfläche dafür, dass dieselbe Richtlinie still und heimlich bei Deployments aus dem Takt gerät. Ein Rollup, das speziell dafür gebaut wurde, Berechtigungen zu halten, löst das Redundanzproblem auf saubere Weise. Ein einziger kanonischer Datensatz, Zero-Knowledge-Beweise, die seinen Zustand belegen, und andere Ketten prüfen einfach dagegen, statt die komplette Logik selbst mitzuführen.

Ich habe eine Weile lang das Design bewundert, bevor mir auffiel, was darunter steckt. Newton bestätigt die Policy-Auswertung mit erneut eingesetzten Operatoren, Zero-Knowledge-Beweisen, Dispute-Windows und Slashing. Das gesamte System ist darauf ausgelegt, eine Frage überzeugend zu beantworten: Hat das Netzwerk diese Transaktion anhand dieser Policy korrekt geprüft? Das ist wirklich eine anspruchsvolle Ingenieursaufgabe, und Newtons Ansatz geht dabei sorgfältig vor. Aber eine Policy-Prüfung ist nur so zuverlässig wie die Fakten, mit denen sie abgeglichen wird – und diese Fakten stammen in fast jeder realen Newton-Policy, die ich mir angesehen habe, von ganz anderer Stelle.

Ich habe nachgeschaut, wer tatsächlich Newtons Compliance-Richtlinien mit den Rohdaten versorgt, und die Antwort drehte sich immer wieder um einen Namen: Magic Labs. Nicht als neutraler Anbieter, der einfach neben einem Dutzend konkurrierender Datenanbieter steht, sondern als dasselbe Unternehmen, das das Protokoll ursprünglich überhaupt erst gebaut hat und jetzt zusätzlich eine seiner zentralen Risiko-Scoring-Eingaben über das sogenannte Magic Labs Risk Scoring Data Oracle liefert.
Das lohnt sich, einen Moment lang durchzudenken, denn das gesamte Pitch-Deck von Newtons Architektur basiert auf einer Trennung zwischen zwei Dingen: der Policy-Logik, die dezentral ist und von Operatoren verifiziert wird, und den Daten, auf denen diese Logik läuft – Daten, die angeblich aus einem offenen Marktplatz von Anbietern stammen. Newton selbst stellt das als Stärke dar. Policies sind modular, Entwickler können Datenquellen mischen und kombinieren, nichts ist fest eincodiert. Aber wenn das Flaggschiff, das erste veröffentlichte Daten-Oracle, auf der Wallet- und E-Mail-Risiko-Intelligenz derselben Organisation basiert, die auch das Protokoll betreibt, und wenn diese Daten aus sieben Jahren Transaktionshistorie stammen – über 50 Millionen Wallets, die Magic bereits für Kunden wie Polymarket und Naver verwaltet – dann wird die Grenze zwischen „dezentraler Policy-Engine“ und „internem Risikomodell eines einzigen Unternehmens, das die Kleidung eines Protokolls trägt“ deutlich unschärfer, als das Marketing vermuten lässt.