Neo blockchain est prêt à étendre ses capacités grâce à une solution de mise à l'échelle innovante et un cadre de programmation sur mesure

Jimmy Liao, développeur principal de Neo et fondateur de R3E Network, a publié le 4 mai deux référentiels expérimentaux explorant à quoi pourrait ressembler la prochaine génération de Neo. Le plus grand des deux, neo-n4, prototype une architecture de réseau élastique multi-L2 construite sur le cœur Neo 4. Le second, neo-lang, est un langage spécifique à un domaine à un stade précoce pour les contrats intelligents Neo N3.

Les deux projets sont des efforts de recherche communautaires indépendants. Le référentiel neo-n4 indique clairement qu'il ne s'agit « PAS de la version officielle de Neo 4 », se décrivant comme « le prototype d'une communauté, pas une spécification ».

neo-n4 : architecture de réseau élastique

neo-n4 est envisagé comme une conception à trois niveaux dans laquelle Neo N3 ou Neo 4 sert de couche de règlement L1, une passerelle facultative regroupe les preuves de plusieurs chaînes L2 et les chaînes L2 individuelles exécutent le noyau Neo 4 comme noyau d'exécution. L'architecture emprunte le modèle de pont partagé et d'agrégation de preuves mis au point par Elastic Chain de ZKsync, reconstruit sur la pile de Neo en utilisant la finalité dBFT 2.0, les actifs NEP-17, NeoVM et NeoFS pour la disponibilité des données.

La portée du prototype est considérable. Au moment de la rédaction de cet article, le référentiel contient 820 tests répartis sur 26 projets, 19 contrats intelligents répartis entre 13 contrats NeoHub L1 et 6 contrats natifs L2, 15 bibliothèques hors chaîne, 8 plugins de nœuds et 3 outils CLI. Les contrats couvrent l'enregistrement de la chaîne, le pontage partagé, la gestion des règlements, la liaison de séquenceur et une fenêtre de défi optimiste, entre autres fonctions.

Liao a structuré le travail par phases. Les phases zéro à trois, couvrant une preuve de concept sidechain, le pont partagé NeoHub, le règlement par lots et une fenêtre de défi optimiste, sont marquées comme terminées. La phase six est également terminée, fournissant des outils CLI aux développeurs. Les phases quatre et cinq, qui ciblent les preuves de validité ZK à l'aide d'un prouveur RISC-V et l'agrégation de preuves sur plusieurs L2, restent en cours avec un échafaudage en place.

Le système de messagerie inter-chaînes du projet, Neo Connect, décrit les messages L1 à L2, L2 à L1 et L2 à L2 passant par des preuves Merkle par lots. Un modèle de disponibilité des données à plusieurs niveaux offre trois niveaux : règlement L1 pour les cas d'utilisation de haute sécurité tels que DeFi, NeoFS pour les applications à moindre coût et une option de comité de disponibilité des données pour les scénarios à coût minimal.

Le référentiel comprend un livre blanc, une documentation sur l'architecture et des guides de l'opérateur, bien qu'il n'ait fait l'objet d'aucun audit de sécurité divulgué.

Relation avec le travail officiel de Neo 4

neo-n4 suppose explicitement que le noyau Neo 4 existe en tant que couche de base de travail et construit une architecture L2 par-dessus. La quatrième phase du projet cible les preuves de validité de NeoVM 2 et RISC-V ZK, s'alignant sur l'orientation que le co-fondateur de Neo, Erik Zhang, a décrite dans son projet de feuille de route Neo 4 en septembre 2025.

Le 15 avril, Zhang a annoncé qu'une solution de machine virtuelle RISC-V compatible NeoVM avait passé avec succès la validation complète de l'état du MainNet, confirmant que la conception avait dépassé le stade conceptuel. Liao a contribué à cet effort en partageant un diagramme d'architecture de l'intégration de PolkaVM dans le nœud Neo Core C# quelques jours plus tôt.

L'annonce du neo-n4 a eu lieu 19 jours après cette étape importante. Alors que le travail de Zhang représente le développement canonique du protocole Neo 4, neo-n4 explore à quoi pourrait ressembler une couche de mise à l'échelle multi-L2 si elle était construite par-dessus. Le projet de feuille de route de Zhang ne proposait pas explicitement une architecture multi-L2.

neo-lang : un langage contractuel néo-natif

Le deuxième référentiel, neo-lang, présente un langage orienté contrat ciblant Neo N3 avec une extension de fichier « .neo ». Il propose 10 types intégrés, des déclarations de structure, une gestion des événements, un système de packages et un accès aux contrats natifs Neo, notamment Oracle et Notary.

L'annonce de Liao affirme que le langage permet d'économiser 30 % sur les opcodes. Cependant, bien que le référentiel contienne une référence complète du langage, les binaires du compilateur, les suites de tests, les exemples de contrats et les tests de référence ne sont pas encore disponibles.

Le contraste avec le compilateur néo-solidité plus mature de R3E, qui a livré la version 0.15.0 le 20 mars avec plus de 700 tests, des exemples de contrats DeFi et une intégration Hardhat achevée à 95 %, est notable. Les deux projets ciblent le bytecode Neo N3 mais s'adressent à des publics différents. neo-solidity porte un langage établi pour les développeurs familiers avec EVM, tandis que neo-lang vise à être néo-natif à partir de zéro.

La production prolifique de R3E se poursuit

Les deux référentiels sont les derniers d'un flux rapide d'outils de développement de R3E en 2026. Depuis février, l'équipe a livré le compilateur néo-solidité, un SDK de décompilateur JavaScript, un système Oracle alimenté par TEE déployé sur MainNet et des versions de SDK pour JavaScript, Rust et Swift.

neo-n4 représente le plus ambitieux de ces efforts : un prototype d'infrastructure au niveau du réseau plutôt que des outils de développement individuels. La question de savoir si l'un de ses composants trouvera sa place dans le développement officiel de Neo reste une question ouverte. Le double rôle de Liao en tant que fondateur de R3E et développeur principal de Neo positionne le travail comme une exploration éclairée, mais les propres avertissements du référentiel indiquent clairement qu'il s'agit exactement de cela : une exploration.