Explorez Cardano : 3. Réseau Cardano : b. Aperçu de la conception du protocole de réseau

Transmission Control Protocols (TCP) et Internet Protocols (IP) forment une suite de protocoles universellement déployées sur le réseau. TCP/IP permet un canal de communication bidirectionnel fiable entre les systèmes sur l'internet.

La livraison ordonnée des protocoles de communication des nodes Cardano est garantie par le protocole TCP/IP.

Les systèmes opérationnels limitent le nombre de connexions simultanées. Par défaut, Linux, par exemple, peut ouvrir 1 024 connexions par processus, tandis que macOS limite ce nombre à 256. Pour éviter une utilisation excessive des ressources et permettre des moyens fiables pour l'établissement des connexions, Cardano utilise un multiplexeur.

 

Gestion des connexions

La couche réseau gère une série de tâches spécifiques, outre l'échange d'informations sur les blocs et les transactions requis par le protocole Ouroboros.

En général, la mise en œuvre de la gestion des connexions comprend l'exécution des tâches suivantes:

• ouverture d'un socket et/ou acquisition de ressources auprès du OS
• négocier la version du protocole avec le mini-protocole handshake
• le lancement du thread qui fait tourner le multiplexeur (qui peut être chargé de démarrer/arrêter divers mini-protocoles)
• découvrir et classer les exceptions lancées par les mini-protocoles ou le multiplexeur lui-même
• la fermeture de la connexion en cas d'erreur
• traitement d'une demande d'arrêt du pair
• arrêter les threads qui exécutent les mini-protocoles
• fermer un socket

 

Multiplexage

La couche de multiplexage sert de point de passage central entre les mini-protocoles et le canal réseau. Elle fait fonctionner plusieurs mini-protocoles en parallèle dans un seul canal - connexion TCP, par exemple.

La figure 1 montre comment les données circulent entre deux nodes, chacun exécutant trois mini-protocoles à l'aide d'un multiplexeur (MUX) et d'un démultiplexeur (DEMUX).

Figure 1. Flux de données entre les nodes par multiplexage

Les données transmises entre les nodes passent par les MUX/DEMUX des nodes. Il existe une paire fixe d'instances de mini-protocole, ce qui signifie que chaque instance ne communique qu'avec son instance double (un côté initiateur et un côté 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 au MUX et lisent des blocs d'octets au 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 pair. 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 agnostique à 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 permet d'éviter les conditions dans lesquelles l'utilisation du multiplexage général TCP sur TCP crée des performances chaotiques.

 

Segments de données du protocole de multiplexage

Les segments de données de multiplexage comprennent 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 la charge utile prise en charge par le format de fil 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 deux instances d'un mini-protocole. Le mode est défini à 0 dans les segments de l'initiateur (le côté qui a initialement l'agence), et il est défini à 1 dans les segments du répondeur.

 

Protocoles de communication des nodes Cardano

Cardano utilise des protocoles de communication interprocessus (IPC) pour permettre l'échange de blocs et de transactions entre les nodes, et pour permettre aux applications locales d'interagir avec la blockchain via le node.

 

Aperçu de l'IPC de node à node

Le protocole NtN (Node-to-Node) transfère des transactions entre des nodes 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 paquet network-mux.

Le schéma suivant représente le flux opérationnel du NtN:

NtN suit une stratégie basée sur la traction, où le node initiateur demande de nouvelles transactions et le node répondant répond avec les transactions si elles existent. Ce protocole convient parfaitement à un cadre sans confiance où les deux parties doivent être protégées contre les attaques de consommation de ressources de l'autre partie.

 

Les mini-protocoles NtN expliqués

Une brève explication des mini-protocoles NtN:

• chain-sync : un protocole qui permet à un node de reconstruire la chaîne d'un node en amont
• block-fetch : un protocole qui permet à un node de télécharger des corps de bloc à partir de divers pairs
• tx-submission: un protocole qui permet de soumettre des transactions. L'implémentation de ce protocole est basée sur un cadre générique de mini protocole, 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 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 nodes et minimise les défauts de performance.

 

Aperçu de l'IPC Node-to-Client

Node-to-Client (NtC) est une connexion entre un node complet et un client qui consomme des données mais ne participe pas au protocole Ouroboros (un porte-monnaie, par exemple).

L'objectif du protocole NtC IPC est de permettre aux applications locales d'interagir avec la blockchain via le node. Il s'agit d'applications telles que les backends de porte-monnaies 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 Node-to-Node (NtN), mais avec un ensemble différent de mini-protocoles, et en utilisant des tuyaux locaux plutôt que des connexions TCP. En tant que tel, il s'agit d'une interface relativement basse et étroite qui n'expose que ce que le node peut fournir nativement. Par exemple, le node fournit l'accès à toutes les données brutes de la chaîne mais ne fournit pas un moyen d'interroger les données sur la chaîne. La tâche de fournir des services de données et des API de plus haut niveau plus pratiques est déléguée à des clients dédiés, tels que cardano-db-sync et le backend du porte monnaie.

 

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 chain-sync 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 semblable au protocole NtN tx-submission mais plus simple, et il renvoie les détails des échecs de validation des transactions. Le protocole local-state-query fournit un accès par requête à l'état actuel du grand livre, qui contient beaucoup de données intéressantes qui ne sont pas directement reflétées sur la chaîne elle-même.

 

Comment fonctionne le NtC

Dans NtC, le node exécute uniquement le côté producteur du protocole chain-sync, et le client exécute uniquement le côté consommateur.

Ce tableau montre quels mini-protocoles sont activés pour la communication NtC :

 

 

Vous trouverez une copie officielle de ce document ici :

https://docs.cardano.org/explore-cardano/cardano-network/networking-protocol

 

Plus de traductions de Cardano à: Cardano For The World