Cette semaine, les opérateurs de nœuds de Vaulta, anciennement connu sous le nom d'EOS, se sont réunis pour discuter d'importantes mises à jour. La réunion a abordé les progrès du logiciel Antelope Spring 2.0, le fonctionnement du nouveau système de gossip pour connecter les producteurs de blocs, et des idées pour sécuriser les connexions réseau. Les opérateurs de nœuds ont partagé leurs expériences concernant les problèmes techniques et la configuration de leurs réseaux, tout en assurant le bon fonctionnement de la blockchain Vaulta.
Points Clés à Retenir
-
La Developer Preview 1 d'Antelope Spring 2.0 est disponible, axée sur les appels synchrones, avec des changements plus importants attendus dans la Preview 2 vers septembre.
-
Le nouveau système d'événements exigera des opérateurs de nœuds qu'ils définissent des limites de stockage, avec plus de détails à venir à mesure que le développement progresse.
-
L'adoption du système de peering gossip est en cours, mais tous les principaux producteurs de blocs ne sont pas encore connectés, ce qui signifie que le réseau n'est pas entièrement maillé.
-
La mise en place du réseau gossip a été difficile, avec des problèmes pour trouver des pairs et des suggestions faites d'utiliser des listes hébergées pour aider les nouveaux nœuds à se connecter.
-
Une nouvelle idée est de permettre aux opérateurs de nœuds de créer des listes de pairs autorisés ou bloqués pour le système gossip afin d'aider à gérer les connexions et la sécurité.
Progrès du Développement d'Antelope Spring 2.0
Le développement d'Antelope Spring 2.0 progresse, avec la première Developer Preview (DP1) désormais disponible. Cette version initiale apporte le support des appels synchrones et donne accès à un environnement de testnet. Il est demandé aux développeurs de reconstruire leurs contrats en utilisant CDT 5.0 dev 1.1. Pour l'instant, la DP1 ne change pas grand-chose pour les opérateurs de nœuds, car les impacts majeurs sont attendus avec la DP2. Cette prochaine préversion, la DP2, est prévue pour début septembre et inclura le nouveau système d'événements ainsi que des améliorations de la vitesse d'exécution.
Aperçu et Implications du Système d'Événements
La prochaine Developer Preview 2 (DP2) d'Antelope Spring 2.0 devrait introduire un nouveau système d'événements. Ce système permettra la diffusion d'événements éphémères qui sont cryptographiquement engagés dans les données de consensus. Pour les opérateurs de nœuds, cela signifie qu'un nouveau paramètre de configuration sera introduit, leur demandant de définir des paramètres de stockage minimum pour ces événements. Les détails exacts et les meilleures pratiques pour la gestion de ces événements sont encore en cours d'élaboration à mesure que le développement progresse, mais la DP2 fournira les fonctionnalités et configurations initiales pertinentes pour les nœuds nécessaires à leur gestion. Les implications pour les opérateurs de nœuds sont importantes, car ils devront adapter leurs configurations pour s'adapter à ce nouveau flux de données.
Fonctionnalité du Système d'Événements
-
Les événements sont des messages temporaires.
-
Ils sont sécurisés par des engagements cryptographiques dans le consensus.
-
Les opérateurs de nœuds doivent définir des limites de stockage.
Exigences de Configuration pour les Opérateurs de Nœuds
-
Définir le stockage minimum pour les événements éphémères.
-
Surveiller le flux de données des événements.
-
S'adapter aux nouveaux paramètres de configuration dans la DP2.
Impact Anticipé du Système d'Événements
-
Nouveaux types de données à gérer.
-
Potentiel d'une surveillance réseau améliorée.
-
Nécessité de procédures opérationnelles mises à jour.
État d'Adoption du Peering Gossip des Producteurs de Blocs
Plusieurs des principaux Producteurs de Blocs (PB) ont pris des mesures pour enregistrer leurs clés de pair, ce qui est un bon début. Nous observons des connexions de peering partielles, comme entre Genereos et Eosphere, montrant que la connectivité de base est fonctionnelle pour certains. Cependant, cela ne se produit pas encore sur l'ensemble du réseau. L'adoption est toujours en cours, et une meilleure coordination et des confirmations claires de la part des PB aideraient vraiment à accélérer les choses. Nous n'avons pas atteint une masse critique d'adoption, ce qui pourrait expliquer pourquoi le réseau gossip n'est pas entièrement maillé comme prévu.
Défis Techniques dans la Formation du Réseau Gossip
Mettre en place un réseau gossip stable pour les Producteurs de Blocs (PB) n'est pas aussi simple qu'il n'y paraît. Nous rencontrons quelques obstacles. Pour commencer, trouver d'autres pairs peut être aléatoire. Cela est souvent dû au fait que certains PB n'ont peut-être pas leurs configurations entièrement réglées, ou que des pare-feu bloquent les connexions. Cela signifie que parfois, les nœuds ne peuvent tout simplement pas se voir alors qu'ils le devraient.
Actuellement, pour démarrer, les gens suggèrent d'ajouter manuellement des pairs pour amorcer les connexions. Cela fonctionne, mais ce n'est pas idéal pour un système décentralisé censé trouver son propre chemin. Il nous manque un moyen pour les nœuds de se découvrir automatiquement, comme un système de "pairs d'amorçage" qui aide les nouveaux nœuds à trouver les existants. Certaines idées qui circulent incluent l'utilisation de listes JSON de pairs hébergées pour faciliter cette configuration initiale.
Fonctionnalité Proposée de Liste Blanche/Noire pour les Connexions Gossip
Pour aider à gérer les connexions au sein du réseau gossip, une fonctionnalité permettant des listes blanches et noires de pairs est envisagée. Cela donnerait aux opérateurs de nœuds plus de contrôle sur les autres nœuds auxquels ils se connectent. L'idée est de permettre aux opérateurs de spécifier des comptes de Producteurs de Blocs (PB) particuliers qui sont autorisés ou non à se connecter.
Ce système proposé fonctionnerait en parallèle des configurations de pairs manuelles existantes. Tous les pairs que vous ajoutez manuellement à la configuration de votre nœud seraient toujours prioritaires. Cependant, pour les pairs découverts via le protocole gossip, les règles de liste blanche et noire s'appliqueraient alors.
L'objectif principal de cette fonctionnalité est de fournir un moyen d'empêcher les connexions avec des nœuds qui pourraient mal fonctionner ou être sous une forme d'attaque. C'est considéré comme un moyen de réduire la nécessité pour les opérateurs de gérer des règles de pare-feu externes complexes juste pour filtrer le trafic gossip entrant.
Voici une ventilation de son fonctionnement possible :
-
Liste Blanche : Une liste de comptes PB spécifiques qui sont explicitement autorisés à se connecter à votre nœud via gossip.
-
Liste Noire : Une liste de comptes PB spécifiques qui sont explicitement interdits de se connecter à votre nœud via gossip.
-
Comportement par Défaut : Si ni une liste blanche ni une liste noire n'est configurée, ou si un pair ne figure sur aucune des listes, le nœud suivrait probablement son comportement de connexion par défaut, permettant potentiellement la connexion.
Préoccupations Concernant l'Identification des Pairs et l'Atténuation des Abus
Défis d'Identification des Pairs
L'une des principales préoccupations avec le système gossip est de savoir qui envoie réellement quoi. Étant donné que les messages peuvent être transmis par différents nœuds, il est difficile de retrouver l'origine réelle du mauvais trafic. Cela rend difficile d'arrêter les problèmes à la source. Si vous bloquez un nœud qui cause des problèmes, cela pourrait simplement continuer à se propager via d'autres nœuds que vous n'avez pas encore identifiés. Cela ressemble un peu à un jeu de tape-taupe, et il n'y a pas de moyen facile de savoir avec certitude qui était l'expéditeur original.
Stratégies d'Atténuation des Abus
Pour y faire face, les gens demandent de meilleurs moyens de contrôler qui peut se connecter et quel type de trafic est autorisé. Cela signifie avoir plus qu'un simple blocage. Nous avons besoin de systèmes capables d'examiner l'identité des pairs et d'appliquer les règles plus attentivement. La configuration actuelle ne nous offre pas ce type de contrôle détaillé, ce qui est un obstacle majeur pour maintenir le réseau propre et sûr. Il est clair que le simple blocage de nœuds individuels ne suffit pas lorsque le réseau est conçu pour relayer l'information si librement.
Contraintes Réseau Affectant la Viabilité des Fonctionnalités
Lorsque nous examinons la mise en œuvre de nouvelles fonctionnalités, en particulier des éléments tels que la liste blanche et la liste noire proposées pour les connexions gossip, nous rencontrons des problèmes de réseau concrets. Ce n'est pas toujours aussi simple que d'appuyer sur un interrupteur. Par exemple, de nombreux nœuds utilisent des serveurs proxy pour se connecter. C'est assez courant, mais cela signifie que l'adresse IP originale d'une connexion est masquée. Cela rend difficile de savoir exactement d'où provient le trafic, ce qui est un gros problème si vous essayez de contrôler qui peut se connecter.
Ensuite, il y a la technologie sous-jacente elle-même. Le protocole TCP, utilisé par gossip, n'offre pas le même type de contrôle granulaire sur les connexions que, par exemple, HTTP. Cela signifie que nous ne pouvons pas facilement établir des règles pour autoriser ou bloquer des connexions spécifiques basées sur des informations détaillées. De plus, avec les adresses IP dynamiques et toutes ces différentes configurations de proxy, tenter d'appliquer une liste blanche ou noire stricte devient un véritable casse-tête. On a l'impression de toujours courir après le temps.
En raison de ces défis, de nombreux opérateurs de nœuds constatent que les contrôles traditionnels au niveau du pare-feu restent le moyen le plus pratique et efficace de gérer leur trafic réseau. Ils y sont habitués, et cela fonctionne de manière fiable, même si ce n'est pas aussi intégré qu'une fonctionnalité spécifique à gossip pourrait l'être. Nous devons nous demander si les fonctionnalités proposées peuvent réellement surmonter ces réalités réseau existantes ou si elles ne feront qu'ajouter de la complexité sans résoudre les problèmes fondamentaux.
Conclusion et Prochaines Étapes
Le développement d'Antelope Spring 2.0, en particulier la prochaine Developer Preview 2 (DP2) et son système d'événements intégré, représente un domaine important pour les tests et les retours des opérateurs de nœuds à venir. Les efforts continus pour encourager et surveiller l'adoption du protocole Gossip pour le peering des Producteurs de Blocs (PB) sont également importants. La fonctionnalité proposée de liste blanche et noire pour la gestion des connexions gossip a été reconnue comme un outil potentiellement utile, bien que ses limitations actuelles signifient qu'elle n'est pas une solution complète pour la sécurité du réseau. Des recherches supplémentaires et des contributions de la communauté seront recueillies pour évaluer la viabilité pratique et l'efficacité de la mise en œuvre de telles fonctionnalités.
Domaines Clés d'Attention pour les Opérateurs
-
DP2 et le Système d'Événements : Les opérateurs de nœuds doivent se préparer à tester ces composants dès qu'ils seront disponibles.
-
Adoption du Peering Gossip : La participation continue et la confirmation d'un peering réussi sont encouragées pour construire un réseau gossip plus robuste.
-
Retour sur les Fonctionnalités de Sécurité : Fournir des commentaires sur le mécanisme proposé de liste blanche/noire et d'autres préoccupations de sécurité aidera à façonner les développements futurs.
Considérations Futures
-
Robustesse du Réseau Gossip : Aborder les défis liés à la découverte des pairs et à la stabilité des connexions reste une priorité.
-
Identité et Abus : Le développement de méthodes plus efficaces pour identifier et atténuer les abus au sein du réseau gossip nécessite une enquête plus approfondie.
-
Réalités du Réseau : Les contraintes pratiques liées au masquage IP et à l'infrastructure réseau existante doivent être soigneusement prises en compte lors de la conception de nouvelles fonctionnalités.
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.