La récente réunion des opérateurs de nœuds Vaulta (anciennement EOS) a rassemblé les participants pour discuter des dernières évolutions du logiciel Antelope. La conversation a porté sur une publication de correctif urgent pour la version 1.2.2, les progrès continus de la très attendue version Spring 2.0, et un débat animé sur la manière dont les nœuds se trouvent mutuellement sur le réseau. Ce fut une session chargée axée sur la stabilisation et la facilitation de la gestion du système.
Points clés à retenir
-
Un correctif urgent pour Antelope Spring 1.2.2 est recommandé aux opérateurs de nœuds afin de résoudre un problème rare qui pourrait arrêter la production de blocs. Cette mise à jour inclut également des améliorations mineures du réseau.
-
Le développement d'Antelope Spring 2.0 progresse, avec la Developer Preview 2 attendue prochainement, introduisant une nouvelle fonctionnalité appelée 'événements'. Un réseau de test séparé est prévu pour cette version.
-
La Developer Preview 3 est en route et sera la dernière occasion d'apporter des modifications significatives aux interfaces avant la version finale de Spring 2.0, en se concentrant sur la stabilité.
-
Il y a une discussion en cours sur la façon dont les nœuds se connectent, car les méthodes actuelles ne connectent pas beaucoup d'opérateurs. Des idées comme commencer avec un petit groupe de nœuds 'hub' fiables sont envisagées.
-
Les opérateurs de nœuds demandent des moyens plus simples de trouver d'autres nœuds, suggérant des outils comme la récupération de listes de pairs à partir d'une URL ou l'utilisation de simples fichiers JSON.
Publication du correctif Antelope Spring 1.2.2 fortement recommandée
L'équipe de développement d'Antelope a lancé un appel aux opérateurs de nœuds pour qu'ils mettent à jour leurs systèmes vers la version 1.2.2 du correctif pour la version Spring. Cette mise à jour est importante car elle résout un problème rare qui pourrait arrêter la production de blocs. Elle apporte également quelques petites améliorations sur la façon dont les nœuds communiquent entre eux et corrige quelques autres bogues. Il est vraiment dans l'intérêt de la stabilité du réseau que chacun installe ce correctif dès que possible.
Progrès du développement d'Antelope Spring 2.0
Le développement d'Antelope Spring 2.0 progresse, l'équipe travaillant sur plusieurs fonctionnalités clés. La Developer Preview 2 devrait être publiée prochainement, probablement fin septembre ou début octobre. Cette préversion introduira une nouvelle classe de données appelée "événements", qui devrait modifier la manière dont certaines informations sont gérées au sein du réseau. Pour soutenir cette publication, un réseau de test temporaire séparé est en cours de mise en place, distinct du réseau de test Jungle existant. Cela permettra un test ciblé des nouvelles fonctionnalités avant qu'elles ne soient intégrées plus largement. L'équipe prévoit également la Developer Preview 3, qui visera à affiner les fonctionnalités introduites dans la Preview 2 et à résoudre les compromis éventuels. Cette troisième préversion est destinée à être la dernière occasion d'apporter des modifications significatives aux interfaces, en se concentrant sur la robustesse des appels de synchronisation et de la nouvelle fonctionnalité d'événements.
Developer Preview 3 à l'horizon
L'équipe se prépare pour la Developer Preview 3, qui devrait être la dernière occasion d'apporter des modifications significatives à l'interface avant la publication complète d'Antelope Spring 2.0. Cette prochaine préversion vise à résoudre les problèmes et à corriger les compromis faits lors du développement de la Preview 2. Un objectif majeur sera de rendre les appels de synchronisation plus robustes et d'affiner la fonctionnalité d'événements introduite précédemment.
Les principaux domaines de travail pour la Developer Preview 3 incluent :
-
Améliorer la stabilité et la fiabilité du processus de synchronisation des nœuds.
-
Poursuivre le développement et les tests de la nouvelle classe de données 'événements'.
-
Résoudre les bogues ou les goulots d'étranglement de performance restants identifiés dans les préversions précédentes.
-
Assurer une transition plus fluide pour les opérateurs de nœuds qui mettent à niveau vers la nouvelle version.
Débat sur le pairage par 'gossip' et la découverte de réseau
La discussion sur la manière dont les nœuds se trouvent mutuellement sur le réseau Antelope, souvent appelée découverte de pairs, a été un sujet brûlant. Actuellement, il semble que tout le monde ne se connecte pas avec autant d'autres nœuds qu'il le pourrait. Cela a conduit à de nombreuses discussions sur la méthode actuelle, qui repose sur un système appelé "pairage par 'gossip'". Essentiellement, les nœuds partagent des informations sur les autres nœuds qu'ils connaissent. Cependant, l'efficacité de ce système semble être un point de discorde.
Plusieurs idées ont été soulevées pour améliorer les choses. Une suggestion était de démarrer de nouveaux nœuds avec un petit groupe fiable de nœuds "hub". Cela leur donnerait une base solide pour commencer à se connecter. Un autre aspect discuté était l'équilibre entre la configuration manuelle des connexions à des pairs spécifiques et le fait de laisser le système de 'gossip' les trouver automatiquement. Le problème central semble être d'assurer une connectivité robuste et étendue sans la rendre trop compliquée pour les opérateurs de nœuds.
Cela a naturellement conduit à des appels pour des moyens plus simples de trouver des pairs. De nombreux opérateurs ont exprimé le désir d'outils capables de récupérer des listes de pairs à partir d'une URL ou d'un fichier. L'idée de publier des listes de points de connexion initiaux, peut-être au format JSON, gagne du terrain. Il a également été mentionné l'ajout de moyens de vérifier si ces listes sont légitimes, juste pour une sécurité supplémentaire.
Appels à des outils simplifiés de découverte de pairs
De nombreux opérateurs de nœuds ont exprimé le désir de disposer de moyens plus simples pour trouver et se connecter à d'autres nœuds sur le réseau. Les méthodes actuelles peuvent être un peu complexes, et il y a une volonté de rendre ce processus plus direct. Une suggestion courante est de permettre aux opérateurs de spécifier une URL ou un chemin de fichier à partir duquel le nœud peut récupérer une liste de pairs auxquels se connecter. Cela éviterait de devoir configurer manuellement chaque pair. Une autre idée qui gagne du terrain implique la publication de listes de nœuds d'amorçage au format JSON. Cette approche structurée pourrait faciliter l'amorçage des connexions pour les nœuds. Il est également question d'ajouter des moyens optionnels de vérifier si ces listes de pairs sont fiables, ajoutant une couche de sécurité au processus de découverte.
Améliorations à long terme à l'étude
Au-delà des correctifs immédiats et des prochaines versions, l'équipe étudie des moyens de rendre le réseau plus robuste et plus facile à gérer à long terme. Une idée envisagée consiste à créer des nœuds relais légers. Ces nœuds, potentiellement construits à l'aide d'outils comme Wharfkit, pourraient aider à diffuser l'information plus efficacement sur le réseau.
Il est également question de rendre le système de 'gossip' plus intelligent. Cela pourrait signifier étendre la façon dont les nœuds partagent l'information et trouver des moyens de gérer automatiquement les connexions afin que les opérateurs n'aient pas à effectuer autant de configurations manuelles.
De plus, le groupe prévoit de revenir sur certaines fonctionnalités qui avaient été proposées auparavant mais qui n'ont jamais été intégrées au code. Ces idées plus anciennes pourraient offrir des solutions à certains des défis actuels concernant la façon dont les nœuds se trouvent mutuellement.
Bilan de la réunion et prochaines étapes
Les discussions se sont conclues par un ensemble clair d'actions et de domaines sur lesquels continuer à se concentrer. Les opérateurs de nœuds sont fortement encouragés à commencer à tester la prochaine Developer Preview 2 d'Antelope Spring dès qu'elle sera disponible. Cette expérience pratique est vitale pour recueillir des retours, en particulier concernant les implications de la nouvelle classe de données "événements". L'équipe recherche une large participation pour aider à évaluer comment ces événements fonctionneront dans des scénarios réels.
Plusieurs points clés sont ressortis des conversations de la journée :
-
L'intérêt de la communauté pour des méthodes de découverte de pairs plus simples, comme la "découverte du pauvre" utilisant des listes de graines, a été réaffirmé. Cette approche, qui implique la récupération de listes de pairs à partir d'une URL ou d'un fichier, a été considérée comme une avancée pratique.
-
Une investigation plus approfondie sur les nœuds relais légers, potentiellement à l'aide d'outils comme Wharfkit, a été convenue comme un moyen d'améliorer la propagation du réseau et de faciliter le processus de connexion pour les opérateurs.
-
L'équipe réexaminera les fonctionnalités précédemment proposées mais non fusionnées qui visent à améliorer les mécanismes globaux de découverte de réseau.
Ces prochaines étapes visent à répondre aux besoins immédiats de stabilité et de convivialité tout en jetant les bases de solutions à long terme plus robustes en matière de gestion de réseau.
Cet article a été créé avec le soutien d'une technologie alimentée par l'IA, en s'appuyant sur plusieurs sources réputées. Le contenu final a été soigneusement examiné et édité par l'équipe éditoriale de BlockzHub afin de garantir précision, clarté et cohérence. Les sources d'information originales sont créditées lorsque cela est approprié et requis. Les opinions exprimées dans cet article ne reflètent pas nécessairement les points de vue ou les positions officielles de BlockzHub. Cet article est uniquement destiné à des fins informatives et ne doit pas être considéré comme un conseil financier ou professionnel. Investir comporte des risques, et il est recommandé de consulter un conseiller financier qualifié avant de prendre toute décision d’investissement.