Le 12 mars 2025, la réunion des opérateurs de nœuds EOS a rassemblé des acteurs clés de la communauté EOS pour discuter des développements récents et des défis. L'accent était principalement mis sur le déploiement de la version 3.8.0 des contrats système EOS et sur les problèmes de performance du réseau, en particulier dans les testnets. Les participants ont partagé des idées sur la façon d'améliorer la connectivité et d'optimiser le réseau pair-à-pair, tout en abordant les défis uniques posés par des temps de bloc rapides. Cette réunion était un pas vers le raffinement de l'écosystème EOS et l'assurance de sa performance robuste à l'avenir.
Points clés
-
Le déploiement des contrats système EOS v3.8.0 a été approuvé avec succès avec toutes les signatures requises.
-
Les mises à jour clés dans v3.8.0 incluent l'introduction de 'RAM cadeau' et de chaînes de noms de compte réservées.
-
Les testnets rencontrent des retards de propagation des votes, ce qui a conduit à des discussions sur des solutions potentielles.
-
Un nouveau système de pairage basé sur le gossip est en cours de développement pour améliorer l'efficacité du réseau pair-à-pair.
-
Des temps de bloc rapides créent des défis pour la propagation des votes, soulignant la nécessité d'une meilleure coordination entre les nœuds.
Déploiement des contrats système EOS v3.8.0
Approbation et exécution de MSIG
Bonne nouvelle concernant les contrats système ! Le MSIG nécessaire pour déployer les contrats système v3.8.0 a reçu le feu vert. Il a en fait obtenu toutes les 15 signatures requises juste avant le début de la réunion. C'est plutôt efficace.
Résumé des changements dans v3.8.0
Alors, qu'est-ce qui est nouveau dans v3.8.0 ? Voici le récapitulatif :
-
Ils ont corrigé certains problèmes avec les clauses Ricardiennes. Je ne suis pas développeur, mais j'entends dire que c'est une bonne chose.
-
Ils ont ajouté "RAM cadeau". Cela vous permet de donner de la RAM à quelqu'un d'autre, mais il ne peut pas la transférer ou la revendre. Intéressant.
-
Ils ont mis en place des réservations de chaînes pour les noms de compte. Cela vise à protéger les marques, afin que quelqu'un ne puisse pas simplement s'approprier un nom déjà utilisé.
Prochaines étapes
Restez à l'affût le 18 mars. C'est à ce moment-là que le vecteur haché des chaînes réservées sera révélé. Cela empêchera les gens de créer de nouveaux comptes avec ces chaînes réservées. C'est tout un enjeu de garder les choses en ordre et d'éviter le squattage de noms, je suppose.
Mises à jour des testnets et problèmes de connectivité
Problèmes de propagation des blocs dans les testnets
Donc, après la mise à jour vers la version 1.1.1, certains producteurs de blocs ont remarqué que les votes ne se propageaient pas aussi vite qu'ils le devraient. C'était particulièrement perceptible sur les testnets Jungle et Kyland. C'est comme si certains nœuds avaient du mal à faire passer le mot sur les derniers blocs. Ils ont ajusté les paramètres de pairage, et cela a semblé aider un peu.
Causes possibles des retards de propagation des votes
Pourquoi les votes étaient-ils lents ? Eh bien, plusieurs choses pourraient se passer. La mise à jour elle-même, de 1.1.0 à 1.1.1, pourrait avoir perturbé la façon dont les connexions sont gérées. Il y a eu des changements dans la "gestion des connexions en double", et peut-être que cela a introduit un comportement étrange. De plus, il y a cette fonctionnalité "Block MAC" qui a été ajoutée dans 1.1.0. Elle pourrait filtrer ou bloquer des connexions alors qu'elle ne le devrait pas.
Dépannage et solutions suggérées
Voici ce qu'ils ont essayé : désactiver le Block MAC. Et devinez quoi ? Cela a semblé résoudre le problème ! Mais, bien sûr, ils doivent faire plus de tests pour être sûrs que c'est vraiment la solution. Voici une liste de choses qu'ils envisagent :
-
Plus de tests sur divers testnets.
-
Analyse du trafic réseau avec et sans Block MAC.
-
Vérification de l'utilisation du CPU et de la mémoire pendant la propagation des votes.
-
Examen des modifications de code liées à la gestion des connexions.
Il s'agit de comprendre exactement ce qui cause les retards et de s'assurer que la solution ne casse rien d'autre.
Optimisation du réseau pair-à-pair
Importance du pairage coordonné
En ce moment, le réseau EOS repose sur les producteurs de blocs (BPs) pour communiquer efficacement entre eux. C'est un réseau mondial, donc faire circuler l'information rapidement est super important. La configuration actuelle nécessite que les BPs se coordonnent beaucoup pour s'assurer que les blocs se propagent rapidement. Pensez-y comme ceci :
-
Tout le monde doit savoir à qui parler.
-
Ces connexions doivent être fiables.
-
Si quelque chose ne va pas, cela peut ralentir tout.
Améliorations proposées : Pairage basé sur le gossip
L'équipe examine une nouvelle façon de gérer les connexions entre les BPs. Cela s'appelle le "pairage basé sur le gossip". L'idée est d'automatiser une partie du processus de connexion. Voici comment cela pourrait fonctionner :
-
Les BPs trouveraient automatiquement des pairs en utilisant un protocole de gossip.
-
Les messages seraient signés pour s'assurer qu'ils sont légitimes.
-
Seuls les meilleurs BPs partageraient des informations de connexion, gardant les choses sécurisées et efficaces.
Discussions sur le consensus et la performance du réseau
Des temps de bloc rapides créent des défis uniques
Les temps de bloc rapides d'EOS, à seulement une demi-seconde, signifient que les votes doivent se propager super vite. Certains nœuds voient des temps de réponse allant jusqu'à 500 ms, ce qui rend difficile l'envoi des votes à temps. Cela crée des problèmes intéressants pour le réseau. C'est comme essayer de gagner une course alors que vous êtes déjà à mi-chemin de la ligne d'arrivée.
Besoin de coordination centralisée dans un réseau décentralisé
Ça peut sembler étrange, mais même dans une configuration décentralisée, vous avez toujours besoin d'une certaine coordination centrale, surtout en ce qui concerne qui parle à qui sur le réseau. Certaines personnes pensent que les producteurs de blocs (BPs) ne devraient pas simplement compter sur le logiciel pour gérer l'optimisation du réseau. Il a été mentionné que :
-
La coordination manuelle est toujours importante.
-
L'automatisation logicielle n'est pas une solution complète.
-
Le dimensionnement des finalisateurs pourrait aider à améliorer la résilience.
Conclusion
En résumé, la réunion des opérateurs de nœuds EOS du 12 mars 2025 a mis en lumière des avancées significatives et des défis persistants au sein de l'écosystème EOS. Le déploiement réussi des contrats système v3.8.0, y compris des fonctionnalités telles que "RAM cadeau" et des protections des noms de compte, marque un pas en avant pour la communauté. Cependant, les problèmes de propagation des votes dans les testnets suite à la mise à jour récente indiquent qu'il reste encore du travail à faire. Les discussions autour de l'optimisation des connexions pair-à-pair et de la nécessité d'une meilleure coordination entre les producteurs de blocs reflètent les complexités de la maintenance d'un réseau performant. Alors que la communauté EOS continue de relever ces défis, l'équilibre entre décentralisation et gestion efficace du réseau reste un point focal clé.
Cet article a été rédigé avec l'assistance de l'IA pour recueillir des informations provenant de plusieurs sources fiables. Le contenu a été examiné et édité par notre équipe éditoriale afin de garantir sa précision et sa cohérence. Les opinions exprimées sont celles de l'IA et ne reflètent pas nécessairement celles de BlockzHub. Les sources d'information originales sont créditées chaque fois que cela est approprié et nécessaire. Cet article est à titre informatif uniquement et ne constitue pas un conseil financier. Investir comporte des risques, et vous devez consulter un conseiller financier qualifié avant de prendre toute décision d'investissement.