(1) À propos du réseau Cardano
Le réseau Cardano est une infrastructure technique combinant les nœuds Cardano et leurs interactions relatives dans un système unifié. Il se compose d’un ensemble de nœuds qui communiquent entre eux pour maintenir le registre distribué. Ces nœuds sont les acteurs sur Cardano qui valident les blocs, ajoutent des blocs à la chaîne et distribuent les transactions.
La couche réseau est la force motrice pour répondre aux exigences d’échange d’informations, qui incluent la diffusion de nouveaux blocs et les informations de transaction pour établir un meilleur flux de données. Les nœuds Cardano maintiennent des connexions avec des pairs qui ont été choisis via un processus de sélection de pairs personnalisé.
Flux de données entre et au sein des nœuds
Pour comprendre comment les nœuds communiquent entre eux, supposons que le nœud A est connecté au nœud B. Ensuite, le protocole Ouroboros programme un nœud N pour générer un nouveau bloc dans un créneau horaire donné. Selon l’emplacement des nœuds A, B et N dans la topologie du réseau, et si un nouveau bloc arrive en premier à A ou B, le nœud A peut être en amont ou en aval du nœud B.
Un ensemble de mini protocoles est utilisé pour permettre la communication entre différents nœuds. Chaque mini-protocole implémente une exigence d’échange d’informations de base, telle que l’information des pairs du dernier bloc, le partage de blocs selon les besoins ou le partage de nouvelles transactions sur le réseau Cardano. A des fins de connexion, les mini-protocoles sont déterminés par la version du protocole réseau. Par exemple, il existe deux suites de protocoles : nœud à nœud et nœud à client. La suite de protocoles nœud à client est utilisée par les portefeuilles et les chaînes de consommateurs. Les suites de protocoles utilisent différents ensembles de mini-protocoles et la version est négociée lorsqu’une nouvelle connexion est établie à l’aide d’un protocole spécifique (les protocoles sont décrits dans les sections suivantes).
Les clients peuvent également choisir les mini-protocoles nœud à client à utiliser, mais il est important de noter que le nœud doit pouvoir répondre à tous pour prendre en charge différents cas d’utilisation. Par exemple, pour communiquer, le nœud A exécute son instance côté client du mini-protocole de synchronisation de chaîne qui communique avec une instance de serveur du mini-protocole de synchronisation de chaîne au nœud B. Une telle situation est similaire à la fonctionnalité d’autres mini-protocoles .
Le schéma ci-dessous illustre comment les données circulent dans un nœud. Les cercles représentent les threads de protocole et les threads internes qui sont responsables de l’exécution des processus client et serveur dans les mini protocoles respectifs.
Deux types de flux de données existent :
- Les mini-protocoles communiquent avec les mini-protocoles d’autres nœuds en envoyant et en recevant des messages sur un réseau public (Internet) ; ce flux n’est pas couvert dans le schéma ci-dessus mais sera potentiellement conçu pour une meilleure compréhension.
- Au sein d’un nœud, les mini-protocoles communiquent entre eux en lisant et en écrivant dans une variable mutable partagée, qui est représentée par des cases dans le schéma. Les flèches indiquent si un thread a un accès en lecture ou en écriture à l’état partagé.
Aborder les complexités et les contraintes du réseau
Pour concevoir une architecture réseau efficace et robuste, un certain nombre de problèmes potentiels concernant la complexité et les contraintes ont été évalués.
Le contrôle de la congestion est l’une de ces fonctionnalités et est utilisé pour gérer la surcharge du système. Le contrôle de la congestion est essentiel pour garantir que le système est suffisamment robuste tout en exécutant des charges de travail élevées. Dans la conception du réseau, il est courant que le nombre de transactions qui se produisent puisse être supérieur au nombre qui peut être réellement traité pour être inclus dans la blockchain. Par conséquent, il est important de s’assurer que le taux croissant de soumission de transactions dans un bloc ne diminue pas les performances de la blockchain.
Le nœud réel a une limite à la quantité de données qu’il peut traiter. En particulier, un nœud peut devoir partager sa puissance de traitement avec d’autres processus qui s’exécutent sur la même machine ou instance de système d’exploitation. Cela signifie qu’un nœud peut ralentir et empêcher le système de traiter toutes les données disponibles sur le réseau.
Pour résoudre ces problèmes, la fonction de contrôle de congestion a été conçue pour fonctionner correctement dans une telle situation et récupérer des conditions transitoires. Dans tous les cas, un nœud ne doit pas dépasser ses limites de mémoire, il doit donc y avoir des limites de mémoire définies, dont les violations sont traitées comme des violations de protocole. Ces facteurs signifient que le système sera en mesure d’atteindre les objectifs de performance.
Les contraintes de temps réel et le temps universel coordonné sont d’autres aspects qui ont été pris en compte lors de la conception de l’architecture de réseau. À Cardano, les protocoles de consensus d’Ouroboros modélisent le passage du temps physique comme une séquence infinie de créneaux horaires, affectant des responsables de créneaux pour créer un nouveau bloc dans ces créneaux horaires. Cependant, le choix d’un créneau horaire peut entraîner certaines complexités en termes de longueur de créneau, car il doit être suffisamment long pour qu’un nouveau bloc ait de bonnes chances d’atteindre le prochain leader du créneau à temps. Par conséquent, une valeur choisie pour la longueur du créneau a été initialement fixée à 20 secondes à l’ère Byron. Avec Ouroboros Praos désormais implémenté à l’ère Shelley, une longueur de slot de 1 seconde est choisie mais, en moyenne, seulement 0,05 des slots produiront un bloc (et donc en moyenne, il y aura des intervalles de 20 secondes entre les blocs). On suppose que les décalages d’horloge entre les horloges locales des nœuds sont petits par rapport à la longueur du créneau. Les éventuelles imprécisions d’horloge doivent toujours être prises en compte, en particulier lorsqu’il s’agit de blocs entrants horodatés. Il est important de différencier s’il y a une différence de temps ou si le nœud considère un comportement contradictoire d’un autre nœud.
Utilisation de mini-protocoles
Les mini-protocoles sont utilisés pour communiquer entre plusieurs nœuds tout en mettant en œuvre les exigences d’échange d’informations. Un mini protocole est un bloc de construction modulaire défini du protocole réseau. La structuration du protocole réseau autour de mini-protocoles permet de gérer la complexité globale de la conception tout en garantissant une flexibilité utile.
Les mini-protocoles décrivent à la fois l’initiateur et le répondeur dans le flux de communication. L’initiateur est le double élément du répondeur et vice versa. Un nœud exécute généralement de nombreuses instances de mini-protocoles, qui comprennent de nombreuses instances du même mini-protocole. Chaque mini instance de protocole du nœud communique alors avec la double instance du pair exact. Tous les mini protocoles qui communiquent avec le même pair partagent un seul canal de communication (pipe ou socket). Un multiplexeur ou un démultiplexeur est utilisé pour multiplexer les protocoles respectifs sur ce canal.
L’ensemble de mini-protocoles utilisés pour la connexion entre deux participants du système dépend du rôle de ces participants, par exemple, si le nœud agit comme un nœud complet ou un consommateur de blockchain (par exemple, un portefeuille).
Il convient également de noter que la mise en œuvre de mini protocoles utilise un cadre générique pour les machines à états. Ce cadre utilise des techniques de correction par construction pour garantir l’implémentation de plusieurs propriétés du protocole. En particulier, cette technique garantit qu’aucun interblocage ne se produit et que la communication est annulée dans les scénarios suivants :
- Lorsqu’un côté est censé transmettre le message suivant, et que l’autre côté attend le message, et que les deux côtés conviennent que le protocole a été terminé
- Lorsque l’un ou l’autre côté reçoit un message qui n’est pas attendu selon le protocole
Tous les mini-protocoles basés sur ce framework incluent les informations suivantes dans leur description :
- une description informelle du protocole
- états de la machine d’état
- messages échangés
- un graphe de transition de la vue globale de la machine d’état
- la mise en œuvre du protocole par le client
- l’implémentation serveur du protocole
Exemples de mini protocoles
Cette section décrit quelques exemples de mini-protocoles.
- Protocole de ping-pong
Il s’agit d’un protocole de test simple qu’un client peut utiliser pour vérifier que le serveur est réactif. Le protocole Ping-Pong est très simple car les messages ne véhiculent aucune donnée et le client Ping-Pong, ainsi que le serveur Ping-Pong, n’accèdent pas à l’état interne du nœud.
- Protocole de demande de réponse
Le protocole de réponse à la demande est polymorphe dans les données de demande et de réponse qui sont transmises. Cela signifie qu’il existe différentes applications possibles de ce protocole et que l’application du protocole détermine les types de requêtes envoyées et les réponses reçues.
- Protocole de synchronisation de chaîne
Le protocole de synchronisation de chaîne est utilisé par un consommateur de blockchain pour répliquer localement la blockchain du producteur. Un nœud communique avec plusieurs nœuds en amont et en aval et exécute une instance de client indépendante et une instance de serveur indépendante pour chaque nœud avec lequel il communique.
Le protocole de synchronisation de chaîne est polymorphe. Le protocole nœud à client utilise une instance du protocole de synchronisation de chaîne qui transfère des blocs complets, tandis que l’instance nœud à nœud ne transfère que des en-têtes de bloc. Dans le scénario nœud à nœud, le protocole de récupération de blocs est utilisé pour transférer des blocs complets.
- Protocole de récupération de blocs
Le protocole de récupération de blocs permet à un nœud de télécharger une plage de blocs.
- Mini-protocole de soumission de transaction locale
Le mini-protocole de soumission de transaction locale est utilisé par des clients locaux, par exemple, des portefeuilles ou des outils CLI, pour soumettre des transactions à un nœud local. Le protocole n’est pas utilisé pour transmettre des transactions d’un nœud central à un autre. Le protocole suit un modèle simple de requête-réponse :
- le client envoie une demande avec une seule transaction.
- le serveur accepte soit la transaction (en retournant une confirmation), soit la rejette (en retournant la raison).
- Protocole de soumission de transaction nœud à nœud
Le protocole de soumission de transaction nœud à nœud est utilisé pour transférer des transactions entre des nœuds complets. Le protocole suit une stratégie basée sur l’extraction où l’initiateur demande de nouvelles transactions et le répondeur répond avec des transactions. Il convient à un environnement sans confiance où les deux parties doivent se prémunir contre les attaques de consommation de ressources de l’autre côté. La mise en œuvre du mini-protocole de transaction nœud à nœud est basée sur un cadre de mini-protocole générique (le même que pour tous les autres mini-protocoles). Pour des raisons techniques, les rôles de l’initiateur et du répondeur sont inversés dans ce cas par rapport à la façon dont d’autres mini protocoles sont implémentés dans le framework. En d’autres termes, le serveur est l’initiateur qui demande de nouvelles transactions et le client est le répondeur qui répond par des transactions.
- Mini-protocole de poignée de main
Le mini-protocole de prise de contact est utilisé pour négocier la version du protocole et les paramètres de protocole utilisés par le client et le serveur. Il est utilisé en premier lorsqu’une nouvelle connexion est initialisée et se compose d’une seule requête du client et d’une seule réponse du serveur. Le mini protocole de poignée de main est un protocole générique qui peut négocier tout type de paramètres de protocole. Il suppose que les paramètres de protocole peuvent être codés et décodés à partir de termes de représentation d’objet binaire concis (CBOR). Un nœud qui exécute le protocole de prise de contact doit l’instancier avec l’ensemble des versions de protocole prises en charge et des fonctions de rappel pour gérer les paramètres de protocole. Ces fonctions de rappel sont spécifiques aux versions de protocole prises en charge.
(2) Présentation de la conception du protocole réseau
Les protocoles de contrôle de transmission (TCP) et les protocoles Internet (IP) forment une suite de protocoles universellement déployée sur le réseau. TCP/IP permet un canal de communication bidirectionnel fiable entre les systèmes sur Internet.
La livraison ordonnée des protocoles de communication du nœud Cardano est garantie par le protocole TCP/IP.
Les systèmes d’exploitation limitent le nombre de connexions simultanées. Par défaut, Linux, par exemple, peut ouvrir 1 024 connexions par processus, alors que macOS limite ce nombre à 256. Pour éviter une utilisation excessive des ressources et permettre des moyens fiables d’établissement de connexion, Cardano utilise un multiplexeur.
Gestion des connexions
La couche réseau gère une gamme de tâches spécifiques en plus de l’échange d’informations de bloc et de transaction requises par le protocole Ouroboros.
Généralement, la mise en œuvre de la gestion des connexions inclut l’exécution des tâches suivantes :
- ouverture d’un socket et/ou acquisition de ressources depuis le système d’exploitation
- négocier la version du protocole avec le mini-protocole de prise de contact
- engendrant le thread qui exécute le multiplexeur (qui peut être chargé de démarrer/arrêter divers mini-protocoles)
- découvrir et classer les exceptions levées par les mini-protocoles ou le multiplexeur lui-même
- couper la connexion en cas d’erreur
- traitement d’une demande d’arrêt du pair
- fermer les threads qui exécutent des mini-protocoles
- fermeture d’une prise
Multiplexage
La couche de multiplexage agit comme un croisement central entre les mini-protocoles et le canal réseau. Il exécute plusieurs mini-protocoles en parallèle dans un seul canal ‒ une connexion TCP, par exemple.
La figure 1 montre comment les données circulent entre deux nœuds, chacun exécutant trois mini-protocoles utilisant un multiplexeur (MUX) et un démultiplexeur (DEMUX).
Figure 1. Flux de données entre les nœuds via le multiplexage
Les données transmises entre les nœuds passent par le MUX/DEMUX des nœuds. Il existe un appariement fixe d’instances de mini-protocole, ce qui signifie que chaque instance ne communique qu’avec sa double instance (un initiateur et un répondeur).
L’implémentation du mini-protocole gère également la sérialisation et la désérialisation de ses messages. Les mini-protocoles écrivent des blocs d’octets dans le MUX et lisent des blocs d’octets à partir du DEMUX. Le MUX lit les données des mini-protocoles, les divise en segments, ajoute un en-tête de segment et transmet les segments au DEMUX de son homologue. Le DEMUX utilise les en-têtes du segment pour réassembler les flux d’octets pour les mini-protocoles de son côté. Le protocole de multiplexage (voir la note ci-dessous) lui-même est complètement indépendant de la structure des données multiplexées.
Remarque : Il ne s’agit pas d’une utilisation générique, mais spécialisée, du multiplexage. Les mini-protocoles individuels ont des contraintes strictes sur les messages non acquittés qui peuvent être en vol. La conception évite les conditions dans lesquelles l’utilisation du multiplexage TCP sur TCP général crée des performances chaotiques.
Segments de données du protocole de multiplexage
Les segments de données de multiplexage incluent les détails suivants :
- Heure de transmission - un horodatage basé sur les 32 bits inférieurs de l’horloge monotone de l’expéditeur avec une résolution d’une microseconde.
- ID du mini-protocole ‒ l’ID unique du mini-protocole.
- Longueur de la charge utile ‒ la taille de la charge utile du segment en octets. La longueur maximale de charge utile prise en charge par le format de câble de multiplexage est de 216 − 1. Notez qu’une instance du protocole peut choisir une limite inférieure pour la taille des segments qu’elle transmet.
- Mode ‒ le bit unique M (le mode) est utilisé pour distinguer les instances doubles d’un mini-protocole. Le mode est défini sur 0 dans les segments de l’initiateur (le côté qui a initialement l’agence), et il est défini sur 1 dans les segments du répondeur.
Protocoles de communication du nœud Cardano
Cardano utilise des protocoles de communication inter-processus (IPC) pour permettre l’échange de blocs et de transactions entre les nœuds, et pour permettre aux applications locales d’interagir avec la blockchain via le nœud.
Présentation de l’IPC nœud à nœud
Le protocole Node-to-Node (NtN) transfère les transactions entre les nœuds complets. NtN comprend trois mini-protocoles (chain-sync, block-fetch et tx-submission), qui sont multiplexés sur un seul canal TCP à l’aide d’un package network-mux.
Le schéma suivant représente le flux opérationnel NtN :
NtN suit une stratégie basée sur l’extraction, où le nœud initiateur demande de nouvelles transactions et le nœud répondeur répond avec les transactions, le cas échéant. Ce protocole convient parfaitement à un environnement sans confiance où les deux côtés doivent être protégés contre les attaques de consommation de ressources de l’autre côté.
Les mini-protocoles NtN expliqués
Une brève explication des mini-protocoles NtN :
- chain-sync : un protocole qui permet à un nœud de reconstruire une chaîne d’un nœud en amont
- block-fetch : un protocole qui permet à un nœud de télécharger des corps de blocs à partir de différents pairs
- tx-submission : un protocole qui permet la soumission de transactions. L’implémentation de ce protocole est basée sur un cadre de mini protocole générique, avec une particularité : les rôles de l’initiateur et du répondeur sont inversés. Le serveur est l’initiateur qui demande de nouvelles transactions et le client est le répondeur qui répond avec les transactions. Cette inversion des rôles a été conçue ainsi pour des raisons techniques.
Pour assurer un service de mise en réseau optimal, l’équipe a également mis en place un protocole supplémentaire :
- keep-alive : un protocole qui assure une connexion continue entre les nœuds et minimise les défauts de performances.
Présentation de l’IPC nœud vers client
Node-to-Client (NtC) est une connexion entre un nœud complet et un client qui consomme des données mais ne participe pas au protocole Ouroboros (un portefeuille, par exemple).
Le but du protocole NtC IPC est de permettre aux applications locales d’interagir avec la blockchain via le nœud. Cela inclut des applications telles que les backends de portefeuille ou les explorateurs de blockchain. Le protocole NtC permet à ces applications d’accéder aux données brutes de la chaîne et d’interroger l’état actuel du grand livre, et il offre également la possibilité de soumettre de nouvelles transactions au système.
Le protocole NtC utilise la même conception que le protocole nœud à nœud (NtN), mais avec un ensemble différent de mini-protocoles et en utilisant des canaux locaux plutôt que des connexions TCP. En tant que tel, il s’agit d’une interface de niveau relativement bas et étroite qui n’expose que ce que le nœud peut fournir de manière native. Par exemple, le nœud donne accès à toutes les données brutes de la chaîne, mais ne permet pas d’interroger les données sur la chaîne. La tâche de fournir des services de données et des API de niveau supérieur plus pratiques est déléguée à des clients dédiés, tels que cardano-db-sync et le backend du portefeuille.
Mini-protocoles NtC
Le protocole NtC se compose de trois mini-protocoles :
- chain-sync - utilisé pour suivre la chaîne et obtenir des blocs
- local-tx-submission - utilisé pour soumettre des transactions
- local-state-query - utilisé pour interroger l’état du grand livre
La version NtC de la synchronisation en chaîne utilise des blocs complets, plutôt que de simples en-têtes de bloc. C’est pourquoi aucun protocole séparé de récupération de blocs n’est nécessaire. Le protocole local-tx-submission est similaire au protocole NtN tx-submission mais plus simple, et il renvoie les détails des échecs de validation des transactions. Le protocole de requête d’état local fournit un accès de requête à l’état actuel du registre, qui contient de nombreuses données intéressantes qui ne sont pas directement reflétées sur la chaîne elle-même.
Comment fonctionne NtC
Dans NtC, le nœud exécute uniquement le côté producteur du protocole de synchronisation de chaîne et le client exécute uniquement le côté consommateur.
Ce tableau montre quels mini-protocoles sont activés pour la communication NtC :
(3) Mise en réseau pair à pair (P2P)
Les nœuds Cardano et les interactions entre eux sont combinés au sein d’une couche réseau, qui distribue des informations sur les transactions et la création de blocs entre tous les nœuds actifs. De cette manière, le système valide et ajoute des blocs à la chaîne et vérifie également les transactions. Un réseau distribué de nœuds doit réduire au minimum les délais de communication et être suffisamment résilient pour faire face aux pannes ou aux contraintes de capacité.
Dans le système fédéré Byron, les nœuds étaient connectés par une configuration statique définie dans un fichier de topologie. Depuis l’introduction de Shelley, le système fonctionne en mode hybride. En passant de l’état fédéré de la connectivité réseau à l’état hybride, nous avons ajouté un réseau peer-to-peer (P2P) construit manuellement de nœuds de relais d’opérateur de pool de participation (SPO). Cela signifie que les nœuds centraux SPO peuvent se connecter à la fois aux nœuds relais fédérés et à d’autres nœuds relais exécutés par SPO. Cette connectivité n’est pas automatisée, cependant, elle permet l’échange d’informations sur les blocs et les transactions sans s’appuyer sur des nœuds fédérés. Au cours de cette étape, les nœuds de relais fédérés sont progressivement désactivés afin que les SPO puissent se connecter aux relais les uns des autres.
Pour assurer une communication efficace entre les nœuds, il est essentiel de permettre des connexions automatisées des relais SPO entre eux, de sorte qu’une configuration moins statique est nécessaire. Ceci est actuellement accompli grâce à des mises à niveau de la pile réseau, qui permettront à terme une topologie P2P complète pour tous les nœuds Cardano. La communication P2P améliorera le flux d’informations entre les nœuds, réduisant ainsi (et finalement supprimant) la dépendance du réseau vis-à-vis des nœuds fédérés et permettant une décentralisation complète du réseau Cardano.
Capacités P2P
La pile réseau subit un certain nombre d’améliorations pour atteindre la résilience réseau souhaitée. Ces améliorations ne nécessitent pas de changement de protocole, mais permettent plutôt une sélection automatisée des pairs et une communication entre les pairs et les nœuds.
La mise en réseau P2P est activée grâce à l’utilisation des composants suivants :
- Gouverneur P2P ‒ gère l’initiation automatique des connexions entre pairs.
- Gestionnaire de connexion ‒ s’intègre au gouverneur P2P pour surveiller les nouvelles connexions et les nouveaux protocoles, ce qui garantit une communication efficace et un meilleur suivi des problèmes.
- Serveur ‒ accepte les connexions et limite les débits dynamiques en les synchronisant avec le gestionnaire de connexions.
- Gouverneur de protocole entrant ‒ reçoit des données du gestionnaire de connexions pour démarrer ou redémarrer les mini-protocoles du répondeur sur les connexions duplex entrantes et sortantes.
Ensuite, nous examinons de plus près le fonctionnement du gouverneur P2P pour assurer une connectivité automatisée entre les nœuds homologues du réseau.
Fonctionnalité de gouverneur P2P
Le réseau Cardano se compose de plusieurs nœuds pairs. Certains nœuds homologues sont plus actifs que d’autres, certains ont établi des connexions et certains doivent être promus pour garantir les meilleures performances du système. Chaque nœud producteur de blocs maintient un ensemble de pairs mappés en trois catégories :
- homologues froids ‒ homologues existants sans connexion réseau établie
- homologues chauds ‒ homologues avec une connexion porteuse établie, qui n’est utilisée que pour les mesures de réseau sans implémenter aucun des mini-protocoles nœud à nœud.
- hot peers ‒ pairs qui ont une connexion, qui est utilisée par les trois mini-protocoles nœud à nœud
Les homologues nouvellement découverts sont initialement ajoutés à l’ensemble d’homologues froids. Le gouverneur P2P est alors responsable de la gestion des connexions des pairs : il définit quels pairs sont bénéfiques à des fins de connexion, et lesquels doivent être promus ou rétrogradés entre les ensembles froids, chauds ou chauds.
L’objectif principal du gouverneur P2P est de maintenir le nombre cible de pairs froids, chauds et chauds. Cela crée et maintient une carte de connectivité de l’ensemble du réseau et simplifie le processus de définitions de connexion en les traitant automatiquement.
Pour établir la connectivité entre les nœuds, le gouverneur P2P s’engage dans les activités suivantes :
- les potins aléatoires utilisés pour découvrir un plus grand nombre de pairs froids
- promotion des pairs froids aux pairs chauds
- rétrogradation de pairs chauds à des pairs froids
- promotion de pairs chaleureux à des pairs chauds
- rétrogradation de pairs chauds en pairs chauds
Le gouverneur P2P doit établir et maintenir :
- un nombre cible de pairs froids (par exemple, 100)
- un nombre cible de hot peers (par exemple, entre 2 et 20)
- un nombre cible de pairs chaleureux (par exemple, entre 10 et 50)
- un ensemble de pairs chaleureux qui sont suffisamment diversifiés en termes de distance de saut et d’emplacements géographiques
- une fréquence de désabonnement cible pour les changements chauds ou chauds
- une fréquence de désabonnement cible pour les changements chauds ou froids
- une fréquence d’attrition cible pour les changements froids ou inconnus
L’utilisation de 2 à 20 homologues chauds est rentable, car les homologues n’échangent que leurs en-têtes de bloc. Le corps du bloc, à son tour, n’est généralement demandé qu’une seule fois, et il a tendance à suivre le chemin le plus court à travers le graphe de connectivité.
Le but des pairs chauds est de fournir un accès aux pairs qui peuvent être rapidement promus au rang de pairs chauds (au cas où l’un des pairs chauds échouerait), et également de fournir des candidats pour le roulement des pairs chauds.
La politique de sélection des homologues chauds à promouvoir repose sur les mesures en amont. Le but d’un degré de désabonnement entre les pairs froids et chauds est, en partie, de découvrir la distance du réseau entre plusieurs pairs et de permettre à des pairs chauds potentiellement meilleurs de prendre le relais des pairs chauds existants. Cela permet une optimisation et des ajustements supplémentaires. Le maintien de la diversité des distances de saut contribue à améliorer les temps de distribution des blocs sur le réseau distribué à l’échelle mondiale.
Dans l’ensemble, cette approche suit un modèle commun de recherche ou d’optimisation probabiliste qui utilise un équilibre d’optimisation locale avec certains éléments de perturbation d’ordre supérieur pour éviter de se retrouver piégé dans un optimum local médiocre.
Les pairs conservent un ensemble limité d’informations, qui est basé sur leurs interactions directes précédentes. Les pairs froids, par exemple, peuvent ne conserver aucune donnée, car ils n’ont pas encore établi d’interactions. Ces données peuvent être comparées à la propriété de «réputation», cependant, ces détails sont purement locaux et ne sont pas partagés entre d’autres nœuds. Les informations de réputation des homologues locaux sont également mises à jour lorsque les connexions homologues échouent. Le réseau ne conserve pas les informations négatives sur les pairs pendant de longues périodes : pour limiter les ressources et en raison de la simplicité des attaques Sybil.
L’implémentation classe les exceptions qui provoquent des échecs de connexion en trois classes :
- exceptions de nœud interne (par exemple, corruption de disque local)
- pannes de réseau (par exemple, connexions TCP interrompues)
- comportement contradictoire (par exemple, une violation de protocole détectée par la couche des protocoles typés ou par la couche consensus).
En cas de comportement contradictoire, le pair peut être immédiatement rétrogradé des ensembles chauds, chauds ou froids.
Source : https://docs.cardano.org/explore-cardano/cardano-network/about-the-cardano-network