Auteur : Marco Gonzàlez
Éditeur : Randall Roland
Traducteur : Charles Arroyo-Bishop
Les opérateurs de nœuds, 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 chaque mercredi de 14h à 15h UTC.
À partir du 1er février, les discussions de la table ronde des opérateurs de nœuds ont porté sur les paramètres de configuration pour Leap v3.2 et au-delà. Les nœuds à usage spécial ont été inclus le 8 février. Les nœuds dédiés à des fins spéciales ont alimenté les réunions des 15 et 22 février. Le groupe a continué à faire avancer le document "ébauche de taxonomie des rôles que jouent les différents nœuds d'Antelope".
15 février : Nœuds à usage spécial (suite) - Nœuds API
Regardez la table ronde du 15 février sur le YouTube de l'ENF. Lisez les notes sur GitHub d'EOS Nation (Leap).
MISE À JOUR :
Comme indiqué précédemment, Leap v4.0.0 devrait commencer à être testé sur Jungle en mars. Une mise à jour consensuelle n'aura probablement pas lieu avant septembre. Aussi, attendez-vous à un gel du code avant les premiers tests dans les semaines à venir.
PRINCIPAUX SUJETS ABORDÉS
La dernière réunion s'est arrêtée sur les nœuds d'API. La réunion du 15 février a revu les définitions fondamentales des types de nœuds. Quelques types de nœuds ont été introduits cette semaine, ainsi qu'un estimateur de transaction. Voir l'(ébauche) de la taxonomie des nœuds d'Antilope pour plus de détails.
À propos des types de nœuds
Les classifications des types de nœuds ont été définies pour la première fois la semaine dernière. L'accent a été mis sur les objectifs primaires.
Types de nœuds discutés précédemment
Nœud producteur de blocs, objectifs principaux et configuration des meilleures pratiques
Nœud relais de blocs uniquement et configuration des meilleures pratiques
Nœud de relais pour blocs et transactions
Début de l'étude des nœuds d'API
Deux principaux types de nœuds d'API ont été identifiés :
Le nœud d'API Push : "Accepte les transactions via les clients HTTP et agit comme un relais de transaction sortant.
"N'accepte pas les transactions p2p entrantes, sauf s'il agit également en tant que nœud de relais de blocs et de transactions."
Chain API Node : "Fournit l'accès aux primitives de la blockchain en lecture... et aux données d'état..."
Les types de nœuds historiques ont des exigences très différentes de celles que peut fournir un nœud API de chaîne.
Voir le projet de document de taxonomie pour des notes détaillées et une discussion potentielle dédiée.
Les classifications des types de nœuds de cette semaine se terminent par les utilitaires généraux suivants :
Nœud de développeur : pour les tests, remplit tous les rôles de nœud sur un dispositif local dans un réseau à nœud unique.
Voir le projet de document pour plus de détails.
Estimateur de transactions : accepte, valide et applique les transactions sans les relayer sur le réseau.
Voir le document préliminaire pour les cas d'utilisation.
Deux autres types de nœuds (classés comme "feeders" lors de la discussion de la semaine prochaine) :
Nœud de capture instantanée : prend périodiquement une capture instantanée et publie un fichier sur un hôte interne/externe.
Voir le projet de document pour une définition plus détaillée.
Trace API Node : enregistre les informations de trace transactionnelle sur le disque local d'un client pour y accéder via l'API.
Solutions de 2ᵉ couche
Un nœud fournisseur de ressources a été l'une des premières solutions de niveau 2 identifiées :
Noeud fournisseur de ressources : accepte, interprète, valide et exécute une logique commerciale sur les transactions du client pour déterminer si une cosignature est justifiée pour couvrir les coûts de CPU/NET/RAM.
Une note a été incluse à propos du service de nœud fournisseur de ressources qui pourrait évoluer vers une solution clé en main et plugin.
PERSPECTIVES
Plusieurs sujets coïncident avec la discussion sur les types de nœuds et les solutions potentielles de la couche 2. Ils comprennent l'élaboration des meilleures pratiques entre les types de nœuds, l'exploration éventuelle de paquets de nœuds spéciaux et les drapeaux intégrés pour les défauts de configuration.
22 février : Nœuds à usage spécial (suite) - Feeders et niveau 2
Regardez la table ronde du 22 février sur le site YouTube de l'ENF. Lisez les notes sur EOS Nation (Leap) GitHub.
MISE À JOUR :
L'ENF prévoit de présenter les fonctionnalités de Leap v4.0.0 avant le gel du code mentionné précédemment. Revenez nous voir pour connaître la date de la table ronde qui présentera les nouvelles fonctionnalités.
SUJETS CLÉS DISCUTÉS
La discussion sur les nœuds à usage spécial s'est poursuivie avec des commentaires sur le (projet de) document de taxonomie des nœuds d'Antelope. Les notes détaillées de la réunion sont disponibles ici. Un nœud DeepMind Logger et un nœud State History ont été présentés dans le cadre de l'avancement d'une solution de niveau 2. Les services d'historique sont d'un intérêt particulier ici.
Notez que l'idée de "chargement prioritaire" a été évoquée. L'idée est d'instituer une règle de trois coups pour résoudre un problème de longue date. Le chargement prioritaire semble efficace même lorsqu'il s'agit de traiter les problèmes de transaction difficiles de WAX. L'allongement des délais d'une demi-seconde à quelques secondes seulement permettrait de "nettoyer" un nœud. Cette solution ne modifierait pas de manière significative les opérations existantes (pour la plupart). L'extension du chargement prioritaire à une ou deux minutes serait exagérée. Une solution simple et efficace, même si le sujet n'a pas été abordé lors de l'enregistrement.
Conceptualisation des nœuds d'alimentation
Voir la section précédente pour un mot sur les types de nœuds. Les deux types de nœuds d'alimentation discutés fonctionnent en recevant des blocs de la part de pairs configurés. Les deux permettent également d'activer les solutions d'historique de couche 2 :
Nœud DeepMind Logger : "sérialise continuellement le bloc actuel, les traces, etc. et les diffuse dans le stdout pour un traitement ultérieur...".
Nœud d'historique d'état : "stocke les blocs/traces dans un fichier d'historique d'état..."
Solutions de 2ᵉ couche
Les réflexions de la semaine dernière sur les solutions de niveau 2 ont été suivies de quelques autres services. Le formatage a été la clé de la discussion.
Service de capture d'événements : Il s'occupe du traitement des sorties des nœuds d'alimentation dans des formats spéciaux afin de garantir les objectifs visés. Un service de fournisseur d'historique a été utilisé comme exemple.
Service fournisseur d'historique : un service de base disponible dans n'importe quel format qui fournit des données historiques à la demande d'un client via une API.
Notez que le service de capture d'événements doit gérer la résolution des fourches.
PERSPECTIVES
En plus des éléments de perspectives listés pour le 15 février, plusieurs autres éléments ont été listés sous Next Steps - voir l'(ébauche) de taxonomie des nœuds d'Antelope pour plus de détails. Les solutions de la couche 2 devraient se poursuivre la semaine prochaine. Aussi, une matrice de caractéristiques pour les feeders doit être définie.
Sources et références