Explorez Cardano : 3. Réseau Cardano : a. À propos du réseau Cardano

Le réseau Cardano est une infrastructure technique combinant les nodes Cardano et leurs interactions relatives dans un système unifié. Il se compose d'une collection de nodes qui communiquent entre eux pour maintenir le grand livre distribué. Ces nodes sont les acteurs de 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 besoins d'échange d'informations, ce qui inclut la diffusion de nouveaux blocs et les informations sur les transactions pour établir un meilleur flux de données. Les nodes Cardano maintiennent des connexions avec des pairs qui ont été choisis via un processus personnalisé de sélection des pairs.

Suivez ces liens pour trouver les spécifications détaillées de :

Flux de données entre et dans les nodes

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 slot temporel donné. Selon l'emplacement des nœuds A, B et N dans la topologie du réseau, et selon qu'un nouveau bloc arrive d'abord à A ou à B, le nœud A peut se trouver en amont ou en aval du nœud B.

Un ensemble de mini-protocoles est utilisé pour permettre la communication entre les différents nœuds. Chaque mini protocole met en œuvre une exigence d'échange d'informations de base, telle que l'information des pairs sur le dernier bloc, le partage des blocs si nécessaire ou le partage des nouvelles transactions sur le réseau Cardano. À des fins de connexion, les mini-protocoles sont déterminés par la version du protocole du réseau. Par exemple, il existe deux suites de protocoles : node-to-node et node-to-client. La suite de protocoles node-to-client est utilisée par les porte-monnaies et les consommateurs de chaînes. 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 de nœud à client à utiliser, mais il est important de noter que le nœud doit être capable de répondre à tous ces mini-protocoles 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 chain-sync qui communique avec une instance serveur du mini-protocole chain-sync au nœud B. Une telle situation est similaire à la fonctionnalité d'autres mini-protocoles.

Le schéma ci-dessous illustre la manière dont 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.

Il existe deux types de flux de données :

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 par le schéma ci-dessus, mais il sera éventuellement 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, 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é.

Prise en compte des complexités et des contraintes du réseau

Afin de concevoir une architecture de 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 fonctions 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 pour supporter des charges de travail élevées. Dans la conception du réseau, il est courant que le nombre de transactions qui se produisent soit plus élevé que le nombre de transactions qui peuvent être effectivement traitées pour être incluses 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 exécutés sur la même machine ou instance de système d'exploitation. Cela signifie qu'un nœud peut ralentir et que le système n'est pas en mesure 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 de manière appropriée dans une telle situation et se remettre 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 le dépassement est traité comme une violation du 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. Dans Cardano, les protocoles de consensus Ouroboros modélisent le passage du temps physique comme une séquence infinie de slots, et attribuent aux leaders de slot la création d'un nouveau bloc dans ces slots. Cependant, le choix d'un slot peut entraîner certaines complexités en termes de longueur du slot, car il doit être suffisamment long pour qu'un nouveau bloc ait une bonne chance d'atteindre le prochain leader de slot à temps. Par conséquent, la valeur choisie pour la longueur du slot était initialement fixée à 20 secondes à l'ère Byron. Avec Ouroboros Praos actuellement mis en œuvre à l'époque de Shelley, une longueur de slot de 1 seconde est choisie mais, en moyenne, seulement 0,05 des slots produira 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 faibles par rapport à la longueur du slot. Les éventuelles imprécisions d'horloge doivent néanmoins être prises en considération, notamment 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 noeud considère un comportement adversatif d'un autre noeud.

Utilisation de mini-protocoles

Les mini-protocoles sont utilisés pour communiquer entre plusieurs nœuds tout en mettant en œuvre les exigences en matière d'échange d'informations. Un mini protocole est un bloc de construction modulaire défini du protocole de réseau. La structuration du protocole de 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 au sein du flux de communication. L'initiateur est l'élément double du répondeur et vice versa. Un nœud exécute généralement plusieurs instances de mini-protocoles, dont plusieurs instances du même mini-protocole. Chaque instance de mini protocole du nœud communique alors avec l'instance double 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 des 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 en tant que nœud complet ou consommateur de blockchain (par exemple, un porte-monnaie).

Il convient également de noter que la mise en œuvre des mini-protocoles utilise un cadre générique pour les machines à états. Ce cadre utilise des techniques de correction par construction pour garantir la mise en œuvre de plusieurs propriétés du protocole. En particulier, cette technique assure qu'aucun blocage ne se produit et que la communication n'est pas 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 est terminé
lorsque l'une des parties reçoit un message qui n'est pas attendu selon le protocole

Tous les mini-protocoles basés sur ce cadre 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 à états
l'implémentation du protocole par le client
l'implémentation du protocole par le serveur

Exemples de mini protocoles

Cette section présente quelques exemples de mini protocoles.

Protocole Ping Pong

Il s'agit d'un protocole simple pour tester 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 transportent pas de données 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 demande de réponse est polymorphe en ce qui concerne 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 demandes envoyées et de réponses reçues.

Protocole de Synchronisation de la Chaîne

Le protocole de synchronisation de la 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 client indépendante et une instance 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 transfère uniquement 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 série de blocs.

Mini protocole de Soumission de Transactions Locales

Le Mini protocole de Soumission de Transactions Locales est utilisé par les clients locaux, par exemple les porte-monnaies ou les 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 demande-réponse:

le client envoie une demande avec une seule transaction.
le serveur accepte la transaction (en renvoyant une confirmation) ou la rejette (en renvoyant la raison).

Protocole de Soumission des Transactions de Nœud à Nœud

Le protocole de soumission de transactions de nœud à nœud est utilisé pour transférer des transactions entre des nœuds complets. Le protocole suit une stratégie de type "pull" dans laquelle l'initiateur demande de nouvelles transactions et le répondant répond avec des transactions. Il convient à un environnement sans confiance où les deux parties doivent se protéger contre les attaques de consommation de ressources de l'autre partie. La mise en œuvre du mini protocole de transaction de 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 les autres mini protocoles sont mis en œuvre dans le cadre. En d'autres termes, le serveur est l'initiateur qui demande de nouvelles transactions et le client est le répondeur qui répond avec des transactions.

Mini protocole Handshake

Le mini protocole handshake est utilisé pour négocier la version du protocole et les paramètres du protocole utilisés par le client et le serveur. Il est utilisé en premier lieu lors de l'initialisation d'une nouvelle connexion et consiste en une seule demande du client et 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 du protocole peuvent être codés et décodés à partir de termes CBOR (Concise Binary Object Representation). Un nœud qui exécute le protocole de poignée de main doit l'instancier avec l'ensemble des versions de protocole prises en charge et des fonctions de rappel pour traiter les paramètres de protocole. Ces fonctions de rappel sont spécifiques aux versions du protocole prises en charge.

Vous trouverez une copie officielle de ce document ici :

https://docs.cardano.org/explore-cardano/cardano-network/about-the-cardano-network

Plus de traductions de Cardano à: Cardano For The World