Shardeum Innovations , Shardeum News / Par Chris Raddings / 16 février 2024

Table des matières

1. Le décollage de Shardeum : une réussite révolutionnaire

2. Premier réseau partagé permettant d’auto-restaurer et de préserver les données

3. Comprendre le crash

3.1 Nœuds d’archiveur : stockage interstellaire

3.2 Détection d’archiveur perdu : la technologie extraterrestre dévoilée

3.3 Modes réseau sur Shardeum : aucune NASA n’est nécessaire

3.4 Mode de récupération par ingénierie inverse : Rosewell revisité

3.5 La cause première du crash : Event Horizon

4. Chroniques de la reprise : du choc systémique au renouveau stellaire

5. En route vers la restauration

5.1 Récupération agile

5.2 Réponse multiforme de l’équipe technologique Shardeum

6. Atterrissage sûr et innovation spatiale

Le décollage de Shardeum : une réussite révolutionnaire

Image générée par l’IA

Le lundi 27 janvier 2024 s’est déroulé un événement révolutionnaire dans le monde du Web 3 qui peut en effet être assimilé à l’exploit historique d’un vaisseau spatial revenant parfaitement à sa rampe de lancement après sa première mission de vol d’essai. Dans ce scénario extraordinaire, Shardeum a non seulement été confronté à un défi formidable, mais a également triomphé, la résilience de son réseau marquant la première fois qu’un réseau fragmenté s’auto-restaure dans le domaine de la technologie des registres distribués.

Tout comme le voyage d’un vaisseau spatial implique une planification méticuleuse, une ingénierie de précision et l’exécution fluide de manœuvres complexes, la restauration par Shardeum de son Sphinx betanet , qui avait connu un crash critique, a nécessité un niveau équivalent de maîtrise technologique et d’innovation. La capacité de préserver toutes les données d’un réseau, en particulier celui qui fonctionne à l’aide du partage d’état dynamique, est tout simplement révolutionnaire.

Alors que nous nous lançons dans cette exploration, nous célébrons non seulement l’atterrissage capital de Shardeum, mais le reconnaissons également comme un moment charnière dans l’évolution de la technologie Web 3 — un saut qui pourrait redéfinir les limites de la résilience des réseaux informatiques et de l’intégrité des données.

Premier réseau partagé permettant d’auto-restaurer et de préserver les données

Le maintien et la restauration d’un réseau fragmenté dynamiquement, tel que Shardeum, englobent un éventail de défis techniques complexes qui le distinguent des réseaux blockchain traditionnels tels que Bitcoin ou Ethereum. Dans un environnement fragmenté dynamiquement avec mise à l’échelle automatique, la réallocation et l’équilibrage continus des nœuds et des ressources entre différentes partitions sont cruciaux pour optimiser les performances et l’évolutivité. Ce flux constant dans l’architecture réseau ajoute une complexité significative au maintien de la cohérence des données, à la stabilité du réseau et à la facilitation d’une reprise efficace en cas de panne.

La criticité de ces défis est accentuée lorsque l’on compare la réponse de Shardeum aux fluctuations des nœuds avec celle de Bitcoin. Le réseau Bitcoin conserve ses fonctionnalités même avec un nombre minimal de nœuds, car chaque nœud complet possède l’historique complet de l’état et des transactions. À l’inverse, chaque nœud actif sur Shardeum ne possède pas l’historique complet de l’état et des transactions, car le réseau Shardeum est fragmenté, et chaque validateur ne détient qu’un sous-ensemble de l’état entier. La conséquence de ce partitionnement est que tous les nœuds de validation sont extrêmement légers. Cela crée donc une multitude d’opportunités et de défis en matière d’ingénierie. Si un nœud tombe en panne, comment pouvons-nous garantir que toutes les données sont préservées ? Shardeum a deux voies principales.

Premièrement, Shardeum utilise le partitionnement d’état dynamique , dans lequel l’espace d’adressage global est partitionné (ou divisé) en fonction du nombre de nœuds actifs. Chaque nœud est responsable des partitions qui lui sont attribuées, ainsi que d’un certain rayon (R) autour de lui et de partitions supplémentaires (E) adjacentes, garantissant une adaptabilité dynamique et une redondance robuste des données dans le cadre du réseau. Ainsi, même si un nœud tombe en panne, le réseau reste continu et aucune perte de données.

Deuxièmement, Shardeum utilise des nœuds d’archivage pour stocker l’état complet de l’ensemble du réseau. Ceci est réalisé par les nœuds actifs diffusant leurs états partiellement stockés vers les archiveurs pour la collecte. En raison de ces deux facteurs et des optimisations de conception, la restauration d’un tel réseau doit être conçue d’une manière nouvelle afin de continuer à faciliter des fonctionnalités avantageuses telles que la mise à l’échelle automatique et la mise à l’échelle linéaire .

Comprendre le crash

Maintenant que nous comprenons les bases du partitionnement d’état dynamique et que les nœuds d’archivage sont impliqués d’une manière ou d’une autre, commençons par démêler plus en profondeur certains composants supplémentaires et les expliquer. Afin de comprendre le crash et la restauration du Shardeum betanet, nous devons d’abord comprendre un peu les éléments suivants :

• Nœuds archiveurs

• Détection de l’archiveur perdu

• Modes réseau

• Mode de récupération

Comprendre les bases de chacun d’entre eux est nécessaire avant de plonger tête première dans les bugs, alors jetons-y un coup d’œil !

Nœuds d’archiveur : stockage interstellaire

Dans Shardeum, les nœuds archiveurs, également appelés archiveurs, constituent une catégorie critique de nœuds, chargés de préserver l’état complet et les enregistrements historiques du réseau. À la différence des nœuds actifs, les archiveurs ne participent pas aux processus de consensus ; leur fonction première est d’archiver de manière exhaustive l’intégralité des données du réseau, y compris les transactions et les reçus. La contribution des nœuds archiveurs est essentielle pour maintenir l’intégrité du réseau et assurer son fonctionnement transparent, affirmant ainsi le statut de Shardeum en tant que réseau robuste, complet et fiable. Les archiveurs faisant partie intégrante de son réseau, Shardeum doit disposer d’un protocole pour détecter tout archiveur (et validateur) qui ne répond pas.

Détection d’archiveur perdu : la technologie extraterrestre dévoilée

Shardeum dispose d’un protocole appelé protocole de détection de nœud perdu qui détecte lorsque les nœuds actifs deviennent non opérationnels — ceci est réservé uniquement aux nœuds actifs. Cependant, Shardeum dispose également d’un protocole pour les archiveurs qui fait une chose similaire appelée détection d’archiveur perdu. La détection des archiveurs perdus est un protocole spécialisé conçu pour gérer des scénarios rares dans lesquels un ou plusieurs archiveurs deviennent non opérationnels et marqués comme perdus. Étant donné que les nœuds d’archivage jouent un rôle essentiel dans le maintien de l’intégrité et de l’accessibilité des données historiques au sein du réseau, il est donc essentiel que, dans les rares cas où ils ne répondent pas ou ne fonctionnent pas, ces événements critiques soient détectés afin d’atténuer tout effet en aval. Bien que la perte des archiveurs n’ait pas provoqué ce crash particulier, l’interaction entre le protocole de détection de la perte de l’archiveur et un mode réseau spécifique l’a provoqué. Examinons maintenant quels sont les modes réseau sur Shardeum.

Modes réseau sur Shardeum : aucune NASA n’est nécessaire

Une innovation phare sur Shardeum, alimentée par le protocole Shardus sous-jacent, est le cadre des modes réseau. Ces modes transcendent les états opérationnels de base, incarnant une coordination complexe de diverses activités de nœuds, de méthodes de synchronisation de données et de systèmes de gestion de transactions. De telles configurations réseau jouent un rôle crucial dans la préservation de l’intégrité opérationnelle du réseau, en particulier dans les scénarios caractérisés par la perte de nœuds et de données, car Shardeum est un réseau fragmenté.

À un niveau plus simple, la meilleure façon de concevoir les modes de réseau sur Shardeum consiste à créer des plans d’urgence codés en dur qui permettent la continuité des opérations pour l’ensemble du réseau, même dans des conditions improbables telles qu’une panne ou une dégradation à l’échelle du réseau. Cette résilience et cette robustesse opérationnelles préprogrammées garantissent que Shardeum survivra toujours, quelle que soit l’adversité à laquelle le réseau est confronté.

Bien que comprendre le bug ne nécessite pas de digérer toutes les facettes du cadre des modes réseau, il est utile de se familiariser avec les bases. Au cœur du cadre des modes réseau se trouve l’incorporation de plusieurs phases de réseau distinctes : formation, traitement, sécurité, récupération, redémarrage, restauration et arrêt. Ces modes sont soigneusement conçus pour répondre à diverses situations et urgences réseau. Cependant, le mode qui nous concerne dans cet article est le mode recovery.

Mode de récupération par ingénierie inverse : Rosewell revisité

Le mode de récupération est l’un des 7 modes réseau susmentionnés. Le mode de récupération est lancé lorsque le nombre de nœuds actifs du réseau descend en dessous d’un seuil critique prédéfini (actuellement configuré à 75 % ou moins). Ce seuil est réglable selon les exigences du réseau. Dans ce mode, le réseau arrête temporairement le traitement des transactions d’application et la synchronisation des données d’application. Cette stratégie est conçue pour faciliter l’expansion du réseau en cyclant de manière transparente les nœuds en veille dans le cadre de la rotation des nœuds, rétablissant ainsi le nombre de nœuds actifs à un niveau optimal, idéalement supérieur à 100 %.

Pendant le mode de récupération, l’architecture réseau de Shardeum permet une augmentation incrémentielle du nombre de nœuds, plafonnée à 20 % de croissance par cycle ( chaque cycle dure environ 60 secondes ). Ce taux de croissance contrôlé est essentiel pour maintenir la stabilité du réseau et garantir une intégration transparente des nouveaux nœuds. Une augmentation rapide du nombre de nœuds, telle qu’une augmentation de 50 %, pourrait potentiellement déstabiliser le réseau et compliquer le processus d’intégration.

Chaque nœud nouvellement ajouté nécessite des ressources réseau pour la synchronisation et l’intégration. En limitant l’augmentation à 20 % par cycle, le réseau garantit que son infrastructure peut prendre en charge de manière adéquate l’ajout de nouveaux nœuds sans contrainte. Cette approche préserve non seulement la stabilité du réseau, mais minimise également le risque d’incohérences ou d’erreurs de données pendant le processus de synchronisation, maintenant ainsi l’intégrité des données de la chaîne de cycles.

La cause première du crash : Event Horizon

Il est important de noter qu’il y avait deux bugs distincts. Le bug de la bibliothèque Neon — qui provoquait le crash des validateurs apparemment au hasard et un bug dans le protocole de détection de la perte de l’archiveur — qui n’acceptait pas une liste de validateurs vide. Bien que ce soit le bug du protocole de détection de l’archiveur perdu qui ait provoqué le crash de la version Betanet actuelle, j’aimerais d’abord vous présenter le bug de la bibliothèque Neon.

Dans la version Sphinx 1.9.1, nous avons intégré une mise à jour d’une bibliothèque qui utilise les liaisons Neon pour relier les fonctionnalités Rust et TypeScript, car Shardeum est principalement construit en TypeScript. Neon est reconnu pour son approche innovante, quoique expérimentale, repoussant souvent les limites des pratiques conventionnelles de développement de logiciels. Cette intégration visait à améliorer l’interopérabilité entre ces deux langages, permettant une communication plus efficace et directe au sein de notre architecture logicielle. Cependant, cela a provoqué un bug qui a provoqué la suppression aléatoire des nœuds du réseau.

Deuxièmement, lors du récent incident qui a conduit au crash du betanet à Shardeum, la cause première a été identifiée comme une anomalie critique provenant de l’interaction entre les deux sous-systèmes distincts susmentionnés : le mécanisme de détection de la perte de l’archiveur et le protocole de mode de récupération du réseau .Ce bref crash a été précipité par l’activation simultanée de ces deux mécanismes, un scénario jamais rencontré ni testé auparavant. Le processus d’archivage perdu a été déclenché parallèlement au mod de récupération du réseau et en raison d’un bug dans le mode archiveur perdu n’acceptant pas la liste de nœuds actifs vide. Cela a abouti au crash du réseau.

Chroniques de la reprise : du choc systémique au renouveau stellaire

Alors, que s’est-il réellement passé d’autre et quand ? La chronologie des événements entourant le crash du réseau et sa résolution est la suivante :

1. Vulnérabilité initiale et mise à niveau : le réseau a rencontré une vulnérabilité signalée par le processus de linting 1.9.1 au sein d’une bibliothèque npm (neon). Une mise à niveau a été mise en œuvre pour résoudre ce problème. Cependant, cette mise à niveau a introduit par inadvertance une exception qui n’a pas été reproduite lors des tests locaux.

2. Exception intermittente de la bibliothèque entraînant des arrêts des validateurs : la bibliothèque, neon, a connu des exceptions sporadiques qui ont provoqué des arrêts périodiques des validateurs de réseau. Alors que la conception du réseau permettait une certaine résilience en remplaçant ces validateurs, le timing des échecs simultanés de plusieurs validateurs a malheureusement déclenché le mode de récupération du réseau.

3. Déclenchement du mode de récupération réseau : une fois en mode de récupération réseau, le protocole nécessitait d’effacer et de régénérer la liste des nœuds actifs. Un bug simultané dans le système d’archivage perdu, qui ne prenait pas en charge une liste de validateurs vide, était la principale cause du crash du réseau.

4. Résolution et restauration du réseau : le crash a été corrigé et le réseau a été restauré avec succès à l’aide des données stockées sur les archiveurs. C’est la première fois dans l’histoire qu’un réseau fragmenté de couche 1 en panne est restauré avec succès et que toutes les données du réseau sont préservées intactes. Cela n’a jamais été réalisé sur aucun réseau, encore moins sur un réseau avec partitionnement d’état dynamique. Cette réussite marque un « atterrissage de fusée » réussi en termes de reprise du réseau.

5. Correctifs terminés : un correctif préliminaire a été implémenté pour résoudre le problème de la bibliothèque, mais dans un effort continu pour améliorer la stabilité du réseau, la version 1.9.5 a été déployée. Cette mise à jour a introduit une correction de bug singulière mais cruciale traitant d’un autre cas de crash de liaison au néon, identifiant et rectifiant une vulnérabilité spécifique sans imposer une mise à niveau à l’échelle du réseau. Initialement, les utilisateurs utilisant la version 1.9.4 avaient la possibilité de conserver leur version actuelle ou d’opter pour la mise à niveau vers la version 1.9.5, en fonction de leur évaluation des performances du réseau et de leurs préférences en matière de stabilité. Cependant, il a finalement été décidé qu’afin d’améliorer la stabilité du réseau et de résoudre les problèmes persistants liés aux liaisons néon, la version minimale requise pour les validateurs devrait être augmentée à 1.9.5. Cette mise à jour visait à exclure systématiquement les validateurs fonctionnant sur la version 1.9.4, qui ont été identifiés comme susceptibles de planter en raison de la complication des liaisons néon susmentionnée. Ceci est nécessaire pour s’assurer que le bug du néon est entièrement annulé et complètement corrigé.

Maintenant que nous connaissons la chronologie et comment les événements majeurs se sont déroulés, jetons un coup d’œil à ce qui s’est passé pour que le réseau se rétablisse si rapidement.

En route vers la restauration

Récupération agile

La restauration du réseau comprenait de nombreux éléments, mais l’un des éléments clés était le mode de récupération de Shardeum. Comme indiqué précédemment, le mode de récupération est lancé lorsque le nombre de nœuds actifs du réseau descend en dessous d’un seuil critique prédéfini et permet une croissance rapide, contrôlée et efficace du réseau de manière sécurisée pour restaurer le réseau. Il est important de souligner que sans l’ingéniosité technologique des concepteurs et développeurs des modes réseau, Shardeum n’aurait pas pu se remettre aussi facilement du crash et démontrer ses prouesses innovantes.

De plus, des efforts importants ont été déployés par l’équipe technique de Shardeum lorsqu’elle s’est lancée dans une action immédiate. La première étape impliquait une analyse approfondie pour identifier la cause première du crash, qui était attribuée à une anomalie dans l’interaction entre la détection de perte de l’archiveur du réseau et ses systèmes de mode de récupération. Comprenant la complexité du problème, l’équipe a rapidement mis en œuvre une approche multidimensionnelle pour répondre à la fois aux conséquences immédiates et aux vulnérabilités sous-jacentes.

Réponse multiforme de l’équipe technologique Shardeum

Techniquement, la réponse a été multiforme : premièrement, l’équipe a isolé les composants concernés pour éviter une nouvelle dégradation du réseau. Parallèlement, ils ont déployé un correctif pour corriger le bug du système d’archivage perdu, garantissant qu’il pouvait gérer une liste de validateurs vide — un oubli critique qui avait précipité la panne du réseau. Pour restaurer le réseau à sa pleine capacité opérationnelle, les données conservées sur les archiveurs ont ensuite été activées et utilisées pour reconstruire l’état du réseau avant le crash, garantissant ainsi l’absence de perte de données au cours du processus.

Sur le plan logistique, l’équipe s’est coordonnée sur différents fuseaux horaires et disciplines, en tirant parti d’outils basés sur le cloud pour une collaboration et une surveillance en temps réel. Cet effort coordonné a non seulement facilité le développement et le déploiement rapides de correctifs, mais a également permis de garantir que tous les membres de l’équipe étaient alignés sur le processus de récupération et les prochaines étapes.

Cet incident a servi de test rigoureux des protocoles de gestion des accidents de Shardeum et a souligné l’importance de réponses agiles et innovantes aux défis imprévus. Cela souligne l’engagement de l’équipe à maintenir un réseau résilient et sécurisé, prêt à relever les obstacles techniques complexes à mesure qu’ils surviennent.

Atterrissage sûr et innovation spatiale

En conclusion, la restauration réussie du réseau fragmenté de Shardeum annonce un changement important dans la technologie des réseaux, marquant une étape importante aux implications considérables pour l’industrie. Bien qu’elles soient largement méconnues à l’heure actuelle, les innovations telles que les modes réseau finiront par établir de nouvelles normes industrielles dans le Web 3.

Je suis convaincu depuis longtemps que les principales innovations de Shardeum sont très susceptibles d’influencer les futurs développements technologiques, en inspirant les innovations et les nouvelles générations de technologies de comptabilité. Ayant été témoin de la première restauration du réseau de Shardeum, je sais que cela catalysera une réévaluation des normes de l’industrie, conduisant potentiellement à l’adoption de protocoles et de méthodologies plus rigoureux dans la conception et l’architecture du réseau.

Cet événement met non seulement en valeur les prouesses techniques et l’innovation de l’équipe de Shardeum , mais marque également l’aube d’une ère où les réseaux décentralisés sont plus robustes, adaptables et capables de relever des défis imprévus en matière de planification de reprise après sinistre. À terme, la technologie de Shardeum annoncera une nouvelle ère de décentralisation.

Dernière mise à jour le 19 février 2024

#shardeumisborderless @shardeum