Alle reden davon, dass Newton das wirklich „Full-Chain“-Strategie-Engine ist – aber in der Node-Validierungslogik sehe ich deutlich den Abdruck von EVM. Die Kern-Workflows verwenden durchgängig EVM-State-Proof-Formate: MPT-Bäume, vorgefertigte BLS-Precompiles – alles wirkt wie maßgeschneidert für die Ethereum-Familie. Kein Wunder: EVM-lastig in der Ausführung, obwohl es als „chain-agnostisch“ verkauft wird.
Ich habe extra ein automatisches Script für Sui gebaut, das Orders aufgibt: Wenn der Floor-Price unter 0,5 SOL liegt, wird storniert. Die Regeln sind simpel – das Ergebnis: AVS-Nodes erkennen es schlicht nicht. Das ist kein Parameterproblem, sondern die Proof-Struktur passt überhaupt nicht zusammen. Solanas Account-Merkle-Bäume, Sui-objektzentrierter Speicher, die BFT-Konsens-Pfade – das ist Meilenweit von der EVM-Schiene entfernt. Zehn, fünfzehn nicht-EVM-Nodes parallel laufen lassen? Die Rechenkosten mal außen vor: Updates, Forks und Kompatibilität sind ein endloses Loch, und in der Doku steht dazu kein Wort. Der versteckteste Haken steckt in der Berechtigungszuordnung. Newtons Zugriffskontrolle folgt ganz dem ERC-4337-Paradigma: Granularität, Gültigkeitsdauer, Revoke-Logik – alles ist 1:1 nach EVM Account Abstraction. Aptos’ Resource-Accounts, Solanas programmdgeleitete Adressen: komplett ein anderes Modell. Rüberkopieren funktioniert entweder gar nicht sauber bei den Rechten oder die Ausführung bleibt hängen. Auch die Signaturvalidierungskosten unterscheiden sich massiv: EVM hat Precompiles, das fällt fast kaum ins Gewicht, bei Nicht-EVM muss man vieles „hart“ berechnen – und das macht Gas im Vergleich locker ein paar Mal teurer. In der Branche rufen Projekte, sie seien chain-agnostisch – von zehn machen neun zuerst das EVM-User-Experience-Setup perfekt und werfen Nicht-EVM nur ins Roadmap-Kapitel. Wenn man es wirklich umsetzen will, heißt es entweder: eine eigene Multi-Chain-Light-Client-Stack aufbauen (Zeitrahmen eher Jahre), oder es an ein Drittanbieter-Proof-Netzwerk auslagern (Sicherheitsannahmen werden extern vergeben). Keine der beiden Wege ist leicht. Ich schaue im Moment nur auf zwei Dinge:
Gibt es wirklich einen technischen Entwurf, der einen nicht-EVM-Leichtclient ausgibt (nicht nur ein Satz einer Roadmap, sondern mit Prüf-/Verifikationsprozess-Details);
Gibt es in der Community bereits reproduzierbare Nicht-EVM-Verifikations-Traces?
Wenn beides nicht vorhanden ist, bleibt die ganze On-Chain-Erzählung letztlich nur Storytelling. Stand jetzt wirkt Newton eher wie ein kraftvolles Strategiemiddleware innerhalb des EVM-Ökosystems, nicht wie eine echte On-Chain-Engine. Kurzfristig bleibe ich weiterhin abwartend und entscheide erst über meine Allokation, wenn Code verfügbar ist und mehrkettenfähige Testergebnisse vorliegen. Das Narrativ ist zwar verlockend, aber die zugrunde liegenden Vorannahmen lügen nicht.