Componentes do DB Sync

Cardano-db-sync é composto por um conjunto de componentes:

• cardano-db – define tipos de dados comuns e funções usadas por qualquer aplicação que precise interagir com o banco de dados a partir do Haskell. Em particular, define o esquema do banco de dados.
• cardano-db-tool – uma ferramenta usada para gerenciar bancos de dados do cardano-db-sync (criar, executar, validar e analisar migrações).
• cardano-db-sync – atua como um nó Cardano, seguindo a cadeia e inserindo dados da cadeia em um banco de dados PostgreSQL.
• db-sync-node – projetado para trabalhar com um Nó Cardano em execução localmente para armazenar dados no banco de dados PostgreSQL.

O db-sync-node é escrito de maneira altamente modular para permitir que seja o mais flexível possível. Ele se conecta a um cardano-node em execução local (ou seja, aquele conectado a outros nós na rede Cardano pela internet com TCP/IP) usando um socket de domínio Unix. O db-sync-node recupera blocos, atualiza seu estado interno do livro-razão e armazena partes de cada bloco em um banco de dados PostgreSQL local.

PostgreSQL

PostgreSQL é um banco de dados relacional genérico usado para o mapeamento de informações on-chain para um modelo relacional. Ele atende a necessidades e requisitos específicos do usuário usando a técnica de normalização para armazenar dados relacionais sem duplicação.

O seguinte diagrama esboça a interação entre os componentes do sistema:

GraphQL e REST API exportam uma interface para os dados armazenados no banco de dados para serem acessados de planilhas, por exemplo. Frontend explorer é a ferramenta mais orientada ao usuário; ele busca dados do banco de dados principal e os reflete em uma interface web direta e conveniente. Outro componente, o servidor SMASH, agrega metadados de stakepool e fornece aos operadores de pool e delegadores uma lista de stake pools válidos com metadados verificados.

Servidor API GraphQL (Apollo)

A API GraphQL fornece uma interface de consulta para todos os dados da blockchain via GraphQL, que é uma escolha conveniente para aplicações cliente baseadas em tecnologias web (aplicações escritas em JavaScript, ou qualquer outra linguagem baseada em navegador, por exemplo) que usam APIs HTTP/REST para se comunicar com outros serviços. É uma alternativa à interface SQL do banco de dados. Desenvolvedores de aplicativos podem escolher entre SQL e GraphQL para acessar os dados da cadeia.

A implementação da API é baseada no Apollo Server, um servidor GraphQL de código aberto e compatível com qualquer cliente GraphQL (incluindo o Apollo Client).

Componentes da API REST

Existem dois componentes do Cardano que fornecem uma API REST HTTP para interagir com um nó local:

• Um componente de submissão de transações dedicado, que possui um único endpoint para submeter transações.
• Um componente de consulta para acessar dados da blockchain. Este é um componente legado fornecido para auxiliar a migração da era Byron. Qualquer aplicativo que atualmente o utilize deve planejar migrar para a API GraphQL ou a interface SQL.

A razão para isso é que a API REST está obsoleta, então não há razão para novas aplicações a usarem para consultar dados da cadeia. A API de submissão, por agora, é a única API baseada em HTTP para submissão de tx, já que o GraphQL ainda não suporta submissão de tx, então qualquer autor de aplicativo que queira usar APIs de tecnologia web (em vez de APIs de script ou APIs de baixo nível ou Haskell) pode usar a API REST para submissão de tx.

Servidor de Agregação de Metadados de stakepool (SMASH)

O propósito do Servidor de Agregação de Metadados de stakepool (SMASH) é agregar metadados off-chain que os stake pools fornecem quando se registram na blockchain Cardano. Esses metadados incluem o nome da stakepool, seu nome de ticker, página da web, e assim por diante.

A razão para um servidor de agregação de metadados na arquitetura Cardano é dupla:

1. Para manter os metadados da stakepool armazenados off-chain; e
2. Para reter a capacidade de moderar os metadados da stakepool, sem qualquer censor centralizado.

Os metadados são hospedados off-chain e referenciados a partir do registro da pool on-chain. O SMASH coleta os dados off-chain para torná-los mais convenientes, performáticos e confiáveis para carteiras e outras aplicações acessarem.

O servidor SMASH também aborda o desejo de moderar o conteúdo dos metadados da stakepool sem uma entidade de censura centralizada. Por exemplo, a maioria dos usuários de carteira e operadores de stakepool gostaria de ter a capacidade de tratar os nomes de ticker dos stake pools como se fossem marcas registradas únicas. Seria complexo demais ter um sistema justo on-chain para resolver disputas de nome de ticker. Em vez de impor unicidade on-chain, isso pode opcionalmente ser imposto por filtragem como parte da agregação de metadados. Múltiplos serviços de agregação podem ser executados por diferentes organizações seguindo diferentes políticas sobre a filtragem de metadados da stakepool. Isso permite que os usuários de carteira e outros consumidores de metadados da stakepool escolham qual política seguir, se houver alguma.