La récente réunion des opérateurs de nœuds EOS (bientôt connu sous le nom de Vaulta) a rassemblé des développeurs pour discuter des mises à jour importantes concernant la résilience et l'automatisation du réseau. Un point clé était l'introduction d'un système d'auto-peering basé sur le gossip visant à améliorer la façon dont les producteurs de blocs se connectent les uns aux autres. De plus, ils ont abordé un bug critique de snapshot qui a été corrigé dans la dernière version du logiciel. Cette réunion fait partie des efforts continus pour améliorer la sécurité et l'efficacité de l'infrastructure de la blockchain EOS, avec l'espoir que les retours d'expérience guideront les améliorations futures.
Points Clés
-
Un bug de snapshot affectant plus que les snapshots programmés a été corrigé dans la version 1.1.4, donc les opérateurs devraient mettre à jour bientôt.
-
Le nouveau système d'auto-peering basé sur le gossip vise à simplifier les connexions entre les producteurs de blocs, réduisant ainsi la configuration manuelle.
-
Chaque clé de pair peut désormais prendre en charge jusqu'à quatre points de terminaison, facilitant la gestion des configurations multi-nœuds.
-
Bien que le protocole de gossip aide à la sensibilisation au réseau, il ne sécurise pas les connexions, laissant place à des attaques potentielles de spam.
-
Les options de peering manuel sont toujours disponibles, permettant aux opérateurs de garder le contrôle sur leurs connexions.
Intégrité des Snapshots et Conseils de Mise à Jour
Le Bug de Snapshot Affecte Plus Que les Snapshots Programmés
Donc, il y avait ce bug, n'est-ce pas ? Et il ne se contentait pas de perturber les snapshots programmés. Il s'avère qu'il affectait également les snapshots réalisés à l'aide de l'API /v1/producer/create_snapshot. En gros, certains blocs qui ne devraient pas être marqués comme finaux l'étaient. Cela pourrait causer de sérieux maux de tête si vous comptez sur ces snapshots pour, eh bien, quoi que ce soit d'important. Cela a affecté à la fois les snapshots programmés et ceux que vous déclenchez manuellement. Pas génial, Bob !
Correction Déployée dans la Version Antelope Spring 1.1.4
Bonne nouvelle, tout le monde ! L'équipe a corrigé le bug de snapshot dans la version 1.1.4 de la version Antelope Spring. Si vous êtes un opérateur de nœud qui réalise des snapshots, vous devriez mettre à jour vers 1.1.4 dès que c'est disponible. Voici un rapide récapitulatif de ce que vous devriez faire :
-
Vérifiez votre version actuelle d'Antelope.
-
Si vous utilisez une version antérieure à 1.1.4, planifiez une mise à jour.
-
Surveillez les notes de version pour 1.1.4 afin de vous assurer qu'il n'y a pas d'autres changements majeurs qui affectent votre configuration.
-
Testez la mise à jour dans un environnement non productif d'abord, si possible.
-
Mettez à jour vos nœuds de production. Mieux vaut prévenir que guérir !
Introduction du Peering Automatique Basé sur le Gossip
Donc, la grande nouvelle est ce nouveau système d'auto-peering basé sur le gossip pour les producteurs de blocs (BPs). En gros, il s'agit de rendre le réseau plus résilient, surtout lorsque les choses deviennent un peu folles, comme pendant des forks difficiles. L'idée est d'automatiser une grande partie des connexions entre pairs que les BPs doivent généralement gérer manuellement. Cela devrait rendre les choses plus fluides et plus fiables.
Automatisation de la Connectivité du Réseau BP
D'accord, donc l'objectif principal ici est de réduire la quantité de travail manuel nécessaire pour configurer les connexions entre pairs. Ce nouveau système est conçu pour gérer automatiquement la façon dont les BPs se connectent les uns aux autres. Pensez-y comme un moyen de garder le réseau en marche, même lorsqu'il y a des accrocs. Cela devrait certainement aider à rendre les choses plus stables, surtout lorsque le réseau est sous pression.
Exigence de Clé de Pair et de Signature
Pour que cela fonctionne, les BPs doivent enregistrer une clé spéciale dans un contrat intelligent. Cette clé est super importante car elle garantit que seuls les BPs de confiance communiquent entre eux. C'est comme une poignée de main secrète qui vérifie que chacun est bien qui il prétend être. Voici l'essentiel :
-
Les BPs enregistrent une clé unique.
-
Cette clé est utilisée pour signer les messages de gossip.
-
Seuls les messages authentifiés sont acceptés.
Sans cette clé, vous ne faites pas partie du club des cools, et votre nœud ne pourra pas participer au réseau de gossip.
Configuration de Peering et Limitations
Jusqu'à 4 Points de Terminaison par Clé de Pair Autorisés
Donc, avec ce nouveau système de peering basé sur le gossip, il y a quelques limites. Chaque clé de pair ne peut avoir que jusqu'à quatre nœuds différents connectés à elle. Je suppose que c'est pour éviter que les choses ne deviennent trop folles et compliquées, mais cela vous permet également d'avoir quelques nœuds fonctionnant en même temps. C'est un équilibre, je suppose.
Pare-feu et Découverte de Points de Terminaison via API
Ils essaient également de faciliter la gestion des pare-feu. Il y a un point de terminaison HTTP qui vous donne des informations de connexion pour les 21 principaux producteurs de blocs. L'idée est que vous pouvez l'utiliser pour mettre à jour automatiquement vos règles de pare-feu afin de n'autoriser que les connexions provenant de sources de confiance. Cela semble bon en théorie, mais je me demande à quel point cela fonctionnera en pratique. Je veux dire, les pare-feu peuvent être pénibles, et tout ce qui les automatise est le bienvenu, mais je suis aussi un peu méfiant à l'idée de céder trop de contrôle.
Option de Peering Manuel Reste Disponible
Ne vous inquiétez pas, vous pouvez toujours faire les choses à l'ancienne si vous le souhaitez. L'option de peering manuel est toujours là. Si vous voulez garder les choses telles qu'elles étaient, vous pouvez. De plus, ils ont fait en sorte que vous puissiez vous connecter à tous les 21 principaux BPs, pas seulement à ceux qui sont juste à côté de vous. Donc, vous avez des options :
-
Continuez à le faire manuellement.
-
Essayez le nouveau système automatisé.
-
Mélangez et assortissez, ce qui fonctionne le mieux pour vous.
Préoccupations de Sécurité et d'Implémentation Pratique
Le Gossip Authentifie, Mais Ne Sécurise Pas le Canal
D'accord, donc le nouveau protocole de gossip est tout au sujet de rendre les choses plus faciles, n'est-ce pas ? Il authentifie qui parle à qui, ce qui est cool. Mais voici le truc : il ne sécurise pas réellement la connexion elle-même. Pensez-y comme ceci : il vérifie votre identité à la porte, mais une fois à l'intérieur, tout est permis. Cela signifie que vos points de terminaison pourraient toujours être frappés par des attaques de spam ou même des attaques par inondation. Pas idéal, surtout si vous essayez de garder les choses en marche sans accroc.
Risques de Mauvaise Configuration et Limitations DNS
Configurer tout cela n'est pas exactement plug-and-play. Si vous vous trompez dans les détails du gossip, la qualité de votre connexion pourrait plonger. Et n'oublions pas les enregistrements DNS. Ils peuvent rendre la configuration des règles de pare-feu et des scripts d'automatisation un véritable casse-tête. C'est comme essayer de construire un ensemble Lego avec des instructions manquantes et quelques pièces aléatoires en trop. Vous pourriez y arriver finalement, mais cela va être frustrant.
La Surveillance Humaine Joue Toujours un Rôle
Je comprends tout le concept d'automatisation, mais certaines décisions sont mieux laissées aux humains. Il y a des préoccupations concernant le fait de laisser une machine gérer des choses qui étaient auparavant gérées par des opérateurs de confiance. Certaines personnes préfèrent encore vérifier manuellement les choses, surtout en ce qui concerne les points de terminaison privés. C'est comme avoir une voiture autonome – bien sûr, elle peut gérer la plupart de la conduite, mais vous voulez toujours garder les mains sur le volant, juste au cas où.
Itération et Retours Encouragés
Ce système est encore en évolution. Les développeurs comptent sur nous pour le tester et leur donner des retours. Ils veulent que nous utilisions le réseau Jungle pour vraiment le mettre à l'épreuve et les aider à corriger les défauts. C'est comme être un testeur bêta pour un nouveau jeu vidéo – vous pouvez y jouer tôt, mais vous devez aussi faire face aux bugs et aux glitches. Mais bon, au moins vous aidez à l'améliorer, non ?
Pensées Finales sur la Réunion des Opérateurs de Nœuds
En résumé, la récente réunion des opérateurs de nœuds EOS (bientôt Vaulta) a mis en lumière des avancées significatives dans l'infrastructure du réseau. L'introduction d'un système d'auto-peering basé sur le gossip vise à simplifier la façon dont les producteurs de blocs se connectent, ce qui pourrait conduire à un réseau plus résilient. Cependant, des défis demeurent, notamment en ce qui concerne l'implémentation et la sécurité de ce nouveau système. Le bug de snapshot corrigé dans la version 1.1.4 est un pas en avant, mais les opérateurs doivent rester prudents face aux risques potentiels, comme les attaques de spam. Alors que le déploiement commence dans le réseau de test Jungle, les retours des opérateurs seront cruciaux pour affiner ces développements. Dans l'ensemble, cette réunion reflète un engagement à améliorer la blockchain EOS, en équilibrant l'automatisation avec le besoin de surveillance manuelle.
Cet article a été créé avec le soutien d'une technologie alimentée par l'IA, en s'appuyant sur plusieurs sources réputées. Le contenu final a été soigneusement examiné et édité par l'équipe éditoriale de BlockzHub afin de garantir précision, clarté et cohérence. Les sources d'information originales sont créditées lorsque cela est approprié et requis. Les opinions exprimées dans cet article ne reflètent pas nécessairement les points de vue ou les positions officielles de BlockzHub. Cet article est uniquement destiné à des fins informatives et ne doit pas être considéré comme un conseil financier ou professionnel. Investir comporte des risques, et il est recommandé de consulter un conseiller financier qualifié avant de prendre toute décision d’investissement.