Explora Cardano:  2. Arquitectura: a. Resumen de la arquitectura de Cardano

Esta sección describe la arquitectura de alto nivel de Cardano. Proporciona detalles sobre los componentes principales y sus interacciones, y discute brevemente las eras e implementaciones de Cardano.

 

Arquitectura de alto nivel de Cardano

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

 

Componentes del sistema

La implementación actual de Cardano es altamente modular. Incluye los siguientes componentes (los diferentes casos de uso utilizarán diferentes combinaciones de componentes):

 

Nodos y nodos remotos

Un sistema blockchain consiste en un conjunto de nodos distribuidos en una red que se comunican entre sí para lograr un consenso sobre el estado del sistema.

Los nodos se encargan de:

  • Ejecución del protocolo Ouroboros
  • Validación y retransmisión de bloques
  • Producción de bloques (algunos nodos)
  • Proporcionar información sobre el estado de la blockchain a otros clientes locales

Sólo puedes confiar en los nodos ejecutados por ti o por tu organización. Por eso Daedalus ejecuta un nodo en segundo plano.

 

El proceso nodo

El cardano-node es el nivel superior del nodo y está formado por los demás subsistemas, de los cuales los más significativos son el consenso, el libro mayor y la red con la configuración auxiliar, la CLI, el registro y la supervisión.

 

Node-to-Node IPC protocol

El propósito del node-to-node Inter-Process Communication (IPC) protocol es permitir el intercambio de bloques y transacciones entre nodos como parte del algoritmo de consenso Ouroboros.

The node-to-node protocol es un protocolo compuesto, que consta de tres "mini-protocolos”:

  • chain-sync: Se utiliza para seguir la cadena y obtener las cabeceras de los bloques.
  • block-fetch: Se utiliza para obtener cuerpos de bloque.
  • tx-submission: Se utiliza para las transmisiones de transacciones.

Estos miniprotocolos se multiplexan en una única conexión TCP (Transmission Control Protocol) de larga duración entre nodos. Pueden ejecutarse en ambas direcciones en la misma conexión TCP para permitir configuraciones peer-to-peer (P2P).

El protocolo general -y cada miniprotocolo- está diseñado para un entorno sin confianza en el que ambas partes necesitan protegerse de los ataques de denegación de servicio (DoS). Por ejemplo, cada miniprotocolo utiliza un flujo de control dirigido por el consumidor, de modo que un nodo sólo solicita más trabajo cuando está preparado, en lugar de que se le imponga trabajo.

El diseño del protocolo es modular y evolutivo: la negociación de la versión se utiliza para acordar el conjunto de miniprotocolos a utilizar, lo que permite añadir miniprotocolos adicionales o actualizados con el tiempo sin causar problemas de compatibilidad.

 

Node-to-Client IPC

El propósito del node-to-client IPC protocol es permitir que las aplicaciones locales interactúen con la blockchain a través del nodo. Esto incluye aplicaciones como backends de monederos o exploradores de blockchain. El protocolo de nodo a cliente permite a estas aplicaciones acceder a los datos brutos de la cadena y consultar el estado actual del libro mayor. También ofrece la posibilidad de enviar nuevas transacciones al sistema.

El protocolo de nodo a cliente utiliza el mismo diseño que el protocolo de nodo a nodo, pero con un conjunto diferente de miniprotocolos, y utilizando rutas locales en lugar de conexiones TCP. Como tal, es una interfaz estrecha de nivel relativamente bajo que expone sólo lo que el nodo puede proporcionar de forma nativa. Por ejemplo, el nodo proporciona acceso a todos los datos brutos de la cadena, pero no proporciona una forma de consultar los datos de la cadena. El trabajo de proporcionar servicios de datos y APIs de nivel superior más convenientes se delega a clientes dedicados, como cardano-db-sync y el backend del monedero.

El protocolo de nodo a cliente consta de tres miniprotocolos:

  • chain-sync: Se utiliza para seguir la cadena y obtener bloques
  • local-tx-submission: Se utiliza para presentar las transacciones
  • local-state-query: Se utiliza para consultar el estado del libro mayor

La versión de nodo a cliente de chain sync utiliza bloques completos, en lugar de sólo cabeceras de bloque. Por eso no se necesita un protocolo de obtención de bloques separado. El protocolo de local-tx-submission es como el protocolo tx-submission de nodo a nodo pero más simple, y devuelve los detalles de los fallos de validación de las transacciones. El protocolo de local-state query proporciona acceso al estado actual del libro mayor, que contiene muchos datos interesantes que no se reflejan directamente en la cadena.

 Lee más sobre el diseño del protocolo de red y los protocolos de comunicación de los nodos de Cardano.

 

Command line interface (CLI)

La herramienta CLI del nodo es la "navaja suiza" del sistema. Puede hacer casi todo, pero tiene un nivel bastante bajo y no es muy conveniente porque está basada en texto y carece de una interfaz gráfica de usuario (GUI).

La herramienta CLI puede:

  • Consultar el nodo para obtener información
  • Entregar transacciones
  • Construir y firmar transacciones
  • Gestionar las claves criptográficas

 

Monedero Daedalus

Daedalus es un monedero de nodo completo que ayuda a los usuarios a gestionar su ada, y puede enviar y recibir pagos en la blockchain de Cardano. Daedalus consiste en un frontend de cartera y un backend. El frontend es la aplicación gráfica que los usuarios ven y con la que interactúan. El backend es un proceso de servicio que monitoriza el estado del monedero del usuario y hace todo el "trabajo pesado", como la selección de monedas, la construcción de transacciones y el envío. El backend interactúa con un nodo local a través del protocolo IPC de nodo a cliente, e interactúa con el frontend a través de una API HTTP. El backend también proporciona una CLI que permite la interacción con el monedero. El backend del monedero también puede utilizarse por sí mismo -sin Daedalus- a través de su API. Esta es una forma conveniente para que los desarrolladores de software integren Cardano con otras aplicaciones y sistemas.

Aconsejamos que los usuarios más avanzados que quieran utilizar Cardano comiencen con Daedalus.

 

cardano-db-sync

El nodo cardano sólo almacena la propia blockchain y la información asociada necesaria para validar la cadena de bloques. Este principio de diseño consiste en minimizar la complejidad del código y reducir el coste computacional y el uso de los recursos, para mantener las interfaces locales del nodo lo más reducidas posible y utilizar clientes externos para proporcionar una variedad de interfaces convenientes y funcionalidades adicionales. En particular, el nodo no proporciona una interfaz de consulta conveniente para la información histórica en el blockchain. Este servicio de datos lo proporciona un componente independiente que utiliza una base de datos Structured Query Language (SQL).

Lee más sobre:

 

Sobre las épocas y las implementaciones de Cardano

Cardano es un libro mayor distribuido de tercera generación. Se basa en Ouroboros, un algoritmo de consenso de blockchain de prueba de participación (PoS) revisado por pares que apareció por primera vez en la principal conferencia de investigación en criptología del mundo (the International Association for Cryptologic Research 37th International Cryptology CXonference - Crypto 2017).

El nombre Cardano es el nombre general dado a la plataforma, que ha pasado por múltiples épocas e implementaciones. Estos conceptos necesitan más explicación.

 

Épocas

Existen varias épocas dentro de la evolución de Cardano. Cada era (Byron, Shelley, Goguen, Basho y Voltaire) se refiere a las reglas del libro mayor. Por ejemplo, qué tipos de transacciones y qué datos se almacenan en el libro mayor, o la validez y el significado de las transacciones.

La evolución de la red principal de Cardano comenzó con las reglas del ledger Byron (era Byron). La red principal se sometió a una bifurcación dura a finales de julio de 2020 para cambiar las reglas de Byron por las reglas del libro mayor de Shelley. Por lo tanto, este hard fork marcó el comienzo de la era Shelley.

 

Implementaciones

La primera implementación de Cardano se introdujo al inicio de la mainnet de Cardano, allá por septiembre de 2017. Esta implementación soportaba exclusivamente las reglas del ledger Byron.

A continuación, emprendimos una reimplementación completa de Cardano, lo que permitió dos cambios fundamentales: la compatibilidad con múltiples conjuntos de reglas del libro mayor y la gestión del proceso de bifurcación dura para pasar de un conjunto de reglas al siguiente. En otras palabras, la nueva implementación puede soportar tanto las reglas de Byron como las de Shelley, lo que significó que, cuando se desplegó en la red principal a principios de 2020, la implementación también era totalmente compatible con las reglas de Byron. Esto permitió una transición suave de la antigua a la nueva implementación. Una vez que todos los usuarios de Cardano actualizaron sus nodos a la nueva implementación, fue posible invocar el hard fork y cambiar a las reglas Shelley.

Se utilizó una tercera implementación de Cardano en la Shelley Incentivized Testnet (ITN). Este sistema soportaba un subconjunto significativo de las reglas de Shelley, y lo utilizamos para probar la dinámica económica y social del sistema de delegación de Shelley.

Esta visión general de la arquitectura de Cardano refleja la implementación actual de Cardano desplegada en la red principal, no las implementaciones originales o ITN.

 

 

Encuentra una copia oficial de este documento aquí:

https://docs.cardano.org/explore-cardano/cardano-architecture/overview

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