Auteur : Markus Hinrichs
Editeur : 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 parler du réseau et de son développement. L'objectif principal de chaque table ronde des opérateurs de nœuds est le suivant :
"...d'améliorer le protocole Antelope (en particulier) pour les opérateurs de nœuds".
Les tables rondes ont lieu tous les mercredis. Visitez le canal Telegram pour obtenir des informations sur la participation. 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.
Vous trouverez ci-dessous une liste des tables rondes contenues dans ce résumé bimensuel :
18 octobre : Amélioration de la configuration du processeur, discussion sur la fonctionnalité Early Blocks, simplification de la configuration à l'échelle du réseau, etc.
25 octobre : Souhaits et aspirations pour le format d'appel de l'opérateur de nœud, derniers jalons pour arriver à RC3
N'oubliez pas de consulter les notes de réunion et les commentaires supplémentaires sur GitHub. Les vidéos se trouvent sur le YT de l'ENF.
18 octobre : Leap 5.0 en route : Premiers blocs, améliorations des performances et commentaires de la communauté
Publication de Leap 5.0 et tests :
La réunion a commencé par une discussion approfondie sur la sortie de Leap 5.0.
Les membres de la communauté ont été fortement encouragés à participer activement aux tests de la version candidate, RC2, dans le but principal d'identifier et de résoudre les problèmes éventuels avant la sortie officielle de la version stable.
Changements dans l'option de pourcentage d'effort du CPU :
Un changement significatif a été introduit concernant l'option de pourcentage d'effort du CPU.
La proposition consistait à passer de l'utilisation de valeurs en pourcentage à la configuration de l'effort du CPU en millisecondes.
Les options existantes, telles que le pourcentage d'effort du processeur, l'effort du processeur du dernier bloc, le décalage du dernier bloc et les versions du dernier bloc, devaient être remplacées par une nouvelle option appelée "produce block offset ms".
Détails de la nouvelle option "produce block offset ms" :
La nouvelle option "produce block offset ms" permet aux opérateurs de nœuds de spécifier le nombre de millisecondes qu'ils souhaitent allouer à l'ensemble du cycle, qui se compose de 12 blocs.
Ce décalage joue un rôle crucial dans la détermination du temps alloué à la gestion de la latence de production des blocs.
Il a été précisé que ce changement n'aurait pas d'incidence sur le mécanisme de consensus et qu'il était spécifiquement conçu pour améliorer l'efficacité de la production de blocs.
Production et test précoces des blocs :
Les discussions suivantes ont porté sur l'introduction de la production anticipée de blocs dans Leap 5.0.
Michael, EOSUSA, a présenté le concept de modification des paramètres de l'horloge du système, ce qui a suscité des inquiétudes quant aux problèmes potentiels et aux conséquences involontaires.
Des inquiétudes ont été exprimées sur la façon dont la production anticipée de blocs pourrait affecter le réseau et si elle pourrait conduire à des fourches ou à d'autres complications.
Performances lors des tests en laboratoire :
Kevin Heifner a fait part de son enthousiasme quant aux améliorations potentielles des performances apportées par la production anticipée de blocs.
La discussion a mis en évidence le fait que la production anticipée de blocs donne plus de temps aux transactions pour être incluses dans les blocs, ce qui bénéficie en fin de compte à l'efficacité du réseau.
Le compilateur optimisé (OC) de la VM EOS a été reconnu comme un important facteur d'amélioration des performances, en particulier pour les DApps et les contrats EOSIO.
L'attention a été attirée sur la probabilité d'une augmentation de la charge transférée vers des solutions historiques pour gérer l'augmentation des performances.
" Il y a une tonne d'améliorations de performance entre les jours 1.8 et aujourd'hui, comme c'est un moteur beaucoup mieux réglé et donc vraiment il devrait être capable de gérer la charge" Kevin Heifner, OCI
Configuration de "produce block offset ms" et valeurs par défaut :
La conversation s'est orientée vers la configuration de "produce block offset ms" et les valeurs par défaut suggérées.
Une valeur par défaut de 450 millisecondes a été proposée pour "produce block offset ms", les discussions soulignant l'importance des paramètres par défaut pour influencer le comportement des nœuds.
La flexibilité a été soulignée comme un facteur clé, permettant aux opérateurs d'adapter les paramètres aux conditions spécifiques de leur réseau.
Blocs tardifs et synchronisation des horloges :
La question des blocs tardifs et de leur gestion dans le contexte de la production de blocs précoces a été abordée.
L'impact potentiel de la synchronisation des horloges et de la latence du réseau sur les blocs tardifs a été pris en considération.
Kevin a précisé que les blocs tardifs pouvaient conduire à des microforks, et le rôle de la synchronisation de l'horloge dans ce contexte a été exploré.
Définition du "Max Transaction Time" et du "Read Only Read Window Time" :
La discussion a porté sur le paramètre "Max Transaction Time" et sur les modifications possibles.
Kevin Heifner a recommandé un réglage par défaut d'"environ 500 millisecondes"
L'importance de la configuration des paramètres pour le "Read Only Read Window Time" a été soulignée, en mettant l'accent sur l'optimisation du réseau pour améliorer les performances.
Il a été suggéré que les opérateurs de nœuds individuels définissent ces valeurs en fonction de leurs cas d'utilisation spécifiques.
Mise en œuvre par consensus sur la chaîne :
Le concept de contrôle des paramètres par consensus sur la chaîne a été introduit pour simplifier les changements de configuration à l'échelle du réseau.
"Désormais, les BP peuvent contrôler les paramètres à l'échelle du réseau par consensus" Kevin Heifner
Discussion sur la PR pour l'étiquetage des pairs Peer-to-Peer :
Une Pull Request en attente concernant l'étiquetage des pairs a été brièvement mentionnée.
En raison de contraintes de temps et de l'absence de Matthew Darwin, membre crucial de l'équipe, une discussion détaillée sur ce sujet a été reportée à une prochaine réunion.
La réunion s'est terminée par un appel à la communauté pour qu'elle teste activement Leap 5.0 rc2 et fasse part de ses commentaires afin d'assurer une transition en douceur vers la version stable.
25 octobre : Souhaits et aspirations pour le format d'appel de l'opérateur du nœud, derniers jalons pour arriver à la RC3
Sujet principal : Comment poursuivre la table ronde des opérateurs de nœuds ?
Perspectives et engagement :
Ross d'EOS Sphere a apprécié les idées de l'équipe technique.
Shaq a souligné le besoin d'informations sur le Leap et de points de vue techniques.
Michael d'EOSUSA a reconnu l'impact de la collaboration sur la maturation des logiciels.
Kevin Heifner, OCI, a souligné l'importance du retour d'information de la part des opérateurs de nœuds.
Souhaits pour les futures réunions :
Discussion sur l'inclusion de la documentation dans les futurs appels.
Les types de documentation mis en évidence, y compris les documents relatifs au protocole, aux opérateurs de nœuds et aux développeurs.
Prise en compte de l'évolution des fonctionnalités et des changements potentiels.
Appel à une exploration plus approfondie des fonctionnalités à venir.
Formats de réunion :
L'idée de différents appels pour des sujets spécifiques a été débattue, les participants se demandant si des appels ad hoc ou de courte durée seraient utiles.
Des inquiétudes ont été exprimées quant au fait qu'un passage à des formats plus larges pourrait, par inadvertance, transformer ces appels en réunions axées sur les développeurs, entraînant le désengagement des opérateurs de nœuds.
Sélection des participants :
Les participants ont exprimé le souhait que des développeurs de poids (par exemple Nathan James) se joignent occasionnellement à ces appels. L'idée d'un échange dans les deux sens, en faisant participer Kevin Heifner aux réunions de développeurs et en tirant parti de l'expertise de Nathan pour la documentation et l'orientation, a été proposée.
L'équipe de rêve des participants comprendrait Kevin Heifner, Nathan James et des contributeurs réguliers (Michael EOSUSA, Ross (EOS Sphere), Matthew Darwin). Les opérateurs de nœuds à forte infrastructure, Aaron Cox (Greymass), et les spécialistes L2 comme Stan d'EOS Amsterdam pourraient également être inclus.
Fréquence des réunions :
On s'oriente vers le maintien d'un calendrier hebdomadaire.
Durée des réunions :
Il est suggéré de maintenir la durée des réunions à une heure.
Possibilité de prolonger les réunions pour des discussions approfondies.
Heures de réunion alternatives :
Défi de perturber les routines et de fragmenter la participation.
Proposition d'appels supplémentaires à des heures différentes.
Amélioration de l'ordre du jour :
Proposition d'un ordre du jour flexible avec des mises à jour de l'état d'avancement et des sujets principaux.
Évaluation des notes de réunion :
Discussion sur l'adéquation des notes de réunion.
Il est recommandé de demander l'avis des personnes absentes.
Enregistrements des réunions :
Aucune préoccupation concernant l'enregistrement des réunions.
Notes et transcriptions générées par l'IA :
Les notes générées par l'IA sont les bienvenues, à condition que l'enregistrement soit actif.
Augmentation de la participation :
Le dernier sujet concernait l'augmentation de la participation, avec la suggestion d'impliquer activement les non-participants afin d'élargir la participation à ces discussions précieuses.
Partie concernant les jalons de la mise à jour Leap RC2 → RC3
L'accent a été mis sur la disponibilité du CPU pour la signature des transactions, avec une référence spécifique à un paramètre de configuration, le "produce block offset", et des stratégies pour l'optimiser afin d'obtenir des performances maximales.
Des jalons ont été définis, l'accent étant mis sur la résolution des problèmes pour la prochaine version candidate. Certains problèmes critiques, notamment l'échec des tests BLS sur les versions ARM, ont été abordés, et des travaux sont en cours pour y remédier.
Paramètres de configuration
Le réglage sain du paramètre "produce block offset" a été un sujet important, la question a été soulevée par Ross et Kevin est intervenu avec une explication en profondeur de la façon dont ce paramètre est amélioré dans la prochaine version.
La RC2 avait un paramètre par défaut de 90% ou 600 millisecondes, ce qui était considéré comme trop conservateur.
Dans la nouvelle version, le nouveau paramètre exprime le décalage en millisecondes, ce qui permet un réglage plus fin. Les participants ont discuté des différents paramètres et des avantages potentiels, comme l'amélioration du traitement des transactions et la réduction de la latence.
"Il y a une augmentation potentielle de la latence pour les transactions qui atteignent le 12e bloc, mais seulement pour celles qui atteignent le dernier bloc, et c'est donc un petit négatif pour un grand positif pour tout le reste" Kevin Heifner
L'avantage le plus important est réalisé pendant les périodes de congestion de la chaîne. Il permet également de traiter plus efficacement les transactions qui échouent en leur donnant plus de temps pour être évaluées sans que cela ait un impact négatif sur le débit global. En fait, il optimise l'utilisation de l'unité centrale.