Gestern Nacht habe ich lange wach geblieben und @NewtonProtocol technische Dokumente durchforstet. Diese eine beiläufige Zeile darin – „Non-EVM support is on the roadmap“ – hat meine Alarmglocken in dem Moment sofort zum Klingen gebracht.
Derzeit ist $NEWT im Einsatz auf dem EigenLayer-AVS. Es wird verwendet, um genau jene „policy enforcement“ zu verifizieren, die im Kern mit der Verarbeitung von Zuständen in Ethereum-kompatiblen Chains zu tun haben. Obwohl das Whitepaper in epischer Breite die glorreichen Leistungen von Ethereum, Arbitrum und sogar Base auflistet, verwandelt sich die Antwort sofort in diese schattenhafte Roadmap, sobald man testweise nach Solana oder Sui fragt – also nach Nicht-EVM-Chains. Ich starrte eine Weile auf den Bildschirm und rechnete nach: Ein Underlying Engine, die den ganzen Tag damit wirbt, „chain-agnostic“ zu sein – wenn ihre verifizierenden Nodes tatsächlich nur Solidity-Bytecode verstehen, wie sollte man dann überhaupt Sicherheitsstrategien auf diesen heterogenen Chains durchsetzen können?
Ich nehme als das typischste Beispiel einfach Solana und leite dieses technische Dilemma ab. Nehmen wir an, ich will heute auf Solana mit einem „Newton-guarded wallet“ eine Sicherheitsrichtlinie einrichten, die den täglichen Abfluss großer Vermögenswerte begrenzt. Diese Regel muss durch die Knoten des Newton-AVS-Netzwerks signiert und bestätigt werden. Das Problem ist aber fatal: Solanas Datenstrukturen und Account-Modell sind komplett eine parallele Welt—vollkommen verschieden vom EVM. EVM-Knoten sind längst daran gewöhnt, Beweise in dem Format zu parsen, das auf Merkle Patricia Trie basiert. Solana verwendet jedoch eine andere Variante von Merkle Trees. Diese kryptografischen Beweisformate können auf der Basisebene überhaupt nicht direkt zusammenarbeiten. Ich habe mit Freunden gesprochen, die Multi-Chain-Architekturen entwickeln; ganz offen sagten sie: Wenn du wirklich die Ketten-Grenzen durchbrechen und State Verification umsetzen willst, musst du entweder massig Geld investieren und selbst einen Light Client für Multi-Chain-States „von Hand“ pflegen, oder dich notgedrungen damit abfinden, eine externe Cross-Chain-Brücke anzudocken.$BTC
Wenn man diese Schlussfolgerung weiterdenkt, sind die Kosten für beide Wege viel zu schwer. Den eigenen Engineering-Aufwand für einen Multi-Chain-Light-Client zu schreiben, ist ähnlich groß wie das Rad neu zu erfinden. Und die Nutzung einer Cross-Chain-Brücke läuft darauf hinaus, die von dir mühsam aufgebaute Sicherheit der Validierungsebene direkt der Vertrauenskrise von Drittnetzwerk-Brücken auszusetzen. Viele Teams, die eine Multi-Chain-Totalabdeckung groß ankündigen, rufen zwar täglich in der Öffentlichkeit nach einem Fahrplan, aber im Hintergrund haben sie womöglich nicht einmal einen grundlegenden technischen Entwurf zum Laufen gebracht. Das ist ganz bestimmt keine Absicht, mit einer „eingefärbten“ Brille schlechtzureden. Denn in der aktuellen offiziellen Dokumentation finde ich nicht einmal einen Zeitplan, geschweige denn substanzielle Code-Tests.
Eine weitere, noch verstecktere technische Bruchstelle liegt in der Cross-Chain-Kompatibilität von Session Keys. Wenn man den Dokumenten folgt und weiter gräbt, stellt sich heraus: Der Session Key, den Newton als zentrales Sicherheitsmodell ansieht, ist eigentlich ein heißes Eisen. Im EVM-Ökosystem läuft das Ganze dank des Rückenwinds von ERC-4337 Account Abstraction sehr rund: Man stellt einem Agent einen temporären Schlüssel mit nur eingeschränkten Rechten aus, um automatisierte Abläufe auszuführen; der gesamte Logik-Loop schließt sich glatt. Doch wenn man diese Spielweise ungeschickt direkt nach Solana überträgt, merkt man, dass es dort nicht einmal die grundlegende Unterscheidung zwischen EOA-Accounts und Contract-Accounts gibt. Diese Differenz in der zugrunde liegenden Account-Philosophie bedeutet, dass man, wenn man jetzt diese auf ERC-4337 basierende Schlüsselverwaltungsarchitektur „hart“ in Solana stopft, fast den gesamten Signatur- und Authentifizierungsprozess neu aufsetzen müsste. Cross-Chain-Standardisierung klingt zwar schön, aber man kann dem Code nicht vorgaukeln, dass das so einfach geht.$ETH
Das ist noch nicht mal das, was mir am meisten Angst macht. Wenn man Newtons BLS-Attestation-Validierung auf EVM-Chains laufen lässt, sind die Kosten vernachlässigbar, weil es dort vorkompilierte Contracts gibt, die speziell dafür da sind, BLS12-381-Kurven zu bedienen. Doch wenn man genau hinsieht, ist die Unterstützung vorkompilierter Precompiles in heterogenen Chains völlig unterschiedlich. Dieselbe kryptografische Signaturvalidierung—wenn man sie ohne spezielle Optimierungen zwangsläufig ausführt—verbraucht exponentiell steigende Rechenressourcen. Ich habe grob auf Papier überschlagen: Diese Kluft in der zugrunde liegenden Rechenleistung kann sehr gut dazu führen, dass die Kosten für eine policy enforcement auf einer Nicht-EVM-Chain mindestens zehnmal so hoch sind wie im Ethereum-Ökosystem. Wenn eine sogenannte einheitliche Sicherheitsnorm am Ende dazu führt, dass ein Teil der Nutzer fast kostenlos spielen kann, aber den anderen Teil dazu zwingt, astronomische Verifikationsgebühren zu zahlen, dann hat diese Cross-Chain-Bedeutung des Standards letztlich keinen Bestand mehr.
Eigentlich ist mir klar, warum sich die Projektseite unbedingt für diese Richtung entscheiden muss. Zuerst hart ins EVM-Ökosystem gehen: das eigene Verifikationsnetz und den Policy-Engine-Standard aufziehen, denn dort sind die meisten aktiven Gelder bereits versammelt—engineering-seitig ist das mit Sicherheit ein guter Schachzug. Doch das tödliche Risiko dieser Strategie liegt in einer massiven Fehlanpassung zwischen Narrativ und Fundamentaldaten. Die aktuelle Begeisterung basiert auf der großen Erwartung, dass es ihm gelingen werde, alle Public Chains zu vereinheitlichen. Unzählige Privatanleger kaufen genau diese weitreichenden Fantasien. Sobald irgendwann in der Zukunft jemand feststellt, dass die Unterstützung für Nicht-EVM-Umgebungen auf unbestimmte Zeit aussteht, werden die ganzen „chain-agnostic“-Marketingfloskeln im Handumdrehen zu Witzen. Die Aufwertungslogik, die zuvor hochgezogen wurde, kann dann sehr wahrscheinlich über Nacht in Gefahr geraten, zu kollabieren.
Ich wage es im Grunde nicht, weil ein paar schöne Parolen mich verleiten könnten, einfach blind nachzulegen. Ich habe mir sehr klare Bedingungen gesetzt: Ich schaue mir nicht an, wie sie ihre zukünftigen Entwicklungspläne schönreden, sondern ich konzentriere mich nur auf zwei harte Datenpunkte. Erstens: Können sie wirklich konkrete technische Entwürfe und eine Zeitleiste liefern, um Nicht-EVM-Chains zu verifizieren? Zweitens: Wann wird im Testnetz wirklich eine Beispiel-Implementierung für Strategie-Interception auf Solana laufen? Gestern habe ich einen ganzen Nachmittag damit verbracht, in einem Blockchain-Explorer Daten nachzuverfolgen. Ergebnis: Ich habe nichts gefunden, das irgendeinen substanzielle Nachweis für Unterstützung heterogener Chains liefern würde—also musste ich die Seite schließlich still schließen. Beim Handeln ist das manchmal genau so: Wenn die technische Blackbox keinen stimmigen Logik-Loop zulässt, ist das Nicht-„aus Versehen kaufen“ auch eine Form von Selbstschutz. Natürlich kann das im aktuellen Stadium auch einfach eine technische Kompromisslösung des Teams sein, um schnell an den Start zu gehen. Ich werde trotzdem weiter auf ihre späteren Code-Commits achten, um zu sehen, wie diese Cross-Chain-Show am Ende überhaupt „rund“ wird.