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 de nœuds 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é). Pour ceux qui souhaitent apprendre les bases de l'exploitation des nœuds EOS, la Fondation du réseau EOS fournit des tutoriels et de la documentation.
La discussion sur les nœuds spéciaux a de nouveau été reportée. Au lieu de cela, les développeurs principaux d'Antelope ont donné un aperçu des générations Leap 4.0 et 5.0 lors des tables rondes du 5 et du 12 avril respectivement. Les développeurs principaux ont cherché à informer la communauté et à obtenir un retour d'information.
05 avril : Mise à jour de la version 4.0.0 d'Antelope et retour d'information
Cette semaine, le groupe a accueilli les développeurs principaux d'ENF pour leur donner un aperçu et des démonstrations de la version 4.0.0. Brian Hazzard a fourni des notes qui sont également disponibles sur le GitHub de la Nation EOS pour le mois d'avril 05. Visionnez l'enregistrement de la table ronde sur le site YouTube de l'ENF.
VUE D'ENSEMBLE
La version 4.0.0 d'Antelope permettra à EOS de renforcer sa position dominante en termes de performances, d'évolutivité et de fiabilité par rapport à d'autres blockchains. Les caractéristiques identifiées (d'après les notes de Brian) sont les suivantes
fournir des performances encore plus élevées grâce au multithreading
réduire la latence et permettre une propagation plus rapide des blocs
fournir plus de contrôle et de visibilité sur les données
amélioration de la qualité de vie des opérateurs de nœuds
Les points à retenir (d'après les notes de Brian) :
get_block est 4x plus rapide et n'est plus sur le thread principal
L'analyse JSON dans nodeos est environ deux fois plus rapide.
les fenêtres multithreads en lecture seule permettent aux fournisseurs d'API d'utiliser autant de threads que possible.
Lin Huang : Transactions en lecture seule
La présentation de Lin Huang a suivi celle de Brian. Lin Huang a parlé des transactions (et des tâches) en lecture seule :
les nouveaux points d'arrivée RPC
les actions d'état non modifiées pour éviter les changements accidentels
l'interdiction des autorisations/signatures
retour systématique d'une trace de la transaction
transactions séparées pour le suivi et l'enregistrement des traces
deep-mind logging
Lin a fait une démonstration de < /cleos push transaction > et des transactions en lecture seule. Les principales caractéristiques des transactions (et des tâches) en lecture seule parallélisées sont les suivantes :
lecture seule : peut être exécutée en parallèle
lecture-écriture : ne peut pas être exécutée en parallèle
fenêtre de lecture : ne peut être exécutée qu'en lecture seule
fenêtre d'écriture : peut être exécutée à la fois en lecture seule et en lecture-écriture ; et séquentiellement sur le thread principal.
Configurations
Vlad : ordonnancement des instantanés et améliorations
Les éléments clés présentés par Vlad pour l'ordonnancement des instantanés sont les suivants
des snapshots pour la planification (uniques, futurs et récurrents)
3 appels API (snapshot_requests) pour réaliser ce qui précède
stockés dans un fichier JSON
Il a décrit les instantanés récurrents comme la fonctionnalité "la plus intéressante". Les instantanés se remplissent tous les 20 blocs et se poursuivent jusqu'à ce qu'on y mette fin. Des instantanés non programmés peuvent être réalisés avec un identifiant.
Vlad a également mentionné un nouvel outil (leap-util) qui ajoute actuellement de nouvelles fonctionnalités et dont le support /cleos sera mis à jour.
Peter Oschwald : Harnais de performance
Peter Oschwald a présenté une démonstration du Performance Harness avec un exemple de ligne de commande et un rapport. A l'origine, il s'agissait d'établir un meilleur moyen d'exécuter des mesures de performance sur différents nœuds opérationnels. Les développeurs pouvaient alors voir comment leurs améliorations pouvaient affecter les performances dans l'ensemble de l'écosystème.
Peter a présenté les trois différentes couches du harnais de performance : simple, basique et avancé. Plus la couche est avancée, plus le nombre de paramètres autorisés est important. De plus amples informations sur le banc d'essai et les configurations typiques sont disponibles dans le README de Pefromance_tests [voir 31:12 de la vidéo].
Peter décrit ensuite le générateur de transactions, qui remplace le plugin associé, et la gestion des grands TPS. Après avoir passé en revue d'autres fonctionnalités, il indique qu'il prévoit de continuer à développer des mesures de performance. Par exemple, mesurer si les performances de nodeos s'améliorent ou se dégradent.
Kevin Heifner : Performance, latence, données et qualité de vie
Kevin Heifner a rapidement passé en revue plusieurs sujets avant de clore la réunion. S'appuyant sur les notes de Brian, Kevin a présenté quatre grands domaines d'amélioration et leurs sous-thèmes :
Performances accrues
Exécution parallélisée des transactions et des tâches en lecture seule
Multi-threading et sécurité des threads
Optimisation de http_plugin
Améliorations subjectives de l'unité centrale
Latence réduite
Auto-peering avec des nœuds BP proximaux planifiés
Validation allégée pour les relais
Contrôle et visibilité des données
Exportateur Prometheus
Séparation des logs pour les blocs et le SHiP
Qualité de vie
Réglage de la valeur absolue du moniteur de ressources
Meilleure logging dans les plugins nodeos
Kevin a ensuite testé le fonctionnement actuel de l'auto-peering. L'exemple a porté sur la connectivité relative à l'ordonnancement BP.
Ensuite, il a fourni quelques notes sur le plugin Prometheus exporter :
IPv4 pour 4.0 permet d'écouter sur un port séparé lorsque le plugin est activé
IPv6 pour la version 5.0
Séparation des logs (spécifier un répertoire d'état différent)
En conclusion de la réunion, il a été mentionné que nodeos avait accès au répertoire (retain) mais pas aux archives. L'historique des états suit le même comportement.
Kevin a terminé avec des micro-optimisations où les blocs se propagent après une validation d'en-tête et n'ont pas besoin de se produire sur le thread principal. En plus d'une amélioration de 4x dans get_block, la propagation des blocs devrait être beaucoup plus rapide dans un environnement 4.0. Il décrit comment "c'est une période plus rapide" et comment plus de la moitié du processus (temps) a été déplacée hors du fil d'exécution principal.
PERSPECTIVES
EOS est la blockchain la plus rapide qui soit. Le développement de la version 4.0.0 d'Antelope rendra EOS nettement plus rapide, plus efficace et plus convivial pour les développeurs.
12 avril : Envisager un environnement 5.0 et des catégories de points finaux
Les développeurs du noyau d'Antelope ont présenté leur vision d'un environnement 5.0 et ont demandé un retour d'information. Des comparaisons ont été faites avec les opérations existantes, un environnement 4.0 et la vision 5.0. Vous trouverez les notes de la table ronde du 12 avril sur GitHub d'EOS Nation et la vidéo sur YT d'EOS Nation.
Mises à jour
Sortie de la v4.0.0-r3
CDT-rc1 bientôt disponible (peut-être d'ici la semaine prochaine)
Heures de bureau pour les développeurs
Les nouvelles fonctionnalités de la v4.0.0-rc3 sont détaillées dans le lien fourni.
Les heures de bureau bihebdomadaires pour les développeurs apporteront un soutien supplémentaire aux personnes participant aux tables rondes. Stephen Diesel dirigera les réunions. La première aura lieu le 20 avril et tous les autres jeudis par la suite. N'hésitez pas à contacter Stephen sur Telegram pour en savoir plus sur la CDT et d'autres sujets liés aux développeurs (par exemple, DUNE, les points de douleur et les nouveaux pods Antler).
VUE D'ENSEMBLE
Étant donné qu'une mise à jour par consensus vers la 5.0 est prévue dans plusieurs mois (probablement au début de l'automne), la réunion a été moins structurée que d'habitude. Les principaux sujets d'intérêt sont les suivants
le désir d'un retour d'information rapide (et les rêves pour la version 5.0)
l'examen des propositions
plugin Prometheus
les catégories de points d'extrémité
SUJETS CLÉS
La version 4.0 introduira le plugin Prometheus. Au cours de sa brève période de test, les membres de la communauté ont demandé à ce que le plugin puisse être exécuté sur un port séparé et configurable. Il semble que ce soit l'objet principal de la version 5.0.
Prometheus sur un port séparé a inspiré d'autres configurations de port. Les catégories de points d'accès proposées sont les suivantes
get_info
chain_ro
chain_rw
net_ro
net_rw
producer_ro
producer_rw
snapshot
trace_api
Prometheus
node
Les catégories ne seront pas configurables pour chaque point de terminaison. Les points d'extrémité seront plutôt regroupés de manière logique. Il y aura également une uniformité entre les catégories. Par défaut, tous les points d'extrémité seront dans une seule catégorie afin que le système puisse fonctionner comme il l'a toujours fait.
Une proposition intitulée "custom port/io configurations" a été partagée.
Une autre priorité pour la version 5.0 est l'introduction de l'IPv6.
Réactions à la réunion
L'idée de catégories efficaces de points d'accès semble avoir été bien accueillie. Voici quelques commentaires et réponses initiales :
des commentaires sur une nouvelle configuration (catégorie) pour get_supported_apis
le processus de filtrage des connexions
discussion sur get_server_info et get_info qui est séparé pour le public et les opérateurs de nœuds.
Dans l'état actuel des choses, get_info est généralement rendu public. Cependant, il y a un besoin dans les environnements pairs (par exemple les nœuds producteurs) pour que get_info reste non-public.
Notez qu'il y a de fortes opinions sur le maintien de get_info sur tous les points de terminaison.
Clôture
La table ronde a commencé à se terminer en discutant d'une sorte de mode de rattrapage et d'un seuil configurable.
Brian a clôturé la réunion en demandant à la communauté quel serait l'environnement rêvé pour la version 5.0. Il a fourni des suggestions de domaines sur lesquels concentrer les propositions, mais a maintenu que le retour d'information devrait être virtuellement illimité :
points controversés
éléments particuliers
amélioration des performances
nouvelles capacités significatives
favoriser l'adoption
se frayer une place
PERSPECTIVES
Le réseau EOS est désormais connecté à Ethereum via EOS EVM. Les versions 4.0 (pas de mise à jour prévue du consensus) et 5.0 (mise à jour prévue du consensus) progressent avec confiance. Les deux versions améliorent la vitesse et les fonctionnalités. EOS est déjà très performant dans l'espace des blockchains. Il est maintenant temps de réaliser ses rêves.
Sources et références