Auteur: Marco González
Editeur: Randall Roland
Traducteur: Vincent Davoine
Les opérateurs de nœuds, les développeurs du noyau 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 le suivant :
“...pour améliorer le protocole Antelope (en particulier) pour les opérateurs de nœuds”.
Les réunions ont lieu tous les mercredis de 14h à 15h UTC (de 13h à 14h UTC pendant l'heure d'été). L'EOS Network Foundation fournit des tutoriels et de la documentation pour ceux qui souhaitent apprendre les bases de l'exploitation d'un nœud EOS (et plus encore).
Vous trouverez ci-dessous la liste des deux tables rondes qui font l'objet de cette synthèse bimensuelle :
7 juin : Améliorations et gestion P2P, feedback 4.0, configurations de nœuds, mises à jour consensuelles
14 juin : Solutions historiques, pare-feu Antelope, innovation à long terme
Des notes de réunion et des commentaires supplémentaires sont disponibles sur GitHub. Les enregistrements vidéo se trouvent sur la chaîne YT de l'ENF.
7 juin : Améliorations et gestion du P2P, commentaires sur la version 4.0, configurations des nœuds, mises à jour du Consensus
La réunion du 7 juin a été essentiellement une discussion ouverte. À l'approche du mois de septembre, l'accent est mis sur la préparation de Leap 5.0.
Aperçu
L'amélioration de la gestion des opérations des nœuds est un intérêt récurrent de la communauté. L'amélioration du P2P fait l'objet d'une grande partie des commentaires.
Mises à jour
prévoir la mise à jour du consensus en septembre (Leap v5.0)
Améliorations P2P
Les améliorations apportées au P2P continuent de retenir l'attention des opérateurs de nœuds. Les principaux problèmes concernent la stabilité des transactions, la fiabilité et la "qualité de vie" globale des opérateurs de nœuds. Les domaines cibles identifiés qui aident à réaliser les meilleures solutions sont les suivants :
bande passante
visibilité
gestion p2p
connectivité
synchronisation
flux de nœuds appropriés
Les semaines précédentes ont donné un aperçu des sujets susmentionnés. La section suivante vise à clarifier les choses et à faire gagner du temps au lecteur. Attendez-vous à un rapport complet (de la part de l'équipe) sur les améliorations du P2P après des discussions plus approfondies et un retour d'information.
Visibilité et gestion P2P
Une meilleure visibilité et une meilleure gestion sont nécessaires pour accroître l'efficacité. L'accent est mis sur l'état visible des nœuds d'un réseau de pairs, qui permet aux opérateurs d'identifier leurs connexions préférées à un moment donné.
Comparées à une boîte noire, les informations sur les pairs peuvent laisser un opérateur dans l'incertitude quant à l'endroit où il peut trouver les blocs dont il a besoin. Les types de données importants ici sont les suivants :
connaissance des pairs qui ont exigé des blocs
l'endroit d'où proviennent les blocs
les appels de blocs spécifiques
lorsqu'un départ est effectué pour un autre nœud
maintenir des informations pertinentes sur l'état de la situation
Flux et synchronisation des nœuds
Le flux de données sortant devrait être plus important que le flux entrant. La désignation actuelle pour la synchronisation est un délai avant de passer au nœud suivant. Les améliorations de la synchronisation P2P sont également le sujet d'une récente conversation sur GitHub.
Le flux de nœuds peut augmenter l'efficacité en éliminant le besoin de se battre pour la même information. Cependant, il peut y avoir un problème de sécurité lorsque les changements ne sont pas motivés et que le nombre de pairs reste étrangement stable. Les solutions évoquées sont les suivantes :
afficher tous les pairs
sélectionner automatiquement l'homologue le plus approprié
faire correspondre les données à l'action
ne se connecter qu'aux nœuds ayant le bloc souhaité
Plus de retours sur les fonctionnalités P2P et d'autres éléments identifiés
La labellisation d'Ethereum a de nouveau permis d'établir une comparaison. La réévaluation continue des pairs a été suivie par la volonté des pairs de produire des blocs. Cependant, l'augmentation de la disponibilité générale a soulevé des problèmes de sécurité et de bande passante par rapport à la limite des blocs.
Les commentaires de la communauté accompagnent généralement les expériences. Vous trouverez ci-dessous les grandes lignes des descriptions détaillées :
Leap util mentionné
l'exécution des tests sur la dernière version
plus grande exposition aux comportements indésirables
augmentation de l'intelligence (via l'automatisation) de l'affaissement du nœud par rapport au mode de rattrapage
une faible latence, un débit élevé et des données complètes sont les signes d'une connexion saine
bloks_log
pare-feu
équilibreur de charge
informations d'en-tête
problèmes de bande passante
Une question de suivi a été réexaminée :
L'étiquetage des types de pairs (par exemple, interne ou externe) peut-il aider les développeurs d'Antelope à améliorer l'efficacité de la synchronisation ?
La communauté continue de travailler à l'élaboration d'un réseau plus sain au fil du temps. Tout le monde est encouragé à essayer la version 4.0.1 et à faire part de ses commentaires sur les questions qui s'y rapportent.
En route pour Leap 5.0
Après la discussion sur la gestion par les pairs, des sujets ont été abordés, principalement liés à la mise à jour du consensus Leap 5.0, prévue pour le mois de septembre.
une meilleure estimation de la date de publication sera probablement disponible à la fin du mois d'août
le plus grand défi pour une mise à niveau consensuelle est la coordination ; l'amélioration de la coordination pour la version 5.0 sera probablement un sujet futur
recommander une date d'activation "go-no-go" et spéculer sur la flexibilité de l'activation
les deux prochains mois seront consacrés à la préparation par le biais d'articles, etc.
14 juin : Solutions historiques, Antelope Firewall, innovation à long terme
Lors de la réunion du 14 juin, les participants ont à nouveau réfléchi à des domaines d'amélioration persistants.
Aperçu
Des solutions historiques avec des bibliothèques indépendantes ont été proposées de temps à autre. Le pare-feu Antelope fait l'objet d'une attention accrue. Avec Leap 5.0 à l'horizon, les participants à la réunion ont pris le temps d'explorer l'innovation à long terme.
Mises à jour
nous visons la sortie du patch 4.0.2 pour cette semaine et les notes suivront bientôt
Le rapport sur les améliorations du P2P arrive ; nous travaillons à répondre aux commentaires et à discuter des plans formels.
Une conversation GitHub sur la faisabilité des instruments découplés reste dans l'esprit de plusieurs opérateurs. Cependant, ce sujet conserve le statut de reporté.
Une vidéo sur la gestion des données a été fournie dans le chat pour compléter la discussion d'aujourd'hui.
Solutions d'historique
L'ouverture de l'échange d'idées et du retour d'information était une solution de sous-flux de l'esprit profond (historique). Les opérateurs de nœuds ont de nombreuses raisons de s'intéresser à une solution historique. En voici quelques-unes.
Au début de la discussion sur l'historique, il a été question de dfuse, Graph et (plus tard) firehose. L'objectif était de garder les bibliothèques et l'instrumentation séparées hors de la base de code nodeos. Une solution non-nodeos pour l'abstraction de l'historique reste dans l'esprit des développeurs. Cependant, les solutions à court terme (par exemple, la satisfaction partielle des besoins via les traces) l'emportent encore sur le rapport effort/récompense élevé pour le moment.
Les efforts indépendants en vue d'une solution d'historisation approfondie de l'esprit ont offert davantage de perspectives et de commentaires. Voici les points forts qui ont occupé environ un quart de la réunion :
les réactions de la communauté suggèrent qu'une solution est faisable, bien que la mise à l'échelle soit un problème
la désérialisation/sérialisation alternative est reconnue comme un intérêt pour la communauté et un effort investi
l'allègement des conversions binaire-hex (goulots d'étranglement) est une motivation importante
suivi par l'équipe de développement avec une solution axée sur l'opérateur à l'esprit
la fonction nodeos continue d'évoluer
les opérateurs sont encouragés à présenter des solutions (nodeos) innovantes similaires
Un participant à la réunion a décrit un prototype (pour la fonction de la bibliothèque) qui remplaçait l'enregistreur par un pointeur de passage vers nodeos avec l'intention que nodeos renvoie les informations appropriées. Cette solution permet de gagner en rapidité et en flexibilité, en particulier pour les applications de type jeu. Les limites du prototype concernent la sécurité et le langage (par exemple, il fonctionne bien avec Python mais pas avec Javascript). À long terme, une interface basée sur une chaîne pour l'expérimentation de différentes structures de données est considérée comme un objectif souhaitable.
Antelope Firewall
Le pare-feu d'Antelope a été brièvement évoqué. Une subvention de l'ENF finance la construction du nouveau pare-feu. Quelques points ont été rapidement évoqués :
API development for Leap nodes
remove load balancing
L'intérêt du pare-feu réside dans des éléments tels que la limitation du débit, les interactions entre les comptes et d'autres éléments (par exemple, les fichiers JSON indépendants).
Innovation à long terme
La réunion s'est achevée sur quelques idées "folles" concernant l'avenir de l'environnement Antelope. Les idées suivantes ne font pas partie de la feuille de route de l'équipe de développement :
la compilation en C#/C+ pour être utilisée avec Leap et l'EVM
les premières constructions intéressantes d'EOSIO
exécution de modèles d'IA déterministes
Bien que la conversation ait été de courte durée, elle a suscité un débat sur les constructions "folles" d'EOSIO. La communauté est encouragée à partager de telles créations en l'honneur du 5e anniversaire d'EOS.