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

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:

explore-2b-1

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:

  1. Mantener los metadatos del grupo de participaci贸n almacenados fuera de la cadena; y
  2. 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