Skip to main content

Démon

Dans cette section, nous décrirons comment les nœuds IBax interagissent les uns avec les autres d'un point de vue technique.

À propos du démon du serveur​

Le démon du serveur doit s'exécuter sur chaque nœud du réseau, ce qui exécute diverses fonctions de serveur et prend en charge le protocole de blockchain d'IBax. Dans le réseau de blockchain, le démon distribue les blocs et les transactions, génère de nouveaux blocs, vérifie les blocs et les transactions reçus, et il peut éviter le problème de fork.

Démon du nœud d'honneur​

Un nœud d'honneur exécute les démons de serveur suivants :

  • démon BlockGenerator

    Génération de nouveaux blocs.

  • démon BlockCollection

    Téléchargement de nouveaux blocs à partir d'autres nœuds.

  • démon Confirmations

    Confirmer que les blocs sur le nœud existent également sur la plupart des autres nœuds.

  • démon Disseminator

    Distribution des transactions et des blocs vers d'autres nœuds honneurs.

  • QueueParserBlocks démon

    Blocs dans la file d'attente, qui contient des blocs provenant d'autres nœuds.

    La logique de traitement des blocs est la même que celle du démon démon BlockCollection.

  • QueueParserTx démon

    Vérification des transactions en attente.

  • Scheduler démon

    Exécution des contrats selon le planning prévu.

Démon du nœud gardien​

Un nœud gardien exécute les démons de serveur suivants :

Démon BlockCollection​

Ce démon télécharge des blocs et synchronise la blockchain avec d'autres nœuds du réseau.

Synchronisation de la blockchain​

Ce démon synchronise la blockchain en déterminant la hauteur maximale du bloc dans le réseau de la blockchain, en demandant de nouveaux blocs et en résolvant le problème de la fourche dans la blockchain.

Vérifiez les mises à jour de la blockchain​

Ce démon envoie des requêtes de l'ID de bloc actuel à tous les nœuds honorés.

Si l'ID de bloc actuel du nœud exécutant le démon est inférieur à l'ID de bloc actuel de n'importe quel nœud honoré, le nœud du réseau blockchain est considéré comme obsolète.

Télécharger les nouveaux blocs​

Le nœud qui renvoie la hauteur de bloc la plus élevée actuelle est considéré comme le dernier nœud. Le démon télécharge tous les blocs inconnus.

Résoudre le problème de la fourche​

Si une fourchette est détectée dans la blockchain, le démon déplace la fourchette en arrière en téléchargeant tous les blocs jusqu'à un bloc parent commun. Lorsque le bloc parent commun est trouvé, un retour en arrière de la blockchain est effectué sur le nœud exécutant le démon, et le bloc correct est ajouté à la blockchain jusqu'à ce que le dernier soit inclus.

Table de données​

Le démon BlocksCollection utilise les tables suivantes :

  • block_chain
  • transactions
  • transactions_status
  • info_block

Demande​

Le démon BlockCollection envoie les requêtes suivantes aux autres démons :

  • Type 10 pointe vers l'identifiant de bloc le plus grand parmi tous les nœuds honorés.
  • Type 7 pointe vers les données avec l'identifiant de bloc le plus grand.

Le démon BlockGenerator​

Le démon BlockGenerator génère de nouveaux blocs.

Pré-vérification​

Le démon BlockGenerator analyse les derniers blocs de la blockchain pour créer de nouveaux plans de génération de blocs.

Si les conditions suivantes sont remplies, un nouveau bloc peut être généré :

  • Le nœud qui a généré le dernier bloc se trouve dans un nœud de la liste d'honneur et exécute le démon.
  • Le laps de temps le plus court depuis la génération du dernier bloc non vérifié.

Génération de blocs​

Un nouveau bloc généré par le démon contient toutes les nouvelles transactions, qui peuvent être reçues du démon Disseminator d'autres nœuds ou générées par le nœud exécutant le démon. Le bloc généré est stocké dans la base de données du nœud.

Table de données​

Le démon BlockGenerator utilise les tables suivantes :

  • block_chain (saves new blocks)
  • transactions
  • transactions_status
  • info_block

Demande​

Le démon BlockGenerator ne fait aucune demande aux autres démons.

Démon Disseminator​

Le démon Disseminator envoie des transactions et des blocs à tous les nœuds honorés.

Nœud gardien​

Lorsque vous travaillez sur un nœud gardien, le démon envoie les transactions générées par son nœud à tous les nœuds honorables.

Nœud d'honneur​

Lorsqu'il travaille sur un nœud d'honneur, le démon envoie les blocs générés et les hachages de transaction à tous les nœuds d'honneur.

Ensuite, le nœud d'honneur répond aux demandes de transaction qui lui sont inconnues. Le démon envoie les données de transaction complètes en réponse.

Table de données​

Le démon Disseminator utilise les tables suivantes :

  • transactions

Demande​

Le démon Disseminator envoie les demandes suivantes à d'autres démons :

  • Type 1 Envoyer des transactions et des hachages de bloc à l'hôte honor.
  • Type 2 Recevoir des données de transaction de l'hôte honor.

Démon de confirmations​

Le démon de confirmation vérifie si tous les blocs de son nœud existent sur la plupart des autres nœuds.

Confirmation de bloc​

Un bloc confirmé par plusieurs nœuds dans le réseau est considéré comme un bloc confirmé.

Le démon confirme tous les blocs un par un, en commençant par le premier qui n'est pas encore confirmé dans la base de données.

Chaque bloc est confirmé de la manière suivante :

  • En envoyant une demande contenant l'ID du bloc en cours de confirmation à tous les nœuds honorés.
  • Tous les nœuds honorés répondent avec le hachage du bloc.
  • Si le hachage renvoyé correspond au hachage du bloc sur le nœud du démon, la valeur du compteur de confirmation est augmentée. Sinon, la valeur du compteur d'annulation est augmentée.

Table de données​

Le démon de confirmation utilise les tables suivantes :

  • confirmation
  • info_block

Demande​

Le démon de confirmation envoie les demandes suivantes aux autres démons :

  • Type 4 Demande les hachages des blocs à partir du nœud d'honneur.

Protocole de service TCP​

Le protocole de service TCP fonctionne sur des nœuds honorables et des nœuds gardiens, qui utilisent le protocole binaire sur TCP pour les demandes des démons BlocksCollection, Disseminator et Confirmation.

Type de demande​

Chaque demande a un type défini par les deux premiers octets de la demande.

Type 1​

### Demandeur de l'envoi

Cette demande est envoyée par le démon Disseminator.

### D'accord, je vais demander les données.

Hachages de la transaction et du bloc.

### Traitement de la demande

Le hachage du bloc est ajouté à la file d'attente des blocs.

Analyse et vérifie les hachages des transactions, et sélectionne les transactions qui n'ont pas encore été présentes sur le nœud.

Réponse​

Non. Après avoir traité la demande, une demande de Type 2 est émise.

Type 2​

### Demandeur de l'expéditeur

Cette demande est envoyée par le démon Disseminator.

### Demande de données

Les données de transaction, y compris la taille des données :

  • data_size (4 octets)

  • Taille des données de la transaction, en octets.

  • données (data_size octets)

Les données de la transaction.

### Traitement de la demande

Vérifie la transaction et l'ajoute à la file d'attente des transactions.

Réponse​

No.

Type 4​

Demande de l'expéditeur​

Cette demande est envoyée par le démon confirmations.

Demande de données​

Identifiant de bloc.

Réponse​

Hachage de bloc.

Renvoie 0 s'il n'y a pas de bloc avec cet identifiant.

Type 7​

Demande de l'expéditeur​

Cette demande est envoyée par le démon BlockCollection.

Demande de données​

Identifiant de bloc.

  • block_id (4 octets)

Réponse​

Les données du bloc, y compris la taille des données.

  • data_size (4 octets)

  • Taille des données du bloc, en octets.

  • data (data_size octets)

Les données du bloc.

La connexion est fermée s'il n'y a pas de bloc avec cet identifiant.

Type 10​

### Demande de l'expéditeur

Cette demande est envoyée par le [démon BlockCollection].(#blockcollection-daemon).

### Demande de données

Non.

Réponse​

Identifiant de bloc.

  • block_id (4 octets)