Um herauszufinden $NEWT ob es in den Haupt-Depot passt und ob es die Risikokontrolle für große Vermögenswerte tragen kann, habe ich einen ganzen Tag investiert und die komplette Lauf-Logik seines Testnetzes eigens vollständig erneut verifiziert.

Ich mag es nicht, nur die offiziellen Tech-Highlights anzusehen – was ZK-Beweise, EigenLayer-Re-Staking usw. betrifft: Das wirkt alles nur anstrengend. Was ich viel mehr interessiert, sind die praktischsten Fragen: Sieht das System zwar beeindruckend aus – aber kann es die realen, komplexen Fehlerszenarien des Marktes tatsächlich aushalten? Und kann es extreme Risiken wirksam umgehen?

Nachdem ich alle Abläufe praktisch getestet und sie mehrfach mit dem offiziellen Konsens sowie den Unterlagen zur Risikokontrolle abgeglichen hatte, habe ich in meinem Kopf im Grunde ein klares Bild.

Objektiv gesagt ist die Top-Level-Architektur von NEWT tatsächlich deutlich besser als die meisten herkömmlichen Orakel am Markt. Die Innovationen sind wirklich überzeugend und stechen ins Auge. Aber gleichzeitig habe ich auch ein paar handfeste Mechanismus-Lücken gefunden: keine kleinen Bugs, sondern eine echte, grundlegende Leere, die in der aktuellen Phase keinen geschlossenen Regelkreis zulässt.

Lass uns zuerst über die Dinge sprechen, die sie gut machen. Nach meiner Analyse hat diese „Intent–Evaluation–Consensus“-Dreischritt-Architektur tatsächlich die alte, veraltete Single-Node-Orakel-Logik und das einfache Community-Abstimmungsmodell hinter sich gelassen. Auf Sicherheitsebene ist die Vorbereitung sehr solide: mehrere Operatoren bewerten unabhängig, was das Problem von Single-Point-Schurken vermeidet. Durch das Staking über EigenLayer gibt es eine ökonomische Absicherung, und am Ende wird das Ganze mit Succinct ZK-Beweisen abgerundet – so entsteht ein vollständiger geschlossener Kreislauf. Betrachtet man nur diese Logik, finde ich daran nichts auszusetzen. Aus der Wurzel heraus werden viele Sicherheitsrisiken traditioneller On-Chain-Datenquellen umgangen.

Außerdem stimme ich auch zu, was den Bereich der Ökosystem-Datenquellen angeht. Bei den eingebauten Partnern wie RedStone und Credora schaue ich ohnehin regelmäßig auf den jeweiligen Track, und der Branchenruf sowie die Datenstabilität sind einwandfrei – unter standardisierten Anwendungsfällen reicht das völlig aus und ist ausreichend vertrauenswürdig.

Aber was mich wirklich nervös macht – ja, mir sogar ein wenig den Rücken kalt läuft – ist nicht ein öffentlich beworbener Vorteil, sondern die von ihnen stark herausgestellte Funktion für benutzerdefinierte Datenquellen. Und gerade darin sehe ich nach meinen Tests den größten Risikopunkt.

Viele wissen diesen Detailpunkt nicht: #Newt ermöglicht es Nutzern, selbst WASM-Module zu schreiben und selbst zu kompilieren, sie können frei Börsenkurse und alle Arten externer API-Daten einbinden – die Freiheit ist extrem hoch und passt sich allen möglichen benutzerdefinierten Risikokontroll-Strategien an.

Zur Abwehr von Angriffen hat das Projekt eine Sandbox-Isolation eingebaut. Nach meinem Live-Test habe ich jedoch festgestellt, dass die Wirkung dieser Sandbox extrem einseitig ist.

Es macht im Grunde nur eine Sache: CPU und Anfragehäufigkeit begrenzen, um zu verhindern, dass bösartige Skripte die Knoten zum Absturz bringen und DOS-Angriffe verursachen.

Es kümmert sich nur darum, dass die Knoten nicht sterben – es kümmert sich nicht darum, ob die Daten stimmen.

Das ist die tödlichste Blindstelle.

Die Logik, die du selbst zum Abruf schreibst, die Art der Zeitstempel-Ausrichtung und die Cache-Refresh-Regeln – alles liegt in deiner eigenen Kontrolle. Auf Protokoll-Ebene gibt es überhaupt keine Validierungsmechanismen.

Ich gebe ein sehr anschauliches Beispiel: Du schreibst ein Modul, um CEFi-Spot-Preise abzurufen. Wenn die Zeitstempel nicht ausgerichtet sind, wenn nach einem Wechsel von Primary/Backup alter Cache zurückbleibt oder wenn die API vorübergehend zittert, dann bekommt das System ausschließlich falsche Daten eingespeist.

Aber der Kern kommt erst:

Solange das Skript ohne Fehler läuft und der Prozess durchläuft, wird die Policy-Validierung direkt durchgewunken. Dann werden ebenso gültige Signaturen generiert und der On-Chain-Konsens abgeschlossen.

So entsteht dann ein besonders absurdes Paradox: Faule, falsche Daten – aber sie bekommen eine Art „höchste“ Bestätigung durch den On-Chain-Konsens.

Je standardisierter der Prozess und je vollständiger die ZK-Beweise sind, desto schwerer ist es für die Außenwelt zu erkennen, dass die zugrunde liegenden Daten verfälscht sind. Das Risiko ist extrem tief versteckt.

Nicht nur die Datenvalidierung fehlt; auch bei der umstrittenen Handhabung von Meinungsverschiedenheiten im Multi-Node-Konsens habe ich in der Dokumentation keine klare Antwort gefunden, nachdem ich alles durchforstet habe.

Netzwerk, Laufumgebung und Cache-Takt verschiedener Operatoren unterscheiden sich zwangsläufig leicht. Mit demselben WASM-Modul unterschiedliche Ergebnisse zu erhalten, ist also völlig normal.

Aber offiziell wurde nur gesagt: „Fehler führen zur Einziehung der hinterlegten Vermögenswerte“, ohne das Kernproblem klar zu erläutern:

Wenn es bei den Daten unterschiedliche Auffassungen gibt: Nach wessen Maßstab wird entschieden? Wer liefert den Nachweis? Führt ein nicht-subjektiver Fehler durch Umgebungsabweichungen zu einer Strafe? Wenn eine Fehlentscheidung getroffen wird – wie kann man Einspruch erheben?

Diese entscheidenden Verantwortlichkeiten und Befugnisse werden alle verschwommen überspielt; im Grunde ist es völlig leer.

Ganz zu schweigen von dem erhöhten Risiko bei Cross-Chain-Deployments.

Ich habe bemerkt, dass sich auf unterschiedlichen öffentlichen Ketten die Anzahl der bereitgestellten Knoten und die Stärke der Autorisierung stark unterscheiden, sodass sich die Risikokontroll-Standards überhaupt nicht vereinheitlichen lassen. Kurz gesagt: Die von ihnen beworbene nahtlose Konsistenz der Risikokontrolle lässt sich derzeit schlicht nicht umsetzen.

Selbst wenn traditionelle Finanzsysteme maximale Effizienz anstreben, lassen sie immer eine Fehlertoleranz mit menschlicher Nachprüfung und Streitfall-Workflows – als Puffer.

Doch NEWT kappt für die Dezentralisierung der Effizienz nahezu alle menschlichen Puffer und vertraut fast komplett darauf, dass Code automatisch ausgeführt und der Konsens automatisch beurteilt wird.

Aus Sicht von Live-Realgeldern denke ich, dass die technische Architektur und die Innovationsideen von NEWT wirklich sehr vorausgedacht sind und das Fundament auf keinen Fall schlecht ist. Aber das aktuelle Problem lässt sich nicht durch bloße Optimierungs-Iterationen lösen. Falsche Daten ohne Validierung, Knoten-Differenzen ohne Regeln, benutzerdefinierte Datenquellen ohne klare Rechte- und Pflichten sowie nicht einheitliche Cross-Chain-Risikokontrolle – diese vier großen Berge stehen im Weg.

Auch kein Wunder: Im Moment trauen sich nur Institutionen mit kleinen Positionsgrößen einen ersten Test. Niemand mit großen Einsatzbeträgen traut sich, mit voller Gewichtung einzusteigen. Wenn ich an ihrer Stelle wäre, würde ich auch nicht wagen.

Insgesamt betrachtet wächst dieses Projekt sehr schnell, aber das Fundament ist tatsächlich nicht stabil geblieben @NewtonProtocol

Ich werde die weiteren Mechanismus-Updates des Teams kontinuierlich verfolgen – inklusive der Ergänzung der Dokumentation und der Umsetzung der Regeln. Erst wenn diese zentralen Schlupflöcher wirklich vollständig geschlossen sind, hat diese scheinbar perfekte, moderne Architektur überhaupt erst die Berechtigung, große Vermögenswerte zu tragen und in einer breiten, großflächigen Umsetzung zu bestehen.