Auteur: Marco González
Editeur: Randall Roland
Traducteur: Vincent Davoine
Les opérateurs de noeuds, 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 :
“…améliorer le protocole Antelope (en particulier) pour les opérateurs de nœuds”.
Les réunions ont lieu tous les mercredis de 14h UTC à 15 UTCh (de 13h UTC à 14h UTC pendant l'heure d'été). Pour ceux qui souhaitent apprendre les bases du fonctionnement des nœuds EOS, l'EOS Network Foundation propose des tutoriels et de la documentation.
Les tables rondes du 19 et du 26 avril ont porté sur le développement de Leap. Le 19 avril, les participants ont envisagé ce que pourrait donner la version 5.0 de Leap. Le 26 avril, la version 4.0.0 était en ligne. La dernière table ronde d'avril a permis de recueillir des commentaires et d'explorer une nouvelle proposition.
19 avril : Espoirs et rêves pour Leap 5.0 et la suite
Le ton était une sorte de paysage de rêve explorant le potentiel futur du réseau EOS. Les notes de la réunion du 16 avril sont disponibles sur le GitHub de EOS Nation. Visionnez l'enregistrement de la table ronde sur le site YouTube de l'ENF.
APERÇU
La version 5 d'Antelope sera disponible dans plusieurs mois. C'est maintenant que le développement prend forme. Les commentaires de la communauté sont encouragés. Consultez les commentaires des participants et partagez les vôtres. Mais d'abord, quelques mises à jour :
Leap v4.0.0 est imminent
Outil Antler
Démonstration CDT attendue dans une semaine ou deux
Dirigée par l'équipe Antelope, la table ronde du 19 avril a exploré les espoirs, les aspirations et les rêves pour la version 5.0 et au-delà.
Le résumé suivant est une adaptation des notes présentées par Brian Hazzard. La version 5.0 d'Antelope Leap devrait être disponible à l'automne 2023. Surveillez les mises à jour et éventuellement une sortie dès le mois de septembre.
La version 5.0 du mainnet EOS représente l'avenir et la vision de la communauté. Les participants ont été invités à exprimer leur liste de souhaits (pensées et rêves). Parmi les sous-thèmes de discussion, on peut citer
des intérêts pour aujourd'hui
des changements mineurs, mais ayant un impact, qui sont relativement faciles à réaliser
des actions pragmatiques, utiles, amusantes et qui soulagent la douleur en général
les facteurs remarquables, controversés et étonnants
les projets ambitieux et les aspirations brillantes, tant pour les opérateurs que pour les utilisateurs
Les sous-thèmes ci-dessus ont permis de lancer les souhaits de développement de la version 5.0 (et au-delà). Vous trouverez ci-dessous de brefs résumés de chacun des neuf participants :
Ross : découverte dynamique des pairs, automatisation des meilleurs pairs et possibilité de voir facilement le dernier bloc.
Daniel : compatibilité avec les chaînes multiples, blocs de construction ETH utiles et intégration de The Graph.
Micheal : un point de terminaison d'administration plus détaillé ("GetInfo2") et une requête de santé indiquant un nœud sûr/synchronisé ("Is Ready").
Marco (MachnBird Sparo) : traitement des paiements et matériel facile/accessible
Aaron : permissions avec des autorisations temporaires et des règles spécifiques qui correspondent aux soumissions
Kevin : parallélisation de la validation des blocs, 100K TPS, et mise à l'échelle horizontale
Denis : amélioration des ressources natives par le biais de la consolidation et de la rentabilité
Tony : intégration de Loki pour la journalisation et une solution de surveillance native
J.P. : amélioration de la gestion des pairs via une API opérationnelle et possibilité de se tenir au courant des nouvelles fonctionnalités et des corrections.
Mathew : intégration de WAX RNG, IPv6 partout, démarrage automatique de nodeos, et format de snapshots compressés
PERSPECTIVES
Le retour d'information de la communauté est au cœur du développement actuel. On pourrait en déduire qu'un retour d'information dès le début du développement de la version 5.0 serait le plus utile.
26 avril : nodeos 5.0, Proposition pour API/Sérialisation
Leap v4.0.0 étant désormais en ligne, l'accent est mis sur la mise en place d'un ou de plusieurs cours pour le développement de la version 5.0 dans les mois à venir. Les notes de la réunion du 26 avril sont sur le GitHub d'EOS Nation. La proposition, (mise à jour) API/serialization time constraints for nodeos 5.0, se trouve sur un lien ENF hackmd.io. Un enregistrement sera disponible sur le site YouTube de l'ENF.
APERÇU
Une fois de plus, l'accent a été mis sur le retour d'information de la communauté. En fait, la discussion a plutôt pris la forme de questions-réponses. Les mises à jour comprennent :
La version 4.0.0 a été publiée cette semaine et certains opérateurs de nœuds l'ont déjà adoptée.
CDT v4rc1 probable la semaine prochaine
Voici un bref aperçu de la proposition. Les deux principaux éléments à retenir pour les changements à venir dans la version 5.0 sont les suivants :
limite de sérialisation ABI
contraintes non atomiques des éléments de l'API
La plupart des demandes ABI (Application Binary Interface) ont vu la désérialisation déplacée vers le pool de threads HTTP. Il en résulte une meilleure réactivité de nodeos sur le thread principal.
En conséquence, il existe des contraintes sur le nombre d'éléments renvoyés pour les API non atomiques. Plus précisément, les demandes pour http_max_response_time doivent spécifier une plage et un temps maximum. Notez que les demandes valides renvoient toujours au moins un objet, avec un maximum par défaut de 1 000 éléments.
Les exigences en matière d'orientation sont résumées ci-dessous :
les nœuds de l'API doivent répondre avec succès à toute demande atomique
les appels d'API non atomiques doivent spécifier une durée maximale de demande
devoir de se prémunir contre les "abi-bombs" fournies par l'utilisateur
Discussion
La discussion a été plus libre que d'habitude. Les sujets énumérés ont été sélectionnés en fonction de ce qui ressortait et inspirait le plus de conversations.
Pourquoi get_block a changé
La rapidité, l'efficacité et le fait d'éviter de geler le fil d'exécution principal semblaient inciter à déplacer get_block sur le fil d'exécution HTTP.
Suivi du temps
Prometheus est recommandé par rapport à une solution d'historique. Prometheus devrait également apporter une aide précieuse en matière de surveillance. La liste des souhaits comprend une solution légère et largement disponible.
Cas d'utilisation pour les développeurs
La possibilité pour les développeurs d'utiliser un plugin a été brièvement discutée. Il a également été question de l'avancement du plugin, de la mention du trace_api_plugin et de la méfiance de certains développeurs (notamment dans le domaine de la finance) à l'égard des solutions de niveau 2.
Autres sujets
Parmi les autres sujets ayant fait l'objet de discussions approfondies, on peut citer
raisons de l'échec (ou du gel)
temps de réponse maximum
plus d'informations sur une solution historique
snapshots
PERSPECTIVES
Leap 5.0 donnera certainement lieu à des discussions animées et à de nouvelles propositions. La réussite de cette proposition axée sur les performances devrait contribuer à faciliter la mise en œuvre de la version 5.0. Les participants semblent partager les mêmes sentiments, en privilégiant la qualité plutôt que l'adoption rapide d'une solution.