R3E Network a publié neox-rs v2.7.0, une nouvelle version du client full-node Neo X écrit en Rust qui fusionne 185 commits de Reth 2.7.0 en amont, corrige neuf vulnérabilités cargo audit et renforce le cycle de vie des validateurs de génération de clés distribuée (DKG).

Jimmy Liao, développeur principal de Neo et fondateur de R3E Network, a annoncé la sortie le 20 octobre.

Depuis ses débuts en juillet, le client est passé par trois versions précédentes : une pré-version initiale, une première version stable avec des corrections de consensus, puis une version de remédiation d'audit ayant clôturé 11 constats. Le numéro de version est passé directement de v2.5.2 à v2.7.0 pour rester aligné sur la numérotation en amont de Reth — une convention de synchronisation qui permet aux opérateurs de nœuds de retracer chaque build de neox-rs jusqu'à la base en amont exacte dont il hérite.

Fusion en amont de Reth 2.7

La mise à jour fait passer neox-rs à la base de code de Reth 2.7.0, intégrant 185 commits par rapport à la base précédente tout en conservant les couches de protocole spécifiques à Neo X, notamment le consensus dBFT, le chiffrement à seuil DKG, le traitement des enveloppes Anti-MEV et les endpoints RPC personnalisés. Reth est le client d'exécution Rust pour Ethereum développé par Paradigm, et les fusions en amont régulières de ce type permettent à un client dérivé d'absorber les correctifs et améliorations de sa base à mesure que la base de code enont évolue, plutôt que de s'en écarter.

Parallèlement à la fusion, l'oracle Neo X Geth a été synchronisé avec sa dernière base. Les fichiers genesis de la MainNet et de la TestNet ont été vérifiés comme correspondant aux octets canoniques, préservant ainsi les hachés des blocs genesis. La version est livrée avec des binaires Linux et Windows x86_64, chacun publié avec des sommes de contrôle SHA-256 ; les artefacts aarch64 n'ont pas été compilés pour cette version.

Remédiation de sécurité

Neuf vulnérabilités cargo audit ont été corrigées via des mises à jour de dépendances vers quinn-proto 0.11.18 et rustls 0.23.46, et le projet ne signale désormais aucune vulnérabilité connue via cargo audit. Cargo audit compare l'arbre de dépendances d'un projet Rust à une base de données d'avis publiés ; un rapport sans aucun constat indique donc qu'aucun signal de vulnérabilité connue ne subsiste dans l'ensemble actuel des dépendances.

La revue de sécurité a été réalisée par un processus autorisé par un agent plutôt que par un audit indépendant tiers, une distinction notée dans la version comme une acceptation de risque consignée.

Renforcement du cycle de vie DKG

Quatre changements ciblent la fiabilité du cycle de vie des validateurs DKG, en s'attaquant aux modes de défaillance observés lors de campagnes de validation prolongées :

• Les préparations DKG survivent désormais aux avancées de la tête canonique, évitant les états précédemment bloqués.
• Les opérations Submit rejetées ramènent le validateur à l'état Ready au lieu de laisser la tâche préparée orpheline.
• La correspondance des parts utilise désormais conjointement le round et la clé globale agrégée, éliminant les fausses erreurs de discordance d'époque lors de la progression normale des blocs.
• Les parts des signataires ne sont plus réinstallées à chaque bloc ; le système hache les entrées canoniques réglées au lieu de la tête canonique.

Le DKG est la procédure de cryptographie à seuil par laquelle un ensemble de validateurs génère conjointement du matériel de clé de sorte qu'aucun participant seul ne détienne la clé complète — l'une des couches spécifiques à Neo X que la fusion en amont devait préserver. Ces correctifs traitent les cas limites où l'état DKG pourrait devenir incohérent aux frontières de blocs, des scénarios qui se manifesteraient lors d'une validation multi-rounds prolongée.

Validation et tests

Le candidat à la version a été validé par une porte G8 de 1 402 blocs couvrant les hauteurs 2 404 à 3 805. La porte a confirmé la progression des rounds DKG du round un au round deux, a maintenu un engagement agrégé identique de 128 octets tout au long, et a enregistré zéro réorganisation et zéro erreur RPC transitoire.

Le déchiffrement des enveloppes a été vérifié dans des scénarios d'époque courante et d'époques croisées, une enveloppe du round un enregistrée ayant été déchiffrée et minée avec succès après que la chaîne est passée au round deux. Les tests de défaillance comprenaient des délais de prover de 60 secondes, des redémarrages forcés processus et le remplacement de parts avec reçus manquants.

Les 427 tests Neo X passent tous, avec des vérifications clippy et de formatage propres. La compatibilité du datadir a également été confirmée : un répertoire de données et un keystore DKG en v2.7.0 se sont ouverts avec succès sous v2.5.2, et le binaire de la version a chargé un datadir d'archive MainNet existant — des vérifications pertinentes pour les opérateurs, car elles montrent que les données de chaîne existantes et les keystores DKG restent utilisables à travers les frontières de versions.

Perspectives

La synchronisation complète de la MainNet depuis le genesis avec un datadir propre reste en cours après la version, bien que la connexion aux pairs et le pipeline des en-têtes aient été vérifiés. Cette synchronisation est l'étape restante à surveiller, ses deux prérequis — connectivité aux pairs et récupération des en-têtes — étant déjà confirmés comme fonctionnels.

neox-rs continue de servir d'implémentation Rust indépendante du protocole Neo X, apportant une diversité de clients aux côtés du client Neo X Geth écrit en Go et maintenu par Bane Labs. La diversité de clients — l'exécution d'implémentations indépendantes du même protocole — est une pratique de résilience de longue date dans les réseaux blockchain, car un défaut confiné à une base de code n'affecte pas automatiquement l'autre.

La page de la version est disponible à l'adresse : https://github.com/R3E-Network/neox-rs/releases/tag/neox-v2.7.0