Auteur: Marco González

Editeur: Randall Roland

Traducteur: Vincent Davoine

Les opérateurs de nœuds, 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 :

Les réunions ont lieu tous les mercredis de 14h UTC à 15h UTC (13h UTC à 14h UTC pendant l'heure d'été). L'EOS Network Foundation 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.

L'intérêt pour l'exploration des développements en cours et l'évaluation du retour d'information s'est poursuivi tout au long de la première moitié du mois.

Les notes de réunion sont disponibles sur GitHub et les vidéos enregistrées sur la chaîne YT de l'ENF.

La réunion du 3 mai pourrait aider les développeurs actifs qui souhaitent se mettre à jour. Bien que la liste fournie soit un travail en cours, les initiatives ont été détaillées en fonction de leur valeur perçue aujourd'hui et de leur rôle dans le lancement d'Antelope 5.0.

Avant de passer à l'action autour de la version 5.0, voici quelques mises à jour :

Après les brefs commentaires sur les mises à jour, les participants ont choisi des thèmes. Une première option était de revenir à la taxonomie des types de nœuds. Une autre option était d'examiner et de commenter les agendas actifs pour Leap 5.0.

La discussion s'articulera finalement autour de deux thèmes :

Les initiatives de subvention ENF pour Leap v5.0.0 discutées le 3 mai sont les suivantes :

Parmi les éléments énumérés ci-dessus, deux (FI et améliorations de la découverte des nœuds pairs) sont reconnus comme des projets de demande de propositions (PDP).

Le PDP FI pourrait s'avérer être l'initiative la plus importante de la version 5.0. Atteindre la finalité plus rapidement (au lieu des quelques secondes nécessaires actuellement) a un impact sur la façon dont les développeurs envisagent leurs dApps. La FI signifie un relais plus rapide entre les transactions et un état du réseau affecté de manière fiable. Imaginez ce que les développeurs peuvent faire lorsque davantage d'actions achevées sont assurées. La FI augmente la complexité du développement des dApps. Les utilisateurs (et le réseau dans son ensemble) bénéficient de dApps plus robustes et plus créatives.

Le retour d'information sur la FI semble toujours positif. Il a été question de cas d'utilisation et de la manière dont les développeurs pourraient modifier leur façon de construire. Dans sa forme la plus basique, une finalité plus rapide rationalise les transactions dont on sait qu'elles sont nécessaires. Pour en savoir plus sur la FI, lisez le rapport de la Coalition - Finalité plus rapide avec l'IBC, les SDK + le nouvel appel d'offres pour l'amélioration du P2P.

La question des limites de la RAM n'est peut-être pas aussi essentielle, mais elle est bien comprise par la communauté des développeurs. La brève discussion a donné un aperçu des plans généraux et a promis de faire un rapport sur les préoccupations des opérations plus importantes.

Les interactions contractuelles ciblent les préoccupations des développeurs en matière d'échelonnement. Le maintien d'une (de) solution(s) flexible(s) s'est distingué parmi les brefs commentaires.

La diffusion immédiate semble être un sujet d'actualité. Il s'agit d'introduire des avantages opérationnels qui "commencent tôt", avant le bloc suivant. Cela évite de rencontrer une transaction en attente avec un bloc suivant partiellement rempli. L'un des problèmes potentiels est que le diagnostic de la latence des BP pourrait devenir plus difficile. Les solutions à la latence des BP pourraient consister à envelopper le bloc, à surveiller entre les nœuds, à créer un bloc enveloppe et à ajouter des informations d'en-tête supplémentaires.

La découverte des nœuds pairs est une autre demande de propositions. Au-delà de la mention des adresses IP privées, des limites/surcharge et d'un éventuel masque de sous-réseau, le sujet n'a pas été beaucoup discuté. Un participant a mentionné que la communauté Ethereum possède une expérience substantielle dans ce domaine. Un point d'action a été créé qui pourrait être réexaminé lors d'une prochaine table ronde.

Prometheus a été mentionné en même temps que l'IP généralisé (configuration des ports pour les points d'extrémité HTTP de nodeos). L'idée est d'éviter la redondance, la dette technologique et la fonctionnalité.

Pour l'instant, les constructions reproductibles (Reproducible Pinned Builds) nécessitent une étape manuelle. L'objectif est d'accroître l'automatisation au fur et à mesure que la communauté des développeurs se développe. Des informations supplémentaires ont été demandées. Les snapshots ont été mentionnés ici. Les snapshots devraient devenir plus raisonnables avec les nouvelles versions de correctifs et être prioritaires par rapport aux redémarrages. Notez que les versions majeures peuvent nécessiter plus qu'un snapshot.

Les autres sujets figurant sur la liste des initiatives de subvention ENF pour Leap v5.0.0 au moment de la rédaction de ce document étaient les suivants :

La liste des initiatives Leap v5.0.0 est un travail en cours. Elle sera probablement modifiée à de nombreuses reprises avant l'échéance de Leap 5.0 fixée à septembre/octobre 2023. L'idée primordiale est qu'AntelopeIO se distingue dans l'espace blockchain par ses performances et sa fiabilité. Le développement doit soutenir ces concepts. En outre, il est essentiel de faciliter les processus pour les développeurs et de favoriser l'adoption par les utilisateurs.

Notez que la liste n'inclut pas les corrections de bugs.

Leap v4.0.0 semble généralement remplir la fonction pour laquelle il a été conçu. Les signatures de comptes flexibles présentent un intérêt particulier. Cette nouvelle fonctionnalité est considérée comme un ajout substantiel.

Les points les plus délicats concernent les multisigs et les déais. Il semble prudent de faciliter les multisigs pour la GameFi. Les fonctions de temporisation ont été réexaminées avec l'idée d'une autorité temporaire étendue (permissions).

L'amélioration de la documentation a refait surface. Un premier défi est d'équilibrer les correctifs et les mises à jour avec la documentation de développement de base. Des améliorations sont attendues à l'approche de la sortie de la version 5.0 à l'automne.

Antelope sur EOS (Leap) 4.0 est un aperçu passionnant de ce qui nous attend. Certains développeurs reconnaissent déjà les avantages et choisissent de faire la mise à jour non obligatoire. L'équipe ENF continue de montrer son talent en laissant circuler l'information sur le développement. Une nouvelle culture EOS a émergé, celle de la créativité et du travail pour la prospérité.

L'EVM EOS a été le sujet de discussion de la table ronde du 10 mai.

Les mises à jour à surveiller sont les suivantes :

La discussion a commencé par une demande de contribution de la part de ceux qui ont géré un EVM public. Le reste de la discussion a permis de mieux comprendre l'environnement actuel du fonctionnement des nœuds d'EVM publics.

Les mesures d'incitation ont été l'un des premiers sujets abordés. L'interaction avec la communauté et la garantie de la valeur et de la croissance ont suivi.

Les "bons contrôles de santé (opérationnels)" sont une solution en cours d'élaboration. La plupart des participants semblent favorables à l'idée de se concentrer sur les performances et la fiabilité connues d'Antelope plutôt que sur l'équilibre de la charge.

Les questions relatives aux portefeuilles ont été abordées pour MetaMask et Anchor. Des annonces faciles pour MetaMask semblent être la prochaine étape logique. Cela demandera probablement plus d'efforts, mais se concentrer sur Anchor pour améliorer l'environnement EVM semble judicieux.

Alors que EOS entre dans l'environnement EVM, il est important de se rappeler que EOS apporte plus que les autres technologies EVM. Alors que l'EVM EOS cherche à égaler la capacité opérationnelle des dApps EVM existantes, le développement doit être prudent pour éviter les écueils. Il a été suggéré d'améliorer la façon dont des objectifs similaires sont atteints de manière unique par EOS. Plus précisément, commencer par l'enveloppement des ressources (CPU/NET) payées par les "mineurs". En outre, il faut chercher à augmenter le nombre de mineurs pour faciliter la distribution des frais.

Parmi les autres points qui ont retenu l'attention du groupe, on peut citer :

Il est à noter qu'une vision commune de la communauté a commencé à aborder des idées qui se prêtent à la centralisation ou à la décentralisation. Le public cible d'EOS pourrait également être inclus dans cette discussion.

Dans l'ensemble, la table ronde du 10 mai a été l'occasion d'une discussion énergique qui a porté sur des questions à la fois générales et spécifiques. L'EVM EOS est peut-être en ligne, mais il n'a pas encore montré sa véritable forme. Le développement se poursuit avec le lancement de nouvelles dApps. Le développement sur l'EVM EOS aujourd'hui nécessite un véritable talent, de la prévoyance et de l'adaptabilité. Pourtant, c'est maintenant que les graines les plus fructueuses sont plantées.