Auteur: Marco González

Editeur: Randall Roland

Traducteur: Vincent Davoine

Les opérateurs de noeuds, les développeurs principaux d'Antelope et les membres de la communauté se réunissent chaque semaine pour discuter des questions captivantes du jour. L'objectif principal de chaque table ronde des opérateurs de nœuds est :

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

Les réunions ont lieu tous les mercredis de 14h UTC à 15h UTC (de 13h UTC à 14h UTC pendant l'heure d'été). Pour ceux qui souhaitent apprendre les bases de l'exploitation des nœuds EOS, la Fondation du réseau EOS fournit des tutoriels et de la documentation.

Les sujets de discussion ont pris une forme différente au cours des dernières semaines. Ce n'est pas surprenant étant donné le lancement imminent de l'EVM EOS et les premiers tests de Leap 4.0.0.

Lors de la table ronde du 15 mars, quelques ajouts ont été apportés à la section "Nœuds spéciaux" du "projet de taxonomie des rôles joués par les différents nœuds d'Antelope". La réunion du 22 mars a été annulée. Aucun ajout n'a été fait au projet de document le 29 mars.

Les principaux événements ayant un impact sur la communauté sont les suivants :

Les retours de la communauté ont occupé une grande partie du temps des tables rondes du 15 et du 29 mars.

La discussion en cours sur les nœuds spéciaux commence dans la section intitulée "Post Upgrade meetings" sur GitHub. L'assurance a été donnée que la taxonomie des nœuds se poursuivra. Le but ultime est d'améliorer l'expérience et le potentiel des futures opérations de nœuds pour les opérateurs existants et nouveaux.

Regardez la table ronde du 15 mars sur le site YouTube de l'ENF. Lisez les notes sur le GitHub d'EOS Nation (Leap).

La réunion a commencé par plusieurs mises à jour. Un patch (Leap 3.2.2) a été publié pour corriger la stabilité du SHiP. La règle des trois coups a suscité de nombreux commentaires.

Des mises à jour pour DUNE et CDT (contract developer toolkit) sont attendues peu après l'arrivée de Leap 4.0.0 sur le réseau de test.

Leap 4.0.0 sera discuté avec l'ENF lors d'une prochaine table ronde. Pour l'instant, on sait que les tests devraient commencer en mars. Il faut savoir qu'il n'y a pas de plan à court terme pour une mise à jour consensuelle avant l'automne.

La discussion technique a continué à alimenter le projet de document. Des notes détaillées relatives aux nœuds spéciaux en cours et aux discussions antérieures sont disponibles ici.

Les questions relatives aux nœuds ont été reportées à la semaine prochaine. Les points forts de la réunion sont les suivants :

Parmi les objectifs à court terme de la version 4.0.0 RC de Leap, on peut citer :

L'amélioration des performances grâce au multithreading a suscité un intérêt pour le SHiP (State History Plugin). Dans le projet de document sur la taxonomie des nœuds, vous trouverez :

“Journalisation de la console/états d'impression liés à la journalisation de SHIP et de DeepMind. Devrait-il y avoir des limites ?”

De même, quand activer/désactiver SHiP pour les meilleures pratiques. L'exécution parallélisée a également été évoquée ici.

N'oubliez pas que le projet de document sur la taxonomie des nœuds n'est pas axé sur Leap 4.0.0. Du moins, pas encore. Voir le GitHub d'AntelopeIO pour les corrections de bugs concernant la stabilité de SHiP.

La réduction de la latence et la propagation plus rapide des blocs ont suivi. Le peering automatique programmé pour les BP a été abordé afin de garantir la réception du dernier bloc avec un délai minimal. L'appairage automatique avec des nœuds BP proximaux programmés (voir le GitHub d'AntelopeIO) a semblé se démarquer au sein du groupe.

Des notes de version sur la validation, un plugin Prometheus Exporter, et plus encore, peuvent être trouvées sur le GitHub d'AntelopeIO. Consultez également les derniers correctifs Leap 4.0.0 RC et 3.2. Ubuntu 18.04 vs. 20.04 et les problèmes de sécurité connexes ont été mentionnés lors de la conclusion de la table ronde du 15 mars.

La communauté a été invitée à donner son avis sur la manière de concentrer le soutien sur la dernière version stable de Leap à l'avenir.

La communauté ne doit pas s'attendre à une nouvelle version (sans correctif) pour la 3.2. Cependant, des commentaires sont également souhaités sur l'avenir de la 3.2. Une suggestion a été de maintenir (deux) versions stables successives (c'est-à-dire une pour la 4.0 et une autre pour la 3.2). Cependant, les changements d'API doivent encore être pris en compte.

La réunion s'est achevée sur l'assurance que les mois de septembre et d'octobre resteraient le point de mire d'une révision à la hausse du consensus.

Le 22 mars était également la semaine où le code EVM a été achevé et a commencé à être testé.

Regardez la table ronde du 29 mars sur le site YouTube de l'ENF.

Compte tenu de la nature des réunions récentes, il y a plus que le chevauchement habituel des informations. Les lecteurs trouveront peut-être utile de consulter la liste de documents suivante :

Il est à noter qu'aucune note supplémentaire n'a été ajoutée au projet de document le 29 mars.

Comme on pouvait s'y attendre après les tests en direct et le lancement anticipé de l'EVM EOS, ainsi que les tests de Leap 4.0.0 rc2, les mises à jour ont rapidement pris le pas sur la réunion.

Il faut s'attendre à une troisième version candidate d'ici une semaine environ. Alerte au spoiler... le développement effréné et choquant s'est intensifié avec la première mention d'une mise à niveau du consensus 5.0 (pour la saison d'automne à venir). Attendez-vous également à une nouvelle version de CDT dans les semaines à venir et à la prise en charge d'IPv4/IPv6.

APPEL À L'ACTION POUR LES BP → Les BP devraient signer le MSIG pour la création du compte EVM.

L'enthousiasme a conduit à des discussions laxistes sur le sujet :

La discussion sur les "blocs log" s'est concentrée sur la clarté des participants, en particulier en ce qui concerne l'efficacité opérationnelle. Le GitHub d'AntelopeIO détaille 'Blocks Log Splitting'. Il existe un plan de travail pour évaluer l'expérience de l'utilisateur afin de mieux prendre en charge les Mac. Les priorités pour les plugins producteurs incluent les snapshots.

Les sous-thèmes liés au retour d'information sur l'échange de trafic de BP sont les suivants :

Alors que l'anticipation d'un écosystème EOS en pleine croissance s'intensifie, la valeur de l'efficacité administrative et managériale s'est imposée au groupe. Parmi les préoccupations et les intérêts exprimés, on peut citer :

Voici quelques suggestions :

Des conditions ont été identifiées dans lesquelles les notes de mise à jour et la formation peuvent être les plus utiles en période d'innovation rapide. Si les opérateurs de nœuds doivent connaître les dernières fonctionnalités, le processus de mise à niveau peut être amélioré afin d'offrir des avantages qui se répercutent sur l'ensemble de la communauté.

Prometheus reste une priorité. Une amélioration du consensus pour Leap et la mention de "5.0" coïncident avec un calendrier de septembre/octobre.

Prenez la liste suivante à la légère. Non seulement elle prévoit des mois à l'avance, mais la discussion n'a pas été préparée. Parmi les sujets inattendus, citons :

Pour suivre les commentaires ci-dessus, essayez de commencer par le GitHub d'AntelopeIO Optimiser le temps de démarrage des blocs par huangminghuang.

Les commentaires de clôture ont débattu de la meilleure façon de maintenir les anciennes normes, de la clarté d'une solution de surcharge, de l'heure exacte par rapport à une fenêtre de compression, et de l'abandon du décalage des blocs.

La réunion du 29 mars a duré un peu plus longtemps que prévu. Il semble que tous les membres de la communauté EOS soient assis dans la bonne position. Non pas que quelqu'un attende un en-cas grillé au miel en vol. Au contraire, de plus en plus d'yeux prennent conscience de la beauté du paysage qui se profile à l'horizon.

L'EVM, une mise à jour du consensus, le financement de GameFi/metaverse, et bien d'autres choses encore dans les mois à venir nous font vivre une période passionnante.