Auteur : Marco González
Éditeur : Randall Roland
Traducteur : Charles Arroyo-Bishop
Les opérateurs Node, 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 Node 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 14 UTC à 15 UTC (de 13 UTC à 14 UTC pendant l'heure d'été). La Fondation du réseau EOS 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 une liste des tables rondes contenues dans ce résumé bimensuel :
19 juillet : Changements de configuration recommandés par l'ENF pour la version 5.0
26 juillet : Annulée
Des notes de réunion et des commentaires supplémentaires sont disponibles sur GitHub. Les vidéos se trouvent sur le YT de l'ENF.
19 juillet : Changements de configuration recommandés par l'ENF pour la version 5.0
La table ronde du 19 juillet pourrait s'avérer être le moment où la communauté des opérateurs de nœuds passe de la version 4.0 d'Antelope à la version 5.0. Les mesures prises pour préparer le déploiement de la version 5.0 commenceront probablement par les changements de configuration de l'ENF discutés lors de la réunion d'aujourd'hui.
VUE D'ENSEMBLE
Eric Passmore a posté des notes sur Telegram qui décrivent les recommandations de l'ENF pour les changements de configuration de nodeos. Les points principaux de ces notes sont listés dans la section suivante.
Eric a commencé par attirer l'attention sur le fait que beaucoup de choses ont changé depuis que B1 a publié la version 2.0. Changer la configuration est logique à bien des égards. Néanmoins, l'ENF fonde ses recommandations sur des tests de performance et des données empiriques.
SUJET : Recommandations publiées sur le canal Telegram des opérateurs de nœuds du 18 juillet
Le premier élément identifié est celui des transactions dans l'environnement de production qui dépassent 30 ms. C'est ici que la mise à jour des transactions en lecture seule ajoutée dans Leap 4.0 se distingue. L'augmentation des limites profite immédiatement aux transactions en lecture seule et à celles de l'environnement de production en général.
Les changements de configuration suggérés par l'ENF en juillet 2023 (tels qu'ils ont été publiés par Eric Passmore) sont les suivants.
1. Pour les changements de configuration en lecture seule, seules les versions 4.0 et ultérieures de Leap sont concernées :
"(165ms) read-only-read-window-time-us à 165,000"
"(151ms) max-transaction-time à 151"
2. Pour les changements multisig, seul le testnet Jungle est affecté (pour le moment). Aucun changement n'est encore nécessaire pour le réseau principal :
"(150ms) max_transaction_cpu_usage to 150,000"
"(200ms) max_block_cpu_usage to 200,000"
Les changements suggérés resteront concentrés sur le Jungle TestNet jusqu'à ce qu'un plan de déploiement soit coordonné avec la réunion hebdomadaire des opérateurs de nœuds.
Les changements suggérés précèdent la configuration par défaut qui devrait accompagner la sortie de la version 5.0. Le message d'Eric se termine par la notification que les paramètres de configuration feront partie des éléments suivis pour s'assurer que les producteurs et les chaînes disposent des mêmes paramètres afin de garantir un déploiement coordonné de la version 5.0.
Discussion lors de la réunion
Eric a rejoint la table ronde pour discuter des changements recommandés. La communauté n'a pas eu besoin de s'engager dans une grande discussion pour saisir l'intention de l'ENF. Il n'y a pas eu non plus d'objections.
Les sujets brièvement abordés sont les suivants
clarifications sur le temps
l'augmentation de 30 à 151 millisecondes offre une grande marge de manœuvre
il faut s'attendre à quelques semaines de tests sur Jungle pour les nouveaux changements
l'accent mis sur une coordination harmonieuse commence avec les changements de configuration
suffisance de la facturation subjective pour les échecs de transaction
La facturation subjective permet de dissuader les transactions qui échouent en se basant sur le coût de l'unité centrale et des changements de configuration.
Notez qu'il est impossible de simuler parfaitement l'activité sur le réseau EOS. Il se peut que les changements prévus doivent être modifiés. Il convient d'examiner plus avant ce qui pourrait mal tourner (en particulier en ce qui concerne les producteurs de blocs).
C'est à ce stade qu'un nouvel article de blog a été suggéré. Les opérateurs de nœuds sont mentionnés à plusieurs reprises dans le billet du 24 mai, intitulé "An Introduction to Subjective Billing and Lost Transactions" (Introduction à la facturation subjective et aux transactions perdues).
D'autres mentions notables relatives aux changements de configuration incluent les tests de performance et d'étalonnage. Il est certain que les configurations tiendront la route.
Version 5.0, facturation subjective et accélération de la sortie des blocs
Comment la version 5.0 d'Antelope Leap va-t-elle accélérer la sortie des blocs ? L'article du 24 mai (mentionné ci-dessus) présente des mises à jour de la facturation subjective :
"Les nouvelles fonctionnalités de Mandel 3.1 permettront aux opérateurs de nœuds de définir le paramètre de temps de décroissance de la facturation subjective de leur nœud lors de l'initialisation. Cette option ajustera le temps nécessaire pour mettre à zéro la facture subjective d'un compte."
L'annonce du 8 août, Leap v3.1 Release Features & Additional Tools, présente de nouveaux outils de gestion des transactions :
"Les articles précédents ont exploré comment le système de facturation subjectif peut causer des pertes de transactions et ont décrit les correctifs existants pour les problèmes courants du cycle de vie des transactions tels que les pertes de transactions. La version 3.1 de Leap introduit de nouveaux outils pour résoudre ces problèmes et d'autres obstacles à l'expérience de l'utilisateur."
De profondes améliorations se profilent à l'horizon alors que le système de facturation subjective arrive à maturité avec la version 5.0. Au lieu d'avoir des transactions en attente et non appliquées, le bloc suivant peut commencer immédiatement. Il a même été suggéré que 12 blocs puissent être complétés en un seul tour. La prudence a été de mise en ce qui concerne le contrôle du dernier bloc.
La réunion s'est achevée prématurément, la communauté étant impatiente de se coordonner pour la version 5.0.