R3E Network déploie un prototype de réseau élastique multi-L2 sur le TestNet Neo N3

R3E Network a déployé son prototype de réseau élastique neo-n4 sur le TestNet Neo N3, marquant la première mise en production réelle de l'architecture multi-L2 indépendante conçue par Jimmy Liao, développeur principal de Neo. Bien qu'il porte le nom de "neo-n4", le projet est distinct des travaux protocolaires officiels de Neo 4 menés par Erik Zhang : l'effort de Zhang vise une évolution RISC-V de la machine virtuelle de la couche d'exécution centrale de Neo, tandis que le neo-n4 de Liao constitue une couche de scaling L2 construite au-dessus de Neo N3. Le projet neo-n4 n'est ni affilié à ni soutenu par Neo Global Development, la Neo Foundation ou l'organisation neo-project.

Avec cinq contrats de règlement essentiels désormais opérationnels sur le TestNet, le projet a dépassé le stade du dépôt de code exploratoire que Neo News Today (NNT) avait couvert en mai pour devenir un prototype fonctionnel on-chain. Le dépôt couvre désormais les phases 0-6, les contrats actifs remplaçant ce qui n'était auparavant que des spécifications non déployées.

Liao, fondateur de R3E Network, a défini l'intention du projet le jour du déploiement : « 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. » Cette référence renvoie à Neo X, la sidechain compatible EVM de Neo, et à SpoonOS, un framework d'agents IA de l'écosystème Neo, comme expressions antérieures de cette même thèse axée sur les applications.

Ce que permet le modèle de réseau élastique

Le modèle de réseau élastique est conçu pour permettre aux applications de fonctionner sur leurs propres chaînes dédiées tandis que Neo N3 sert de couche commune de règlement et de sécurité. Une application de jeu, par exemple, pourrait fonctionner sur une chaîne optimisée pour le haut débit et la faible latence, tandis qu'une application DeFi occupe une chaîne distincte offrant des garanties de sécurité plus strictes—toutes deux suyant néanmoins sur le même pont pour le transfert d'actifs et le même cadre de gouvernance. Les utilisateurs et les actifs pourraient ainsi circuler entre ces chaînes sans que chaque application ait à construire son propre pont ou sa propre infrastructure de sécurité. Cette approche reflète les architectures multi-rollup explorées sur Ethereum, adaptées à la pile protocolaire de Neo.

Contrats déployés sur le TestNet

Cinq contrats de règlement L1 ont été déployés sur le TestNet Neo N3, chacun jouant un rôle distinct dans l'architecture du réseau élastique :

• RollupHub : registre des chaînes, soumission de lots et inclusion forcée.
• SharedBridge : séquestre d'actifs gérant les dépôts et les retraits entre les couches.
• GovernanceController : gouvernance fondée sur un conseil, avec propositions et mécanismes de timelock.

Deux contrats supplémentaires gèrent la vérification des preuves : ZkVerifier assure le routage des preuves, tandis que Sp1Groth16Verifier vérifie les attestations de comité à l'aide de l'appariement Groth16/BN254 de SP1 v6.2.1.

Aperçu de l'architecture

L'architecture neo-n4 suit une conception à trois niveaux adaptée du modèle ZKsync Elastic Chain et reconstruite sur la pile de Neo, combinant le consensus dBFT 2.0, les standards de tokens NEP-17 et NeoFS pour la disponibilité des données.

NeoHub se situe au niveau de base sur Neo N3 et coordonne le règlement entre plusieurs chaînes L2. Chaque chaîne L2 conserve son propre environnement d'exécution tout en partageant l'infrastructure de pont utilisée pour transférer les actifs entre les couches. Entre L1 et L2 se trouve une couche facultative d'agrégation Gateway qui gère l'agrégation des preuves.

Le système prend en charge trois voies de preuve : l'attestation multisig, le rollup optimiste avec une fenêtre de fraud-proof et les preuves de validité ZK via SP1 RISC-V. Sept modèles de chaînes élastiques—couvrant les cas d'usage DEX, jeux, DeFi, social, NFT, paiement et entreprise—sont inclus en tant que prototypes de recherche destinés à la validation et aux tests.

Résultats de validation

Les déploiements sur TestNet de ce type permettent à une suite de contrats de fonctionner dans un environnement public sans actifs de mainnet en jeu. Les tests avant déploiement ont couvert 1 475 tests sur 1 478—338 tests VM, 55 tests d'intégration et 1 082 tests unitaires—atteignant une couverture de 99,8 %. Les tests de fumée après déploiement ont donné 12 réussites sur 12, les cinq déploiements de contrats ayant réussi et six liens inter-contrats ayant été vérifiés.

La validation RPC a enregistré 11 vérifications réussies sur 14 ; les trois échecsants étaient des problèmes de format de paramètres signalés comme non bloquants. L'état genesis a été préparé pour la première chaîne L2.

Portée et réserves

Le dépôt contient désormais 38 projets de tests .NET, 16 bibliothèques hors chaîne essentielles, huit plugins de nœud, cinq projets de contrats L1 avec 10 contrats natifs L2, sept outils CLI et quatre sources de SDK couvrant .NET, TypeScript, Rust et Python.

Le déploiement comporte néanmoins des réserves importantes. Aucune phase de la matrice d'état d'implémentation n'est marquée comme prête pour la production. Le dépôt n'a fait l'objet d'aucun audit de sécurité annoncé, et plusieurs exigences de production—dont l'intégration de signataires HSM/KMS et un backend NeoFS révisé—restent non résolues. Un audit de sécurité annoncé est un prérequis habituel pour le déploiement en production d'infrastructures de ce type. Les preuves SP1 réelles sont facultatives via un flux de travail manuel, tandis que le CI standard n'exécute que des vérifications de compatibilité rapides. Les sept modèles de chaînes élastiques sont explicitement décrits comme des prototypes de recherche, et non comme des chaînes de production prévues.

Perspectives

Le déploiement sur TestNet fait passer neo-n4 d'une architecture théorique à un prototype opérationnel, même si le projet reste fermement dans une phase de recherche et d'exploration. Depuis la couverture de NNT en mai, R3E Network a achevé les phases 4-6, ajoutant les preuves de validité NeoVM2/SP1 RISC-V, l'agrégation Gateway et les outils CLI, en complément des phases 0-3 déjà en place.

Aucun calendrier de déploiement sur le MainNet n'a été annoncé, et les travaux se poursuivent en tant qu'ingénierie exploratoire indépendante menée par R3E Network. Les indicateurs à surveiller incluent la résolution des trois échecs RPC non bloquants liés au format des paramètres, le passage des preuves SP1 réelles du flux manuel facultatif au CI standard, et l'évolution de l'état genesis préparé vers une première chaîne L2 active sur le TestNet ; toute étape vers la production exigerait également l'audit de sécurité en attente, l'intégration de signataires HSM/KMS et un backend NeoFS révisé, signalés comme non résolus.

L'intégralité des résultats du déploiement et le dépôt sont disponibles à l'adresse : https://github.com/r3e-network/neo-n4