Explorez Cardano : 2. Architecture : b. À propos de Cardano DB Sync et de ses composants

Cardano DB Sync est l'un des principaux composants de l'architecture Cardano, car il offre un moyen pratique de trouver et d'interroger des informations historiques à partir de la blockchain Cardano no en utilisant une base de données relationnelle en langage SQL (Structured Query Language). Db Sync se connecte au node local en tant que client et se synchronise avec l'activité sur la chaîne. La base de données PostgreSQL fait ensuite correspondre les informations de la chaîne au modèle relationnel.

DB Sync peut être utilisé par les utilisateurs et les développeurs de Cardano qui souhaitent connaître des détails spécifiques concernant la production de blocs et les transactions récentes. Ces détails comprennent des informations sur les blocs qui permettent aux utilisateurs de suivre la chaîne et d'explorer les transactions au sein des blocs, mais excluent les signatures cryptographiques.

 

Architecture de Cardano DB Sync

Cardano-db-sync est constitué d'un ensemble de composants:

  • cardano-db – définit les types de données et les fonctions communs utilisés par toute application qui doit interagir avec la base de données à partir de Haskell. En particulier, il définit le schéma de la base de données.
  • cardano-db-tool – un outil utilisé pour gérer les bases de données cardano-db-sync (créer, exécuter, valider et analyser les migrations).
  • cardano-db-sync – agit comme un node Cardano, suivant la chaîne et insérant les données de la chaîne dans une base de données PostgreSQL.
  • cardano-db-sync-extended – une extension relativement simple de cardano-db-sync, qui maintient une table supplémentaire contenant les données des époques.
  • db-sync-node – conçu pour fonctionner avec un Node Cardano fonctionnant localement afin de stocker des données dans la base de données PostgreSQL.

Les deux versions cardano-db-sync et cardano-db-sync-extended sont entièrement compatibles et utilisent des schémas de base de données identiques. La seule différence est que la version étendue maintient une table Epoch, que la version non étendue créera également mais ne maintiendra pas.

Le db-sync-node est écrit de manière très modulaire pour lui permettre d'être aussi flexible que possible. Il se connecte à un cardano-node fonctionnant localement (c'est-à-dire celui qui est connecté aux autres nodes du réseau Cardano par Internet avec TCP/IP) en utilisant un socket de domaine Unix. Db-sync-node récupère les blocs, met à jour l'état de son grand livre interne et stocke des parties de chaque bloc dans une base de données PostgreSQL locale.

 

PostgreSQL

PostgreSQL est une base de données relationnelle générique utilisée pour le mappage des informations sur la chaîne vers un modèle relationnel. Elle répond aux besoins et exigences spécifiques des utilisateurs en utilisant la technique de normalisation pour stocker des données relationnelles sans duplication.

Le schéma suivant décrit l'interaction entre les composants du système:

GraphQL et REST API exportent une interface vers les données stockées dans la base de données afin d'y accéder depuis des feuilles de calcul, par exemple. Le Frontend explorer est l'outil le plus orienté vers l'utilisateur ; il récupère les données de la base de données principale et les reflète dans une interface web simple et pratique. Un autre composant, le serveur SMASH, rassemble les métadonnées des groupes d'enjeu et fournit aux opérateurs et aux délégués des groupes d'enjeu une liste des groupes d'enjeu valides avec des métadonnées vérifiées.

 

GraphQL API Server (Apollo)

L'API GraphQL fournit une interface d'interrogation de toutes les données de la blockchain via GraphQL, ce qui est un choix pratique pour les applications clientes basées sur des technologies web (applications écrites en JavaScript ou tout autre langage basé sur un navigateur, par exemple) qui utilisent des API HTTP/REST pour communiquer avec d'autres services. Il s'agit d'une alternative à l'interface SQL de la base de données. Les développeurs d'applications peuvent choisir entre SQL et GraphQL pour accéder aux données de la chaîne.

L'implémentation de l'API est basée sur le serveur Apollo, un serveur GraphQL open-source, conforme aux spécifications et compatible avec tout client GraphQL (y compris le client Apollo).

 

Composants REST API

Deux composants Cardano fournissent une API HTTP REST pour interagir avec un node local:

  • Un composant dédié à la soumission des transactions, qui dispose d'un point de terminaison unique pour la soumission des transactions.
  • Un composant d'interrogation pour accéder aux données de la blockchain. Il s'agit d'un composant hérité fourni pour faciliter la migration depuis l'ère Byron. Toutes les applications qui l'utilisent actuellement doivent prévoir de migrer vers l'API GraphQL ou l'interface SQL.

La raison en est que l'API REST est dépréciée et qu'il n'y a donc aucune raison pour que les nouvelles applications l'utilisent pour interroger les données de la chaîne. L'API de soumission est, pour l'instant, la seule API basée sur HTTP pour la soumission de tx, puisque GraphQL ne supporte pas encore la soumission de tx, donc tous les auteurs d'applications qui veulent utiliser des API de technologie web (plutôt que des API de script ou des API de bas niveau ou Haskell) peuvent utiliser l'API REST pour la soumission de tx.

 

Stake Pool Metadata Aggregation Server (SMASH)

L'objectif du Stake Pool Metadata Aggregation Server (SMASH) est d'agréger les métadonnées hors chaîne que les groupes d'enjeu fournissent lorsqu'ils s'inscrivent sur la blockchain Cardano. Ces métadonnées comprennent le nom du groupe de joueurs, son nom de téléscripteur, sa page d'accueil, etc.

La raison d'être d'un serveur d'agrégation de métadonnées dans l'architecture Cardano est double:

  1. Pour que les métadonnées des groupes d'enjeu soient stockées hors chaîne ; et
  2. Conserver la possibilité de modérer les métadonnées des groupes d'enjeu, sans censure centralisée.

Les métadonnées sont hébergées hors chaîne et sont référencées à partir de l'enregistrement des groupes sur la chaîne. SMASH collecte les données hors chaîne afin de les rendre plus pratiques, plus performantes et plus fiables pour les porte-monnaies et autres applications qui y accèdent.

Le serveur SMASH répond également au désir de modérer le contenu des métadonnées des groupes d'enjeu sans avoir recours à une entité de censure centralisée. Par exemple, la plupart des utilisateurs de porte-monnaies et des opérateurs de groupes d'enjeu aimeraient avoir la possibilité de traiter les noms de téléscripteurs de groupes d'enjeu comme s'il s'agissait de marques commerciales uniques. Il serait trop complexe de mettre en place un système équitable, sur la chaîne, pour résoudre les litiges relatifs aux noms de téléscripteurs. Au lieu d'imposer l'unicité sur la chaîne, on peut éventuellement l'imposer par filtrage dans le cadre de l'agrégation des métadonnées. Plusieurs services d'agrégation peuvent être gérés par différentes organisations suivant des politiques différentes en matière de filtrage des métadonnées du groupe d'enjeu. Cela permet aux utilisateurs de porte-monnaies et à d'autres consommateurs de métadonnées de groupe d'enjeu de choisir la politique à suivre, le cas échéant.

SMASH peut être configuré avec des politiques permettant de filtrer les métadonnées en fonction des listes de blocage ou des noms de téléscripteurs réservés. Daedalus peut être configuré pour utiliser n'importe quel serveur SMASH.

 

 

Vous trouverez une copie officielle de ce document ici :

https://docs.cardano.org/explore-cardano/cardano-architecture/about-db-sync-and-its-components

 

Plus de traductions de Cardano à: Cardano For The World