Die Neo-Blockchain soll ihre Fähigkeiten durch eine innovative mehrschichtige Skalierungslösung und ein maßgeschneidertes Programmier-Framework erweitern

Jimmy Liao, Neo-Kernentwickler und Gründer von R3E Network, veröffentlichte am 4. Mai zwei experimentelle Repositories, die untersuchen, wie die nächste Generation von Neo aussehen könnte. Der größere der beiden, neo-n4, ist der Prototyp einer elastischen Multi-L2-Netzwerkarchitektur, die auf dem Neo 4-Kern basiert. Die zweite, neo-lang, ist eine domänenspezifische Sprache im Frühstadium für Neo N3-Smart-Verträge.

Bei beiden Projekten handelt es sich um unabhängige Gemeinschaftsforschungsbemühungen. Im neo-n4-Repository heißt es deutlich, dass es „NICHT die offizielle Neo 4-Version“ sei, und beschreibt sich selbst als „einen Community-Prototyp, keine Spezifikation“.

neo-n4: elastische Netzwerkarchitektur

neo-n4 ist als dreistufiges Design vorgesehen, bei dem Neo N3 oder Neo 4 als L1-Abwicklungsschicht dient, ein optionales Gateway Beweise von mehreren L2-Ketten aggregiert und einzelne L2-Ketten den Neo 4-Kern als Ausführungskernel ausführen. Die Architektur übernimmt das Shared-Bridge- und Proof-Aggregation-Muster, das von ZKsyncs Elastic Chain entwickelt wurde und auf dem Neo-Stack unter Verwendung von dBFT 2.0-Finalität, NEP-17-Assets, NeoVM und NeoFS für die Datenverfügbarkeit neu aufgebaut wurde.

Der Umfang des Prototyps ist beträchtlich. Zum Zeitpunkt des Schreibens enthält das Repository 820 Tests in 26 Projekten, 19 Smart Contracts, aufgeteilt auf 13 NeoHub L1-Verträge und 6 L2 native Verträge, 15 Off-Chain-Bibliotheken, 8 Node-Plugins und 3 CLI-Tools. Die Verträge umfassen unter anderem die Kettenregistrierung, Shared Bridging, Settlement Management, Sequencer Bonding und ein optimistisches Challenge-Fenster.

Liao strukturierte die Arbeit in Phasen. Die Phasen null bis drei, die einen Sidechain-Proof-of-Concept, die NeoHub-Shared-Bridge, die Batch-Abwicklung und ein optimistisches Challenge-Fenster umfassen, werden als abgeschlossen markiert. Phase sechs ist ebenfalls abgeschlossen und stellt Entwickler-CLI-Tools bereit. Die Phasen vier und fünf, die auf ZK-Gültigkeitsnachweise mithilfe eines RISC-V-Beweisers und die Beweisaggregation über mehrere L2s hinweg abzielen, bleiben mit vorhandenem Gerüst in Bearbeitung.

Das kettenübergreifende Nachrichtensystem des Projekts, Neo Connect, beschreibt L1-zu-L2-, L2-zu-L1- und L2-zu-L2-Nachrichten, die durch gestapelte Merkle-Proofs geleitet werden. Ein abgestuftes Datenverfügbarkeitsmodell bietet drei Ebenen: L1-Abwicklung für Anwendungsfälle mit hoher Sicherheit wie DeFi, NeoFS für kostengünstigere Anwendungen und eine Option des Datenverfügbarkeitsausschusses für Szenarien mit minimalen Kosten.

Das Repository umfasst ein Whitepaper, eine Architekturdokumentation und Bedienerhandbücher, wurde jedoch keinem offengelegten Sicherheitsaudit unterzogen.

Beziehung zur offiziellen Neo 4-Arbeit

neo-n4 geht ausdrücklich davon aus, dass der Neo 4-Kern als funktionierende Basisschicht existiert, und baut darauf eine L2-Architektur auf. Die vierte Phase des Projekts zielt auf Gültigkeitsnachweise für NeoVM 2 und RISC-V ZK ab und steht im Einklang mit der Richtung, die Neo-Mitbegründer Erik Zhang in seinem Entwurf der Neo 4-Roadmap im September 2025 dargelegt hat.

Am 15. April gab Zhang bekannt, dass eine NeoVM-kompatible RISC-V-VM-Lösung die vollständige MainNet-Statusvalidierung bestanden hat, was bestätigt, dass das Design über die Konzeptphase hinausgegangen ist. Liao leistete einen Beitrag zu diesen Bemühungen, indem er Tage zuvor ein Architekturdiagramm der PolkaVM-Integration in den Neo Core C#-Knoten veröffentlichte.

Die Ankündigung von neo-n4 erfolgte 19 Tage nach diesem Meilenstein. Während Zhangs Arbeit die kanonische Entwicklung des Neo-4-Protokolls darstellt, untersucht neo-n4, wie eine darauf aufbauende Multi-L2-Skalierungsschicht aussehen könnte. Zhangs Roadmap-Entwurf schlug nicht ausdrücklich eine Multi-L2-Architektur vor.

neo-lang: eine neo-native Vertragssprache

Das zweite Repository, neo-lang, präsentiert eine vertragsorientierte Sprache für Neo N3 mit der Dateierweiterung „.neo“. Es verfügt über 10 integrierte Typen, Strukturdeklarationen, Ereignisbehandlung, ein Paketsystem und Zugriff auf native Neo-Verträge, einschließlich Oracle und Notar.

Liaos Ankündigung behauptet, dass die Sprache 30 % an Opcodes einspart. Das Repository enthält zwar eine umfassende Sprachreferenz, Compiler-Binärdateien, Testsuiten, Beispielverträge und Benchmarks sind jedoch noch nicht verfügbar.

Der Kontrast zum ausgereifteren Neo-Solidity-Compiler von R3E, der am 20. März v0.15.0 mit über 700 Tests, Beispiel-DeFi-Verträgen und einer Hardhat-Integration zu 95 % ausgeliefert wurde, ist bemerkenswert. Beide Projekte zielen auf Neo N3-Bytecode ab, bedienen aber unterschiedliche Zielgruppen. neo-solidity portiert eine etablierte Sprache für EVM-vertraute Entwickler, während neo-lang darauf abzielt, von Grund auf neo-nativ zu sein.

Die produktive Produktion von R3E geht weiter

Die beiden Repositories sind die neuesten in einem rasanten Strom von Entwicklertools von R3E im Jahr 2026. Seit Februar hat das Team den Neo-Solidity-Compiler, ein JavaScript-Decompiler-SDK, ein auf MainNet bereitgestelltes TEE-basiertes Oracle-System sowie SDK-Releases für JavaScript, Rust und Swift ausgeliefert.

neo-n4 stellt die ehrgeizigste dieser Bemühungen dar – ein Prototyp einer Infrastruktur auf Netzwerkebene und nicht einzelner Entwicklertools. Ob irgendwelche seiner Komponenten Eingang in die offizielle Neo-Entwicklung finden, bleibt eine offene Frage. Liaos Doppelrolle sowohl als R3E-Gründer als auch als Neo-Kernentwickler positioniert die Arbeit als fundierte Erkundung, aber die Haftungsausschlüsse des Repositorys machen deutlich, dass es genau das ist – eine Erkundung