R3E Network setzt Multi-L2-elastisches Netzwerk-Prototyp auf Neo N3 TestNet ein

R3E Network hat seinen neo-n4-Prototyp eines elastischen Netzwerks auf dem Neo N3 TestNet bereitgestellt – die erste Live-Bereitstellung der unabhängigen Multi-L2-Architektur des Neo-Core-Entwicklers Jimmy Liao. Obwohl das Projekt den Namen „neo-n4“ trägt, ist es von Erik Zhangs kanonischer Neo 4-Protokollarbeit getrennt: Zhangs Arbeit zielt auf eine RISC-V-VM-Weiterentwicklung der zentralen Ausführungsschicht von Neo ab, während Liaos neo-n4 eine L2-Scaling-Schicht auf Basis von Neo N3 ist. Das neo-n4-Projekt steht in keiner Verbindung zu und wurde weder von Neo Global Development, noch von der Neo Foundation oder der neo-project-Organisation gebilligt.

Mit fünf zentralen Settlement-Verträgen, die nun auf dem TestNet betriebsbereit sind, hat sich das Projekt über das explorative Code-Repository hinaus entwickelt, das Neo News Today (NNT) im Mai behandelt hatte, und ist zu einem funktionsfähigen On-Chain-Prototyp geworden. Das Repository umfasst nun die Phasen 0-6, wobei live Verträge ersetzen, was zuvor nur als nicht bereitgestellte Spezifikation existierte.

Liao, der Gründer von R3E Network, umriss die Absicht des Projekts am Tag der Bereitstellung: „Same thesis as Neo X and SpoonOS: Neo N4 isn't about launching a new chain. It's about building chain-native apps on top of N3, application-centric, serving users better in the AI era.“ Der Verweis bezieht sich auf Neo X, Neos EVM-kompatible Sidechain, und SpoonOS, ein KI-Agenten-Framework im Neo-Ökosystem, als frühere Ausprägungen derselben anwendungszentrierten These.

Was das elastische Netzwerkmodell ermöglicht

Das elastische Netzwerkmodell ist darauf ausgelegt, dass Anwendungen auf ihren eigenen dedizierten Chains laufen können, während N3 als gemeinsame Settlement- und Sicherheitsschicht dient. Eine Gaming-Anwendung könnte beispielsweise auf einer Chain laufen, die auf hohen Durchsatz und geringe Latenz optimiert ist, während eine DeFi-Anwendung eine separate Chain mit strengeren Sicherheitsgarantien nutzt – dennoch würden beide dieselbe Brücke für den Asset-Transfer und denselben Governance-Rahmen nutzen. Nutzer und Vermögenswerte könnten sich zwischen diesen Chains bewegen, ohne dass jede Anwendung ihre eigene Brücke oder Sicherheitsinfrastruktur von Grund auf neu aufbauen müsste. Der Ansatz spiegelt die Multi-Rollup-Architekturen wider, die auf Ethereum erprobt werden, und wurde an Neos Protokollstack angepasst.

Auf dem TestNet bereitgestellte Verträge

Fünf L1-Settlement-Verträge wurden auf dem Neo N3 TestNet bereitgestellt, jeder mit einer eigenen Funktion in der elastischen Netzwerkarchitektur:

• RollupHub: Chain-Registry, Batch-Einreichung und Forced Inclusion.
• SharedBridge: Asset-Escrow für Ein- und Auszahlungen über die Schichten hinweg.
• GovernanceController: Council-basierte Governance mit Proposal- und Timelock-Mechanismen.

Zwei weitere Verträge übernehmen die Proof-Verifizierung: ZkVerifier leitet Proofs weiter, während Sp1Groth16Verifier Committee-Attestierungen mittels SP1 v6.2.1 Groth16/BN254-Pairing verifiziert.

Architekturüberblick

Die neo-n4-Architektur folgt einem dreistufigen Design, das vom ZKsync-Elastic-Chain-Muster abgeleitet und auf Neos eigenem Stack neu aufgebaut wurde – mit dBFT 2.0-Konsens, NEP-17-Token-Standards und NeoFS für Datenverfügbarkeit.

NeoHub sitzt auf der Basisschicht auf Neo N3 und koordiniert das Settlement über mehrere L2-Chains hinweg. Jede L2-Chain verfügt über eine eigene Ausführungsumgebung und teilt sich die Brückeninfrastruktur für den Asset-Transfer zwischen den Schichten. Zwischen L1 und L2 liegt eine optionale Gateway-Aggregationsschicht, die die Proof-Aggregation übernimmt.

Das System unterstützt drei Proof-Pfade: Multisig-Attestierung, Optimistic Rollup mit Fraud-Proof-Fenster sowie ZK-Validity-Proofs über SP1 RISC-V. Sieben elastische Chain-Templates – für Anwendungsfälle wie DEX, Gaming, DeFi, Social, NFT, Zahlungen und Unternehmen – sind als Forschungsprototypen zur Validierung und Testung enthalten.

Validierungsergebnisse

TestNet-Bereitstellungen dieser Art ermöglichen es einer Vertragssuite, in einer öffentlichen Umgebung ohne gefährdete Mainnet-Assets zu laufen. Die Tests vor deritstellung umfassten 1.475 von 1.478 Tests – 338 VM-Tests, 55 Integrationstests und 1.082 Unit-Tests – mit einer Abdeckung von 99,8 %. Nach der Bereitstellung bestanden 12 von 12 Smoke-Tests, alle fünf Vertragsbereitstellungen waren erfolgreich, und sechs Vertragsverbindungen wurden verifiziert.

Die RPC-Validierung verzeichnete 11 von 14 erfolgreichen Prüfungen; die drei verbleibenden Fehl schläge waren als nicht blockierend eingestufte Parameterformat-Probleme. Der Genesis-Zustand für die erste L2-Chain wurde vorbereitet.

Umfang und Vorbehalte

Das Repository umfasst nun 38 .NET-Testprojekte, 16 zentrale Off-Chain-Bibliotheken, acht Node-Plugins, fünf L1-Vertragsprojekte mit 10 L2-Native-Verträgen, sieben CLI-Tools und vier SDK-Quellen in .NET, TypeScript, Rust und Python.

Trotz des Umfangs der Bereitstellung bestehen erhebliche Vorbehalte. Keine Phase in der Implementierungsstatus-Matrix ist als produktionsreif gekennzeichnet. Das Repository hat keine offengelegte Sicherheitsprüfung durchlaufen, und mehrere Produktionsanforderungen – darunter die HSM/KMS-Signer-Integration und ein geprüftes NeoFS-Backend – sind weiterhin ungelöst. Eine offengelegte Sicherheitsprüfung ist üblicherweise eine Voraussetzung für den Produktiveinsatz von Infrastruktur dieser Art. Echte SP1-Proofs sind über einen manuellen Workflow optional; die Standard-CI führt nur schnelle Kompatibilitätsprüfungen durch. Die sieben elastischen Chain-Templates werden ausdrücklich als Forschungsprototypen und nicht als geplante Produktionschains beschrieben.

Ausblick

Die TestNet-Bereitstellung verwandelt neo-n4 von einer theoretischen Architektur in einen funktionsfähigen Prototyp, wobei das Projekt sich klar in der Forschungs- und Explorationsphase befindet. Seit NNTs Berichterstattung im Mai hat R3E Network die Phasen 4-6 abgeschlossen und dabei NeoVM2/SP1-RISC-V-Validity-Proofs, Gateway-Aggregation und CLI-Tooling ergänzt – auf den bereits bestehenden Phasen 0-3.

Kein Zeitplan für eine MainNet-Bereitstellung wurde bekannt gegeben, und die Arbeit wird als unabhängige explorative Entwicklungsarbeit von R3E Network fortgesetzt. Zu beobachtende Indikatoren sind die Behebung der drei nicht blockierenden RPC-Parameterformat-Fehler, die Verlagerung echter SP1-Proofs vom manuellen Opt-in-Workflow in die Standard-CI sowie ob der vorbereitete Genesis-Zustand zu einer live geschalteten ersten L2-Chain auf dem TestNet führt; jeder Schritt in Richtung Produktion würde zudem die ausstehende Sicherheitsprüfung, die HSM/KMS-Signer-Integration und ein geprüftes NeoFS-Backend erfordern, die als ungelöst markiert sind.

Die vollständigen Bereitstellungsergebnisse und das Repository sind verfügbar unter: https://github.com/r3e-network/neo-n4