Réunion des opérateurs de nœuds Vaulta (anciennement EOS) : plans MSIG, modifications du contrat système et tests du réseau Gossip

La dernière réunion des opérateurs de nœuds Vaulta ($EOS $A) du 11 juin 2025 a abordé d'importants changements à venir. Nous avons parlé d'un nouveau plan de multi-signature (MSIG) pour les contrats système, d'une refonte complète du fonctionnement du jalonnement et des récompenses, et de la manière dont nous traiterons les réclamations BPay. Il y a également eu beaucoup de discussions sur le test de la nouvelle version Antelope Spring v1.2 RC3 sur le réseau Jungle. Il semble que les choses avancent vite, et tout le monde se prépare à ces mises à jour.

Points clés à retenir

• Une mise à jour majeure du contrat système Vaulta est prévue pour juillet, ce qui changera la façon dont le jalonnement et les récompenses fonctionnent, en déplaçant tout vers le jeton $A.

• Le nouveau système ne permettra le jalonnement et le déjalonnement qu'en jetons $A, et les récompenses seront également réclamées en $A.

• Nous travaillons avec des opérateurs de proxy pour les aider à passer progressivement au nouveau système de jetons.

• Il est prévu d'ajouter un wrapper pour les réclamations BPay afin de s'assurer qu'elles fonctionnent toujours avec le nouveau système de jetons.

• Les opérateurs de nœuds testent Antelope Spring v1.2 RC3, en particulier le nouveau peering basé sur le gossip, pour s'assurer qu'il est prêt pour la production, avec des recommandations pour les configurations de production.

Prochain MSIG Vaulta pour le déploiement du contrat système

Ainsi, la Fondation Vaulta prévoit une transaction multi-signature (MSIG). Il semblerait qu'ils visent une proposition vers le 8 juillet. L'objectif ? La faire exécuter d'ici le 15 juillet, mais cela dépend d'un nombre suffisant d'approbations.

Ce MSIG concerne les contrats système mis à jour, regroupant les changements apportés au jalonnement, aux récompenses et à l'enregistrement des clés de pair.

Qu'est-ce qui change, exactement ?

• Tout d'abord, ils veulent que le jalonnement et le déjalonnement ne se fassent que via le contrat core.vaulta. Pensez-y comme une rationalisation de l'ensemble du processus.

• Les BP pourront enregistrer des clés de pair. C'est nécessaire pour le peering BP basé sur le gossip de Spring v1.2.0.

• Vous ne pourrez plus jalonner à partir d'EOS. Le jalonnement en $A sera toujours disponible via core.vaulta.

• Il en va de même pour le déjalonnement – plus de déjalonnement vers EOS. Le $A est la voie à suivre via core.vaulta.

• Et les réclamations de récompenses BP en EOS ? Non. Il faut réclamer ces récompenses en $A via core.vaulta.

Refonte du jalonnement et des récompenses

D'accord, le système subit une petite refonte en ce qui concerne le jalonnement et les récompenses. En gros, tout devra se faire sous forme de jetons. Plus d'émission directe d'EOS pour les récompenses, ce qui est assez important.

Pensez-y comme ça :

• Jalonnement et déjalonnement ? Tout par jetons.

• Réclamer des récompenses ? Oui, des jetons encore.

• L'objectif ? Un contrôle plus strict sur la distribution des jetons. Logique, non ?

Je sais que les développeurs principaux travaillent encore sur les détails, mais l'idée principale est de rationaliser les choses et de surveiller de plus près le flux de jetons. Il s'agit de rendre le système plus efficace et, je suppose, plus facile à gérer à long terme.

Coordination de l'infrastructure proxy

Il a été question de la manière de travailler avec les grands proxys de jalonnement pendant la transition. L'essentiel est de s'assurer que tout le monde est sur la même longueur d'onde alors que Vaulta passe à un nouveau système.

• Certains proxys commenceront à prélever des frais dans le nouveau jeton mais continueront à verser des récompenses en EOS pendant un certain temps. C'est comme un point intermédiaire.

• Le plan est de passer éventuellement à un système de récompenses entièrement basé sur les jetons. C'est une chose progressive.

• Les opérateurs de nœuds devraient se manifester s'ils connaissent d'autres proxys ou pools qui pourraient être affectés par ces changements. Plus il y a d'informations, mieux c'est.

Lacune dans la gestion des réclamations BPay

Il semble que les mises à jour actuelles du contrat système aient en quelque sorte oublié l'intégration de la récompense de réclamation eosio.bpay. Oups ! Cela signifie que les producteurs de blocs pourraient ne pas être en mesure de réclamer leurs récompenses correctement pendant la transition.

Pour résoudre ce problème, l'idée est d'ajouter une action de wrapper. En gros, ce wrapper permettrait aux BP de réclamer leurs récompenses dans le nouveau format de jeton. C'est important pour plusieurs raisons :

• Cela assure le bon fonctionnement pendant le basculement.

• Cela garantit que personne ne manque les récompenses qui lui sont dues.

• Cela donne à chacun un peu de répit, de sorte qu'il y a moins de chances que quelque chose se brise.

En gros, c'est une solution rapide pour éviter un mal de tête potentiel. Le calendrier est flexible, donc cela ne devrait rien gâcher d'autre.

Examen de la restriction de la fenêtre de réclamation

Il y a cette vieille règle qui dit que vous ne pouvez réclamer des choses que dans une fenêtre de 24 heures, plus une seconde supplémentaire. C'est un peu ennuyeux, n'est-ce pas ? Eh bien, on parle de la changer. Quelqu'un a suggéré d'agrandir cette fenêtre ou simplement de supprimer la restriction avec une mise à jour du contrat.

Les opérateurs de nœuds semblent être d'accord avec l'idée, mais ils pensent qu'il est préférable d'attendre que le MSIG soit terminé. C'est logique, une chose à la fois. Un futur MSIG pourrait inclure ce changement pour un déploiement en douceur. En gros, ils ne veulent pas s'en mêler maintenant et risquer de causer plus de problèmes que cela n'en résout. Il s'agit de maintenir la stabilité, vous savez ?

Test et améliorations d'Antelope Spring v1.2 RC3

Antelope Spring v1.2 RC3 est là, et il apporte des changements intéressants. Cette version se concentre sur la correction de certains problèmes gênants et sur la flexibilité pour les opérateurs de nœuds.

Ce n'est pas une mise à niveau obligatoire pour la participation aux tests, donc pas de pression. Voici un bref aperçu :

• La mise à jour réduit les adresses de serveur. Cela devrait aider à réduire les erreurs de mauvaise configuration. Nous sommes tous passés par là, n'est-ce pas ?

• Elle permet désormais les adresses IP de pair de gossip en double. C'est une bonne nouvelle pour ceux qui gèrent des configurations plus complexes.

• Le comportement de peering de gossip restera le même que celui de RC2. Donc, si vous testez déjà, les choses devraient vous sembler assez familières.

Validation du réseau de peering basé sur le gossip

Le prochain cycle de test vise à s'assurer que la découverte automatique des pairs et la connexion fonctionnent réellement. L'objectif est de voir si les nœuds peuvent se connecter simplement en utilisant les données de gossip qu'ils reçoivent.

Voici le plan :

• Tous les participants doivent supprimer toutes leurs entrées de pair manuelles, à l'exception d'un nœud désigné. Cela force le système à s'appuyer sur le gossip.

• L'idée est de confirmer que les nœuds se connectent uniquement en fonction des données de gossip qu'ils reçoivent.

• Le groupe Telegram Jungle Testnet coordonnera toutes les configurations et la planification. Gardez donc un œil sur cela pour les mises à jour.

Recommandations de peering de production

En ce qui concerne les producteurs de blocs (BP) en production, le peering externe direct n'est généralement pas une bonne idée du point de vue de la sécurité. Il est beaucoup plus sûr de mettre en œuvre une approche plus stratifiée.

Voici ce qui est recommandé :

• Mettre en place une architecture de « nœud canari » : BP → Nœud canari → Réseau externe.

• Conserver vos configurations de gossip sur les nœuds canaris, et non directement sur les BP.

• Cette configuration aide à la compatibilité du pare-feu et maintient vos opérations BP isolées de toute bizarrerie du réseau. En gros, c'est comme avoir une zone tampon pour protéger le cœur de votre opération.

Conclusion

Ainsi, cette réunion des opérateurs de nœuds Vaulta du 11 juin 2025 a couvert beaucoup de terrain. Ils ont parlé du prochain plan de multi-signature (MSIG), ce qui est très important pour les nouveaux contrats système. Cela signifie des changements dans la façon dont le jalonnement et les récompenses fonctionnent, en déplaçant tout vers les jetons $A. Ils ont également discuté de la collaboration avec les opérateurs de proxy et du test du réseau Jungle pour Antelope Spring v1.2 RC3. De plus, ils ont soulevé des problèmes avec les réclamations BPay et la façon dont ils pourraient résoudre le problème du calendrier des réclamations de récompenses plus tard. Il semble qu'il y ait beaucoup de pièces mobiles, mais tout cela vise à améliorer le système.

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.