Passer au contenu principal
Toutes les collectionsLes médias axés sur EOS
Résumé de la table ronde des opérateurs de nœuds EOS [Novembre 2023 #1] État d'avancement de Leap 5.0, plan de migration, corrections EOS VM OC terminées, publication de la RC3 en décembre et plus encore.
Résumé de la table ronde des opérateurs de nœuds EOS [Novembre 2023 #1] État d'avancement de Leap 5.0, plan de migration, corrections EOS VM OC terminées, publication de la RC3 en décembre et plus encore.

Publié le 17 novembre 2023

Charles Arroyo-Bishop avatar
Écrit par Charles Arroyo-Bishop
Mis à jour il y a plus d'un an

Auteur : Markus Hinrichs

Éditeur : Randall Roland

Traducteur : Charles Arroyo-Bishop

Les opérateurs Node, les développeurs du noyau Antelope et les membres de la communauté se réunissent chaque semaine pour parler du réseau et de son développement. L'objectif principal de chaque table ronde des opérateurs de nœuds est le suivant :

"...d'améliorer le protocole Antelope (en particulier) pour les opérateurs de nœuds".

Les tables rondes ont lieu tous les mercredis. Visitez le canal Telegram pour obtenir des informations sur la participation. La Fondation du réseau EOS fournit des tutoriels et de la documentation pour ceux qui souhaitent apprendre les bases de l'exploitation d'un nœud EOS.

Vous trouverez ci-dessous une liste des tables rondes contenues dans ce résumé bimensuel :

  • 9 novembre : Statut de Leap 5.0, plan de migration, discussion sur le mode OC Auto, risque potentiel pour les nœuds non mis à niveau, etc.

  • 15 novembre : EOS VM OC Correes Completed, Anticipated RC3 Release in Early-Mid-December, Issues Discussion.

N'oubliez pas de consulter les notes de réunion et les commentaires sur GitHub. Les vidéos se trouvent sur le YT de l'ENF.

9 novembre : Statut de Leap 5.0, plan de migration, discussion sur le mode OC Auto, risque potentiel pour les nœuds non mis à jour et plus encore.

Mise à jour du statut de Leap 5.0 :

  • Le travail pour Leap 5.0 est pratiquement terminé depuis quelques semaines.

  • Un problème en suspens lié aux bibliothèques BLS est en cours de résolution pour la Release Candidate 3 (RC3).

  • Aucun nouveau changement significatif n'est attendu dans la RC3 par rapport aux discussions précédentes.

Plan de migration pour la mise à jour vers la version 5.0 :

  • Le paramètre par défaut est désormais "ES VM OC enable equals AUTO", activant le mode OC de manière sélective en fonction du contexte.

  • Discussion sur la gestion des réseaux hétérogènes où certains nœuds passent à la version 5.0 alors que d'autres ne le font pas.

"Il y a quelques conditions dans lesquelles un problème potentiel pourrait survenir ; cela dépend de la charge importante du réseau (CPU)". Brian Hazzard

  • Il est recommandé aux nœuds utilisant des versions antérieures d'activer l'option "ES VM OC enable ON" afin de suivre le débit plus rapide des nœuds Leap 5.0 (plus efficace en termes de mémoire, plus efficace en termes de CPU, etc.)

  • Une communication claire et l'implication de la communauté seront cruciales pour gérer tous les problèmes qui surviennent et éventuellement aider les membres de la communauté à mettre à jour leurs nœuds.

Discussion sur le mode OC Auto :

  • Clarification sur le mode OC Auto qui dépend du type de machine (producteur ou non-producteur) et des contrats de système.

  • Les producteurs utilisent OC pour les contrats système EOSIO ; les non-producteurs utilisent OC pour tous les contrats sauf configuration contraire.

Risques potentiels pour les nœuds non mis à niveau :

  • Si un producteur ne passe pas à la version 5.0, en mode OC, les blocs peuvent ne pas être vérifiés par d'autres producteurs en cas de forte charge de contrats hors système.

  • La dynamique de la contre-pression peut encourager les nœuds non mis à niveau à se mettre à niveau.

"... Et ils devraient se mettre à niveau... S'il y a une charge, il faut se mettre à niveau" Matthew Darwin

Calendrier de mise à disposition de Leap 5.0 :

  • La version stable devrait être disponible dans quelques semaines, et la version rc3 dans une semaine environ.

  • Les opérateurs de nœuds sont encouragés à tester les versions candidates sur les nœuds de non-production, en commençant par les réseaux de test.

  • Recommandations de mise à jour en temps voulu pour les nœuds de production et de non-production sur les réseaux principaux.

Rapports sur les problèmes et contributions :

  • Reconnaissance des rapports sur les problèmes, en particulier de la part de contributeurs actifs comme Matthew.

  • La plupart des problèmes critiques ont été traités, et rc3 incorpore les corrections de rc2+.

Brian Hazzard exprime sa gratitude pour les précieux retours d'information, la participation active à la table ronde des opérateurs du nœud d'Antelope et au canal communautaire est très appréciée. L'appel se termine par une invitation à rejoindre la session de la semaine prochaine.

15 novembre : EOS VM OC Fixes Completed, Anticipated RC3 Release in Early-Mid-December, Issues Discussion.

Mise à jour du statut de la version 5.0

  • Les corrections de la fonction hôte d'EOS VM OC sont terminées.

  • Bake-off entre deux versions de la fonction hôte avec des différences de performance.

  • La version 5.0 RC3 devrait être disponible entre le 6 et le 14 décembre.

  • Demande de test de la RC3 sur des réseaux de test ou des nœuds non-BP en production.

Retour d'information et discussion sur les questions soumises

Prise en charge des étiquettes arbitraires sur les pairs P2P (Kevin Heifner)

  • Discussion sur le besoin d'étiquettes arbitraires, car elles ajoutent de la complexité et réduisent la lisibilité.

  • Selon Matthew Darwin, il serait probablement préférable d'ajouter une structure JSON pour des informations supplémentaires sur les pairs.

  • Envisager de restructurer la configuration du peering avant la mise en œuvre.

"Il ne sera de toute façon pas inclus dans Leap 5, il est donc logique d'attendre ce travail de refonte."

Suggestion de Mathew Darwin : Ne pas forcer le vidage des fichiers d'état à la sortie de Nodeos

  • La discussion a tourné autour de cette suggestion et de son impact sur les performances globales du système.

  • Kevin Heifner considère le flushing comme crucial mais reconnaît les problèmes associés, tels qu'un délai considérable lors des redémarrages. Ce défi découle de la nécessité de vider non seulement le petit fichier nodeos, mais aussi de nombreux fichiers provenant d'autres chaînes.

  • Dans ce contexte, Ross a partagé un article Medium discutant des améliorations potentielles de ZFS.

  • Kevin a recommandé de résoudre le problème évoqué et a préconisé de tester la vidange avec Leap 5.0. Il a souligné les nombreuses améliorations de performance dans Leap 5.0, y compris la fonction de nœud privé mappé, qui a le potentiel d'accélérer de manière significative le processus de vidange.

Consignation des options non par défaut, à raison d'une par ligne

  • Lorsque nodeos démarre, il enregistre toutes les options autres que celles par défaut sur une longue ligne.

  • C'est un choix de style selon Brian Hazzard

Raisonnement pour l'utilisation de la délimitation des lignes :

  • Implémentée pour améliorer la grepabilité, facilitant la recherche dans les fichiers journaux.

  • Raisonnement pour la consolidation en une seule ligne :

    • Considérée comme utile pour le débogage, elle augmente la probabilité d'être incluse dans un collage de ligne de journal.

    • Améliore l'aspect pratique et simplifie l'utilisation dans les situations de dépannage.

Ajouter une nouvelle fonctionnalité : Compatibilité avec l'état

  • Proposition d'un script de service conçu pour faciliter les vérifications de compatibilité, réduisant ainsi les délais.

  • Une délibération sur l'utilisation des snapshots et des codes de sortie Nodeos a suivi.


Sources et références

Avez-vous trouvé la réponse à votre question ?