Explora Cardano: 2. Arquitectura: b. Acerca de Cardano DB Sync y sus componentes

Cardano DB Sync es uno de los componentes centrales de la arquitectura de Cardano, ya que proporciona una forma conveniente de encontrar y consultar información histórica de la blockchain de Cardano mediante el uso de una base de datos relacional en lenguaje de consulta estructurado (SQL). Db Sync se conecta al nodo local como cliente y se sincroniza con la actividad de la cadena. La base de datos PostgreSQL mapea entonces la información de la cadena al modelo relacional.

DB Sync puede ser utilizado por los usuarios y desarrolladores de Cardano que deseen conocer detalles específicos sobre la producción de bloques y las transacciones recientes. Estos detalles incluyen información de los bloques que permite a los usuarios seguir la cadena y explorar las transacciones dentro de los bloques, pero excluyen las firmas criptográficas.

Arquitectura de Cardano DB Sync

Cardano-db-sync consta de un conjunto de componentes:

cardano-db – define los tipos de datos y funciones comunes utilizados por cualquier aplicación que necesite interactuar con la base de datos desde Haskell. En particular, define el esquema de la base de datos.
cardano-db-tool – una herramienta utilizada para gestionar las bases de datos cardano-db-sync (crear, ejecutar, validar y analizar las migraciones).
cardano-db-sync – actúa como un nodo Cardano, siguiendo la cadena e insertando los datos de la cadena en una base de datos PostgreSQL.
cardano-db-sync-extended – una extensión relativamente sencilla de cardano-db-sync, que mantiene una tabla adicional que contiene los datos de épocas.
db-sync-node – diseñado para trabajar con un Nodo Cardano que se ejecuta localmente para almacenar datos en la base de datos PostgreSQL.

Las dos versiones cardano-db-sync y cardano-db-sync-extended son totalmente compatibles y utilizan esquemas de base de datos idénticos. La única diferencia es que la versión extendida mantiene una tabla Epoch, que la versión no extendida también creará pero no mantendrá.

El db-sync-node está escrito de forma altamente modular para permitir que sea lo más flexible posible. Se conecta a un nodo Cardano que se ejecuta localmente (es decir, el que está conectado a otros nodos de la red Cardano a través de Internet con TCP/IP) utilizando un socket de dominio Unix. El nodo Db-sync recupera bloques, actualiza el estado de su libro mayor interno y almacena partes de cada bloque en una base de datos PostgreSQL local.

PostgreSQL

PostgreSQL es una base de datos relacional genérica que se utiliza para el mapeo de la información de la cadena a un modelo relacional. Responde a necesidades y requisitos específicos de los usuarios utilizando la técnica de normalización para almacenar datos relacionales sin duplicación.

El siguiente diagrama resume la interacción entre los componentes del sistema:

GraphQL y REST API exportan una interfaz a los datos almacenados en la base de datos para que se pueda acceder a ellos desde hojas de cálculo, por ejemplo. El Frontend explorer es la herramienta más orientada al usuario; obtiene los datos de la base de datos principal y los refleja en una interfaz web sencilla y cómoda. Otro componente, el servidor SMASH, agrega los metadatos de los grupos de participación y proporciona a los operadores y delegados una lista de grupos de participación válidos con metadatos verificados.

GraphQL API Server (Apollo)

La API GraphQL proporciona una interfaz de consulta a todos los datos del blockchain a través de GraphQL, que es una opción conveniente para las aplicaciones cliente basadas en tecnologías web (aplicaciones escritas en JavaScript, o cualquier otro lenguaje basado en el navegador, por ejemplo) que utilizan APIs HTTP/REST para hablar con otros servicios. Es una alternativa a la interfaz SQL de las bases de datos. Los desarrolladores de aplicaciones pueden elegir entre SQL y GraphQL para acceder a los datos de la cadena.

La implementación de la API se basa en el servidor Apollo, un servidor GraphQL de código abierto que cumple con las especificaciones y es compatible con cualquier cliente GraphQL (incluido el cliente Apollo).

Componentes REST API

Hay dos componentes de Cardano que proporcionan una API REST HTTP para interactuar con un nodo local:

Un componente dedicado al envío de transacciones, que tiene un único terminal para el envío de transacciones.
Un componente de consulta para acceder a los datos del blockchain. Se trata de un componente heredado proporcionado para ayudar a la migración desde la era Byron. Cualquier aplicación que lo utilice actualmente debe planificar la migración a la API GraphQL o a la interfaz SQL.

La razón de esto es que la API REST está obsoleta, por lo que no hay razón para que las nuevas aplicaciones la utilicen para consultar los datos de la cadena. La API de envío es, por ahora, la única API basada en HTTP para el envío de tx, ya que GraphQL aún no admite el envío de tx, por lo que cualquier autor de aplicaciones que quiera utilizar APIs de tecnología web (en lugar de APIs de scripting o APIs de bajo nivel o Haskell) puede utilizar la API REST para el envío de tx.

Stake Pool Metadata Aggregation Server (SMASH)

El propósito del Stake Pool Metadata Aggregation Server (SMASH) es agregar los metadatos fuera de la cadena que los grupos de participación proporcionan cuando se registran en la blockchain de Cardano. Estos metadatos incluyen el nombre del grupo de participación, su nombre de ticker, su página web, etc.

La razón de ser de un servidor de agregación de metadatos en la arquitectura de Cardano es doble:

Mantener los metadatos del grupo de participación almacenados fuera de la cadena; y
Mantener la capacidad de moderar los metadatos de los grupos de participación, sin ningún tipo de censor centralizado.

Los metadatos se alojan fuera de la cadena y se hace referencia a ellos desde el registro de grupos en la cadena. SMASH recoge los datos fuera de la cadena para que el acceso de los monederos y otras aplicaciones sea más cómodo, eficaz y fiable.

El servidor SMASH también responde al deseo de moderar el contenido de los metadatos de los grupos de participación sin una entidad censora centralizada. Por ejemplo, a la mayoría de los usuarios de monederos y operadores de grupos de participación les gustaría tener la capacidad de tratar los nombres de los tickers de los grupos de participación como si fueran marcas comerciales únicas. Sería demasiado complejo tener un sistema justo, en la cadena, para resolver las disputas sobre los nombres de los tickers. En lugar de imponer la unicidad en la cadena, ésta puede imponerse opcionalmente mediante el filtrado como parte de la agregación de metadatos. Los servicios de agregación múltiples pueden ser ejecutados por diferentes organizaciones siguiendo diferentes políticas de filtrado de los metadatos del grupo de participación. Esto permite a los usuarios de monederos y a otros consumidores de metadatos de grupos de participación elegir qué política seguir, si es que hay alguna.

SMASH puede configurarse con políticas para filtrar los metadatos en función de listas de bloqueo o nombres de teletipos reservados. Daedalus puede configurarse para utilizar cualquier servidor SMASH.

Encuentra una copia oficial de este documento aquí:

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

Más traducciones de Cardano en: Cardano For The World