Ehrlich gesagt hatte ich eigentlich nicht vor, durchzumachen. Am letzten Wochenende habe ich das @NewtonProtocol -Public-Chain-Beta- Sandbox gestartet, um eine Runde Rego-Strategie-Templates für einen Stresstest durchlaufen zu lassen, und dann war Schluss. Als ich gemerkt habe, wie spät es geworden war, war draußen schon völlig dunkel, der Kaffee war viermal kalt, und auf dem Terminal hing immer noch ein absichtlich falsch geschriebener Parameter für eine Strategie – und es wurde eine Testtransaktion durchgewunken, die eigentlich hätte abgefangen werden müssen.
Was macht Newton also genau? In einem Satz: Bevor eine On-Chain-Transaktion endgültig bestätigt wird, wird eine zusätzliche Autorisierungsprüfung eingefügt. Diese Prüfung ist nicht als Hardcoding in den Smart Contracts fest verankert, sondern als konfigurierbares Strategietemplate mit der Rego-Sprache geschrieben. Die Sanktions-Filterung ist ein Template, die KYC-Vertrauenswürdigkeits-Schwellenwerte sind ein anderes, und die Limits für die Transaktionsrate wieder ein weiteres. Deployende können sich ihre benötigten Templates wie beim Bauen mit Legosteinen zusammenstellen: ein paar Parameter ändern – und das lässt sich an unterschiedliche Rechtsräume und Compliance-Anforderungen anpassen. Die Strategieauswertung läuft in der TEE-Umgebung von Phala. Die Ergebnisse werden als signierte Quittung on-chain gespeichert; die Transaktionsdetails verlassen dabei die TEE während des gesamten Prozesses nicht. Wenn das erst einmal sauber durchläuft, verändert sich die Art, wie Institutionen Compliance umsetzen: von „jede Organisation hält sich ein eigenes Compliance-Team“ zu „ein Abonnement für eine Reihe von Strategie-Templates“. Die Deploy-Kosten fallen von siebenstelligen Beträgen direkt auf fünfstellige.
Aber. Dieses „Aber“ wagte ich erst zu schreiben, nachdem ich vierundachtzig Stunden gelaufen war.
Das Sandbox-Tooling in der Mainnet-Beta ist reifer als ich erwartet hatte. Docker-Images heruntergeladen, den RedStone-Sanktionslist-Datenstrom angeschlossen, und auch die Credora-Schnittstelle für Kredit-Scores hat durchgängige Verbindung. Diese beiden sind offizielle, veröffentlichte Daten-Partner für den Start der Mainnet-Beta. Ich habe mich an der Doku orientiert und die erste Gruppe von Strategie-Templates geschrieben: eine Sanktions-Filterregel, eine Regel für das Tageslimit für Abhebungen je Adresse und eine Regel für den Confidence-Threshold im KYC. Zusammengenommen sind es weniger als vierzig Zeilen Rego-Code. Saubere Adressen werden durchgelassen, Sanktionsadressen werden abgeblockt, überhöhte Abhebungen werden abgeblockt, niedrige KYC-Scores werden abgeblockt. In den ersten zwei Stunden lief alles reibungslos. Die Strategie-Engine war präzise wie ein Schweizer Uhrwerk.
Ich fange an, es zu ruinieren.
Die Ausführungslogik der Rego-Strategie-Templates ist rein funktional: Eingabedaten gehen ins TEE, die Strategie-Engine nimmt Rego-Regeln zum Matchen. Wenn ein Match gefunden wird, führt sie eine vorgegebene Aktion aus – durchlassen oder ablehnen. Sie hinterfragt nicht, ob die Eingabedaten wirklich wahr sind, sie kümmert sich nicht darum, wann die Daten aktualisiert wurden, und sie prüft nicht, ob der Cache veraltet ist. Sie macht nur eins: Regeln über die Daten legen und daraus ein Ergebnis ableiten.
Mein erster Test betraf das Abgreifen des RedStone-Datentransports. In der Übertragung eines inkrementellen Updates der Sanktionsliste habe ich mit iptables gezielt Pakete verworfen, sodass das TEE Dutzende kürzlich hinzugefügter OFAC-Adressen nicht bekam. Die Strategie-Engine weiß nicht, dass die Liste unvollständig ist. Sie führt die Rego-Logik mit dem unvollständigen Cache aus, und die Signatur wird durchgewunken. Der ganze Ablauf dauerte weniger als drei Sekunden. Die Zieladresse der Transaktion war in der realen OFAC-Liste als gesperrte Adresse bestätigt – aber in Newtons lokalem Cache existierte sie nicht, also ging sie durch. [Meine Einschätzung: Das ist kein Bug in der Rego-Logik, der Code ist nicht falsch. Das Problem liegt in der Vertrauensannahme der Strategie-Engine bezüglich der Eingabedaten. Sie geht davon aus, dass die Datenquelle aktuell und vollständig ist, dass das Netzwerk stabil ist, und dass der Cache in jedem Moment der aktuellste ist. Diese Annahmen können in verteilten Systemen jeweils auf die eine oder andere Art gebrochen werden.]
Beim zweiten Test habe ich an der Parameter-Grenze des Strategie-Templates angesetzt. Ich habe das Tageslimit für Barauszahlungen von 100.000 USDC auf 10.000 USDC geändert und dann sowohl eine Überweisung über 9.900 als auch eine über 1.000 in Folge eingereicht. Die erste ging durch, die zweite auch. Weil der Rate-Limit-Zähler asynchron aktualisiert wird, kamen beide Transaktionen fast gleichzeitig bei den TEE-Knoten an. Der Zähler hatte noch nicht Zeit, die 9.900 der ersten Transaktion in den Zustand zu schreiben, da kam die zweite schon hinein – und sah weiterhin „null“. Zusammen überschreiten beide die 10.000 – die Strategie-Engine hat es nicht abgefangen. [Nach meinen Erfahrungen werden solche Probleme bei paralleler Zustandskonsistenz in traditionellen Finanzsystemen über Datenbank-Transaktionssperren gelöst. In einer TEE-Umgebung ist die Status-Synchronisierung aber keine transaktionale, sondern eine finale Konsistenz. Für Szenarien mit starken Konsistenzanforderungen wie „Compliance“ bedeutet finale Konsistenz: Es gibt ein Zeitfenster, das man ausnutzen kann.]
Den dritten Test habe ich nicht in der Sandbox laufen lassen, sondern nur durchgespielt. In der Strategiearchitektur von Newtons Mainnet-Beta sind Rego-Templates kettenübergreifend wiederverwendbar. Dieselbe Zensur-/Sanktions-Filterstrategie: ein paar Parameter ändern – und sie wirkt gleichzeitig in Ethereum und Solana. Dieses Design ist extrem effizient, aber die Angriffsfläche verdoppelt sich ebenfalls. Ein Strategie-Template, das von mehreren Ketten wiederverwendet wird, bedeutet: Das Template selbst wird zu einem Single Point of Failure. Wenn ein Parameter falsch eingestellt wird oder wenn der Schwellenwert einer Regel zu niedrig ist, wirkt sich das gleichzeitig auf alle angeschlossenen Ketten aus. [Ich vermute, deshalb begrenzt Newton in der Mainnet-Beta-Phase die Anzahl der angebundenen Ketten eher konservativ – die schädliche Wirkung der Strategie-Wiederverwendung muss erst Zeit zur Validierung bekommen.]
Dann kommt die Sicherheitsbestätigung von EigenLayer. Ob die Signatur-Quittungen der Strategie-Engine von einem On-Chain-Vertrag vertraut werden können, hängt davon ab, ob die TEE-Knoten der Signierer über genügend wirtschaftliche Sicherheits-Deposits verfügen. Ich habe mir Newtons Betreiberverteilung auf EigenLayer angesehen: Die Top 3 halten zusammen etwa sechzig Prozent des gesamten Deposits. Slashing/Strafabzüge funktionieren als Korrelation: Wenn bei einem Betreiber auf einem anderen AVS etwas schiefgeht, wird bei Newtons Seite ebenfalls die Sicherheits-Ebene herausgezogen. Aber für den On-Chain-Vertrag sieht die Signatur-Quittung nur die Signaturgültigkeit – nicht, ob der Knoten zu dem Zeitpunkt, als signiert wurde, noch ein gültiges Deposit-Setup hatte. [Dabei könnte es ein Zeitfenster geben: Zwischen Auslösen des Slashing und der On-Chain-Bestätigung mit Streitfall bleibt eine Konformitäts-Signatur möglicherweise trotzdem wirksam.]
Bis hierher muss ich kurz stoppen und eine Sache klar sagen. Ich spreche nicht davon, was Newton falsch gemacht hat. Im Gegenteil: Compliance aus Hardcoded-Vertragslogik in zusammensetzbare Rego-Strategie-Templates zu abstrahieren, ist die richtige Richtung, und dass es weitergeht, ist absehbar. Eine Institution kann nicht für jede neue Kette jedes Mal ein ganzes Set an Compliance-Verträgen neu schreiben – „Strategie als Code“ ist die einzige skalierbare Lösung. $NEWT hat jetzt eine Marktkapitalisierung von mehr als zehn Millionen US-Dollar. Der Markt zahlt für diese Richtung noch keine besonders hohe Gewissheitsprämie. Aber auf der Mainnet-Beta laufen RedStone- und Credora-Datenschichten bereits in der Realität – die Push-Frequenz ist höher als bei generischen Schnittstellen.
Nur klingt „Strategie als Code“ zu elegant. Diese Eleganz lässt leicht vergessen, dass Code selbst keine Wahrheit hervorbringt. Code legt lediglich Regeln über Eingabedaten – und gibt dann ein Fazit aus. Wenn die Eingabedaten falsch sind, ist das Fazit wertlos. Wenn die Parameter falsch konfiguriert sind, ist das Fazit schief. Wenn die Statussynchronisierung langsam ist, ist das Fazit veraltet. TEE garantiert, dass der Rechenprozess nicht manipuliert wird – aber nicht, dass das Berechnungsergebnis korrekt ist. EigenLayer garantiert, dass der Signierer „Geld hat, das man bestrafen kann“ – aber nicht, dass die Signatur zu einem zuverlässigen Fazit gehört.
Strategie ist Code und maximiert die zulässige Flexibilität – aber der Preis ist, dass die Verantwortung für die Korrektheit nicht mehr beim Code selbst liegt, sondern beim Verfasser der Strategie. Die Parameter stellst du ein, die Datenquelle wählst du aus, ob „fail-open“ oder „fail-closed“ ist deine Entscheidung. Die Engine führt nur aus, kümmert sich nicht um richtig oder falsch.
Meine Haltung ist derzeit: Ich lasse in der Wallet einen kleinen Betrag $NEWT stehen – nicht viel. Wenn der weg ist, tut’s nicht weh. Alle paar Wochen schaue ich mir Newtons Update-Logs an und prüfe ein paar Dinge, ob sich etwas geändert hat: Ob sich das Update-Fenster der Datenquelle auf unter fünf Sekunden drücken lässt, ob die TEE-Status-Synchronisierung transaktional gemacht werden kann, ob die Notfall-Absicherung für fail-open schon live ist und ob die EigenLayer-Slashing-Notfalldokumentation immer noch diese Formulierung trägt: „in Diskussion“. Solange diese Dinge sich nicht bewegen, fehlen dem Versprechen von „Strategie als Code“ noch ein paar Schrauben, die noch nicht festgezogen sind.
An dem Tag, an dem man die Schrauben festzieht, kaufe ich nach. Nicht jetzt.