Auteur : Marco González
Éditeur : Randall Roland
Traducteur : Vincent Davoine
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 le suivant :
"...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 la liste des deux tables rondes contenues dans ce résumé bimensuel :
21 juin : Améliorations P2P Document énumérant le problème et les solutions
28 juin : Découpage des blocs, planification du Leap 5.0, IF, OC
Des notes de réunion et des commentaires supplémentaires sont disponibles sur GitHub. Les enregistrements vidéo se trouvent sur le YT de l'ENF.
21 juin : Améliorations P2P Document listant le problème, solutions
La réunion du 21 juin a poursuivi la discussion sur le P2P. Un document GitHub répondant à certains des commentaires des dernières semaines a guidé la discussion.
Vue d'ensemble
Le document d'orientation définit clairement le problème. La définition d'une solution acceptable s'aligne étroitement sur les commentaires précédents.
Mises à jour
Le patch Leap 4.0.3 a été publié pendant la réunion.
Décomposition du document d'orientation sur les améliorations P2P
La page du document d'orientation est divisée en plusieurs sections : le problème, la solution, les questions, les ressources et les commentaires.
Problème : opportunités, public et stratégie
Les groupes d'utilisateurs ciblés ont des besoins différents. Les priorités sont désormais mieux comprises.
Le public identifié est basé sur les antilopes et :
des "personnes techniquement compétentes" (opérateurs de nœuds) intéressées par des "solutions fiables, rentables et simplifiées".
Pour aligner le problème sur le développement de base, il faut se concentrer sur "l'amélioration de l'expérience de l'utilisateur et de l'efficacité de l'infrastructure". Une mise en œuvre réussie devrait permettre "une adoption plus large et un succès du protocole Antelope".
Si l'on revient aux possibilités offertes aux utilisateurs cibles, les principales priorités sont les suivantes :
La première sur la liste est d'"améliorer la sélection des pairs en mode de rattrapage pour les blocs disponibles".
La bande passante a fait l'objet de nombreuses discussions ces dernières semaines. L'amélioration des contrôles de la "consommation de bande passante par les pairs" est la priorité suivante. La prévention des abus et la rotation automatique des pairs sont des points essentiels.
La troisième grande priorité est la "capacité d'étiqueter les connexions entre pairs comme étant internes ou externes". La réussite dans ce domaine devrait permettre de résoudre le problème des "niveaux de confiance au sein de l'infrastructure interne".
Le document et/ou la vidéo décrivent d'autres questions, notamment l'interface utilisateur basée sur un terminal, les listes noires d'homologues et la synchronisation.
Définition d'une solution et identification des risques
Le nom donné à l'opportunité de produit décrite ci-dessus est "Améliorations P2P". Les quatre principaux critères de réussite, tels qu'ils sont énumérés dans le document GitHub, sont les suivants
Améliorer le temps de synchronisation pour un nouveau nœud ou un nœud redémarré
Réduire le nombre d'étapes pour configurer un nouveau nœud
Améliorer la fiabilité des transactions qui transitent par le réseau P2P
Améliorer la vitesse des transactions qui transitent par le réseau P2P
Le processus d'identification des risques est guidé par un article (The Four Big Risks) écrit par le Silicon Valley Project Group. La question posée est centrée sur le P2P Peer Discovery RFP concernant les délais parallèles :
"Y a-t-il un risque de conflit ou de chevauchement ?"
Voir la page de documentation pour plus de ressources et de questions.
Commentaires et réactions sur la réunion
Les réponses des participants sont les suivantes
les nœuds internes et les goulets d'étranglement
la vitesse de stockage est essentielle
bloks-log mentionné comme une préoccupation concernant la lecture et les pairs locaux (par exemple, le nombre d'opérations et la synchronisation)
options de synchronisation limitées
la bande passante par rapport à la portée de l'état (peut ne pas être un problème si la bande passante est suffisante et si les pairs tournent).
Dialogue de clôture
La réunion s'est terminée par des questions de clarification. Une question a été posée sur l'étranglement (ralentissement) en tant que stratégie de gestion de la bande passante. D'après les réactions, l'étranglement est considéré comme une option par opposition à la déconnexion des pairs.
L'équipe de développement invite les opérateurs de nœuds à contribuer à l'orientation des prochaines étapes. L'attention a été attirée sur la section de la répartition des tâches ("Features/Epics") de la page du document. La bande passante et les mécanismes de contrôle y sont mentionnés.
28 juin : Découpage des blocs, planification de Leap 5.0, IF, OC
La réunion du 28 juin a permis d'identifier le découpage des blocs comme un domaine à améliorer. La planification de Leap 5.0 inclut le temps de préparation, les nouvelles normes, IF, OC, et plus encore.
Vue d'ensemble
Les opérateurs de nœuds ont partagé leur expérience avec le processus actuel de découpage des blocs. Les diagnostics, l'automatisation et d'autres types de solutions ont été abordés. Le dernier tiers de la réunion a été consacré à la planification et aux préparatifs du Leap 5.0.
Mises à jour
il n'y a pas de nouvelle mise à jour sur Leap 4.0
l'équipe de développement continue de retravailler le calendrier provisoire de la version 5.0 en vue d'une version candidate.
Plus d'informations sur Leap 5.0 dans une section ultérieure.
Préoccupations de la communauté
La parole a été donnée aux membres de la communauté pour qu'ils fassent part de leurs préoccupations. La discussion s'est engagée sur le découpage des blocs et sur les différents problèmes liés aux attentes actuelles de la version 4.0.3 par rapport à la version 5.0. Le découpage des blocs a suscité un intérêt immédiat. L'utilisation de leap-util pour découper une solution pour une exception bloks-log a suscité plusieurs commentaires. La nécessité d'étendre le découpage à plusieurs centaines de blocs semble pouvoir être améliorée. Des coupes plus petites qui peuvent identifier les erreurs (exceptions) sont une fonctionnalité intéressante à ajouter.
Thèmes approfondis
Deux sujets ont semblé ressortir du discours d'ouverture :
le formatage et le contenu de leap-util (par exemple, le test de fumée)
le besoin de revenir en arrière sur bloks-log
Voici une liste des points spécifiques mentionnés. Les éléments de la liste suivent un ordre chronologique et logique général tel qu'il a été enregistré lors de la réunion :
affichage vs. fonctionnalité
améliorations potentielles pour une réduction minimale
assurer une solution sécurisée
suggestion d'ajouter un découpage successif (un par un)
un outil de diagnostic de l'élagage pourrait déterminer les blocs corrompus
une solution d'autoréparation qui veille à ne pas supprimer automatiquement les blocs
solutions de nœuds publics ou privés
la correction complète via un instantané renvoie aux mises en garde concernant les nœuds publics et les nœuds privés.
La communauté semble vouloir des outils de diagnostic et de récupération plus faciles. Pour plus de détails, visitez le leap-util n'est pas en mesure d'exécuter avec succès un test de fumée détaillé et de découper le blocklog. #1348.
PLANIFICATION DE LEAP 5.0
Comme indiqué précédemment, la planification d'une version candidate de Leap 5.0 a commencé. L'équipe de développement s'efforce d'atténuer le processus long et compliqué d'une mise à niveau par consensus. Leap 5.0 établira une procédure standard. Quelques mois sont nécessaires pour préparer la communauté. Les plans prévoient une version avant les vacances, c'est-à-dire un début de déploiement en septembre.
Il est prévu que Leap fasse l'objet de deux versions majeures par an. L'une d'entre elles nécessitera probablement une mise à niveau par consensus. La réduction des coûts d'exploitation des nœuds est l'une des principales préoccupations. Cela inclut la réduction des coûts pour les opérateurs de nœuds lors de l'ajout de nouvelles chaînes. Des commentaires ont été formulés sur les avantages de l'expérience et de l'optimisation (RAM, CPU et espace disque). L'importance d'une mise à niveau vers la version 4.0 a été soulignée.
Les deux principales caractéristiques de mise à niveau du protocole pour la version 5.0 sont les suivantes:
Finalité instantanée (IF)
Fonctionnalités du compilateur d'optimisation (OC)
La finalité instantanée semble être l'élément décisif des deux. La finalité instantanée reste une initiative clé du plan initial de l'ENF pour le nouvel EOS. Les fonctions d'optimisation du compilateur sont des avantages en termes de performances, principalement destinés à améliorer l'EVM. Cependant, il existe des avantages globaux de l'OC qui incluent les producteurs. Voir Add eos-vm-oc-enable auto mode #1322 pour plus d'informations.
D'autres éléments sont développés en parallèle et devraient être intégrés dans les prochaines versions afin de ne pas retarder la version 5.0.
Dialogue de conclusion
La réunion se termine par un examen des fonctionnalités d'OC pour la version 5.0. Le développement actuel porte sur des améliorations fondamentales. L'OC devrait d'abord fonctionner sur les contrats du système eosio (par exemple pour les jetons et EOS EVM) avant les autres fonctionnalités mentionnées. Les nouvelles fonctionnalités et la préparation de Leap 5.0 resteront probablement au centre des réunions futures.