Auteur: Marco González

Editeur: Randall Roland

Traducteur: Vincent Davoine

Les opérateurs Node, 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 noeuds est le suivant :

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

Les réunions ont lieu tous les mercredis de 14h UTC à 15h UTC.

Les deux premières tables rondes du mois de mars ont poursuivi la discussion sur les nœuds spéciaux, notamment en ce qui concerne les meilleures pratiques. La table ronde du 1er mars a exploré les objectifs des nœuds BP par rapport aux meilleures pratiques. La table ronde du 8 mars s'est achevée sur les nœuds de relais en bloc. Si vous êtes ici pour parler du "gel du code" imminent, attendez-vous à ce qu'une annonce soit faite dans les jours qui suivront la table ronde du 8 mars. En ce qui concerne la version testnet de Leap 4.0.0, l'équipe de développement reste dans les temps pour l'objectif de fin mars/début avril.

Le "projet de taxonomie des rôles joués par les différents nœuds d'Antilope" contient des notes détaillées. Pour explorer le début de la discussion sur les nœuds spéciaux, visitez la section intitulée "Post Upgrade meetings" sur GitHub.

Regardez la table ronde du 1er mars sur la chaîne YouTube de l'ENF. Lisez les notes sur EOS Nation (Leap) GitHub.

La table ronde du 1er mars est la quatrième d'une discussion en cours sur les nœuds à usage spécifique. Il s'agit notamment d'élaborer des modèles de ressources plus efficaces pour l'ensemble de l'écosystème. Cela inclut la règle des trois coups contre les besoins subjectifs de facturation.

Le groupe a repris les notations concernant les fournisseurs d'historique. Les types de nœuds primaires qui mentionnent spécifiquement l'historique dans le projet de document sont les suivants :

Les solutions de seconde couche qui mentionnent l'historique sont les suivantes :

En ce qui concerne l'"historique de l'état", on peut citer, entre autres, les questions suivantes

Voir également les suggestions de suivi pour l'historique.

La liste des types de nœuds se termine par le nœud fournisseur de ressources, la troisième solution de couche 2 de la liste. Son objectif est d'améliorer l'expérience de l'utilisateur. Bien que le nœud fournisseur de ressources utilise actuellement node.js, il pourrait éventuellement devenir décentralisé comme un plugin d'API. Le projet de document de taxonomie définit le nœud fournisseur de ressources comme suit :

La réunion s'est poursuivie avec les meilleures pratiques et les efforts et exigences pour une configuration optimale. L'un des principaux objectifs des meilleures pratiques est d'identifier les minima dans les réseaux d'Antilope (par exemple WAX, Telos...).

Il y aura probablement des débats sur les meilleures pratiques, surtout si l'on considère que les besoins varient d'un réseau à l'autre. Par exemple, tous les éléments suivants varient en fonction de l'utilisation du réseau de la blockchain :

Les exigences en matière de dispositifs ont pris le pas sur la discussion relative aux meilleures pratiques. Les opérateurs doivent vérifier la configuration globale de nodeos lorsqu'ils changent de type de nœud. Par exemple, l'exécution avec des démarrages et des arrêts par rapport à l'exécution ininterrompue devrait réajuster une unité centrale selon les recommandations d'AtticLabs. Voir le projet de document de taxonomie pour le lien AtticLabs et d'autres exigences relatives aux dispositifs comme la RAM ECC, les processeurs x86, etc.

La table ronde s'est terminée par des notes sur les meilleures pratiques en matière de sécurité et sur la non-réutilisation des clés matérielles.

Le nœud API de la chaîne a reçu les derniers mots concernant les meilleures pratiques de configuration de nodeos pour les nœuds producteurs de blocs. Les recommandations sont les suivantes :

La discussion sur les nœuds de l'API en chaîne s'est achevée sur ce qui devrait être disponible (par exemple, simplifier avec seulement Getinfo, bien que Prometheus puisse fournir une autre solution).

Il faut garder à l'esprit que certains types de nœuds nécessiteront des configurations variables. La réunion se termine par d'autres points de suivi (dans la section Next Steps du projet de document sur la taxonomie).

Regardez la table ronde du 8 mars sur la chaîne YouTube de l'ENF. Lisez les notes sur EOS Nation (Leap) GitHub.

L'équipe d'Antelope indique être sur la bonne voie pour une version candidate à la fin du mois ou au début du mois d'avril. Le développement d'Antelope Leap 4.0.0, axé sur l'avenir, est terminé pour le moment. L'annonce d'un "gel du code" est imminente. Une version candidate 4.0.0 devrait suivre d'ici quelques semaines.

La discussion initiale a porté sur les meilleures pratiques de configuration de nodeos pour les nœuds producteurs de blocs. Le peering est presque toujours interne. Protéger un réseau de nœuds internes avec une clé WireGuard (par exemple) est efficace. WireGuard n'est qu'une option parmi d'autres. Ces clés permettent d'éviter les connexions inattendues et indésirables.

Les scénarios de cas d'utilisation particuliers (par exemple la resynchronisation) ont rejoint les points de suivi dans la section "Prochaines étapes". Il est également conseillé d'envisager d'accroître l'efficacité.

Le reste de la table ronde s'est concentré sur les nœuds de relais en mode bloc et sur les meilleures pratiques en matière de configuration. Le groupe a examiné en détail le nombre de connexions. Lors d'une réunion précédente, 10 à 15 connexions ont été jugées appropriées pour le fichier de configuration. Ce petit nombre de connexions n'est qu'un point de départ.

En ce qui concerne Leap 3.2, il est prudent de maximiser le nombre de connexions des nœuds de relais en mode bloc uniquement entre 25 et 50. Plusieurs notes ont été ajoutées :

La première considération mentionnée pour les exigences relatives aux dispositifs des nœuds de relais en bloc est qu'il en faut plus d'un pour éviter un point de défaillance unique.

Une grande partie du reste de la discussion a porté sur la connectivité et la vitesse. L'accent a été mis sur une connexion internet fiable. Il en va de même pour un disque rapide avec une forte concentration sur l'écriture. Voir d'autres bonnes pratiques dans le projet de taxonomie pour des commentaires sur les blocs logs complets ou partiels. Notez que Leap 4.0 devrait disposer d'une fonction de connexion automatique aux nœuds.

Une distinction importante est faite ici à propos d'une idée fausse très répandue. Sur les chaînes Antelope, un snapshot est juste l'état actuel. Cette définition est différente de celle d'Ethereum. Ainsi, pour les chaînes Antelope, un réseau de pairs n'a besoin que d'une quantité "suffisante" d'un journal de blocs complet. Un historique complet n'est pas nécessaire pour les relais internes des chaînes Antelope.

Tout au long de la discussion sur le projet de taxonomie, il a été fait mention de l'impact de l'ajustement des variables en dehors des meilleures pratiques. Par exemple, un nœud de relais bloc uniquement n'accepte rien d'autre que des blocs. Notez également que Leap 4.0 ne nécessitera peut-être pas de nœuds de relais de type bloc uniquement.

La table ronde de la semaine prochaine poursuivra la discussion sur les meilleures pratiques pour la configuration de nodeos spécifique aux nœuds API.