From 30fe3bc82ed6e7c375615c64d91d290d24fbca9f Mon Sep 17 00:00:00 2001 From: olgahryniuk <67585499+olgahryniuk@users.noreply.github.com> Date: Wed, 3 Apr 2024 14:45:16 +0300 Subject: [PATCH] Update 03-cardano-architecture.mdx --- .../03-cardano-architecture.mdx | 90 +++++++++---------- 1 file changed, 42 insertions(+), 48 deletions(-) diff --git a/docs/04-explore-cardano/03-cardano-architecture.mdx b/docs/04-explore-cardano/03-cardano-architecture.mdx index bbd9f816..638b4ff4 100644 --- a/docs/04-explore-cardano/03-cardano-architecture.mdx +++ b/docs/04-explore-cardano/03-cardano-architecture.mdx @@ -6,69 +6,64 @@ metaTitle: Cardano architecture This section describes the high-level architecture of Cardano, providing details on the core components and their interactions. -### High level architecture of Cardano - The following diagram outlines the interaction between the system components of Cardano: ![cardano_components](https://ucarecdn.com/3756645a-a4a2-4d2f-846a-e454bf7cba60/) -### System components +## System components The _current_ implementation of Cardano is highly modular. It includes the following components (different deployment use cases will use different combinations of components): - [Node](https://github.com/input-output-hk/cardano-node) -- [Command line interface (CLI)](https://github.com/input-output-hk/cardano-node-wiki/blob/main/docs/reference/cardano-node-cli-reference.md) -- [Daedalus wallet](https://github.com/input-output-hk/cardano-wallet) +- [Command line interface (CLI)](https://github.com/IntersectMBO/cardano-cli) +- [Cardano wallet](https://github.com/input-output-hk/cardano-wallet) - [Cardano db-sync](https://github.com/input-output-hk/cardano-db-sync) - [GraphQL](https://github.com/input-output-hk/cardano-graphql) API server (Apollo) -- [SMASH server](https://github.com/input-output-hk/smash) +- [SMASH server](https://github.com/IntersectMBO/cardano-db-sync/tree/master/cardano-smash-server) -### Nodes and remote nodes +## Nodes and remote nodes A blockchain system consists of a set of nodes distributed across a network that -communicate with each other to achieve [consensus](https://docs.cardano.org/learn/consensus-explained) about the system’s state. +communicate with each other to achieve [consensus](/learn/consensus-explained) about the system’s state. Nodes are responsible for: - Executing the - [Ouroboros](https://github.com/input-output-hk/ouroboros-network/#ouroboros-network) + [Ouroboros](https://github.com/IntersectMBO/ouroboros-network?tab=readme-ov-file#ouroboros-network) protocol - Validating and relaying blocks - Producing blocks (some nodes) -- Providing information about the state of the blockchain to other local clients - -You can only trust nodes run by you or your organization. This is why [Daedalus](https://docs.cardano.org/cardano-components/daedalus-wallet) -runs a node in the background. +- Providing information about the state of the blockchain to other local clients. -#### Node process +### Node process -The cardano-node is the top level for the node and consists of the other -subsystems, of which the most significant are consensus, -[ledger](https://github.com/input-output-hk/cardano-ledger-specs#cardano-ledger) -and networking with ancillary configuration, CLI, logging, and monitoring. +The `cardano-node` is the top level Cardano component that consists of the other +subsystems, of which the most significant are [consensus](https://github.com/IntersectMBO/ouroboros-consensus?tab=readme-ov-file#ouroboros-consensus), +[ledger](https://github.com/IntersectMBO/cardano-ledger?tab=readme-ov-file#cardano-ledger) +and [networking](https://github.com/IntersectMBO/ouroboros-network?tab=readme-ov-file#ouroboros-network) with ancillary configuration, CLI, logging, and monitoring. -#### Node-to-Node IPC protocol +### Node-to-node IPC protocol The purpose of the node-to-node Inter-Process Communication (IPC) protocol is to allow for the exchange of blocks and transactions between nodes as part of the Ouroboros consensus algorithm. The node-to-node protocol is a composite protocol, consisting of three -‘mini-protocols’: +mini-protocols: -- **chain-sync**: Used for following the chain and getting block headers. -- **block-fetch**: Used for getting block bodies. -- **tx-submission**: Used for forwarding transactions. +- **chain-sync**: used for following the chain and getting block headers +- **block-fetch**: used for getting block bodies +- **tx-submission**: used for forwarding transactions. These mini-protocols are multiplexed on a single long-running Transmission Control Protocol (TCP) connection between nodes. They can be run in _both_ directions on the same TCP connection to allow for peer-to-peer (P2P) settings. -The overall protocol -and each mini-protocol- is designed for a trustless +The overall protocol – and each mini-protocol – is designed for a trustless setting where both sides need to guard against Denial-of-Service (DoS) attacks. For example, each mini-protocol uses consumer-driven control flow, so a node only requests more work when it is ready, rather than having work _pushed_ upon @@ -78,7 +73,7 @@ The protocol design is modular and evolvable: version negotiation is used to agree on the set of mini-protocols to use, which allows additional or updated mini-protocols to be added over time without causing compatibility issues. -#### Node-to-Client IPC +### Node-to-client IPC The purpose of the node-to-client IPC protocol is to allow local applications to interact with the blockchain via the node. This includes applications such as @@ -87,7 +82,7 @@ these applications to access the raw chain data and to query the current ledger state. It also provides the ability to submit new transactions to the system. The node-to-client protocol uses the same design as the node-to-node protocol, -but with a different set of mini-protocols, and using local pipes rather than +but with a different set of mini-protocols, and local pipes rather than TCP connections. As such, it is a relatively low-level narrow interface that exposes only what the node can provide natively. For example, the node provides access to all the raw chain data but does not provide a way to query data on the @@ -97,9 +92,9 @@ backend. The node-to-client protocol consists of three mini-protocols: -- **chain-sync**: Used for following the chain and getting blocks -- **local-tx-submission**: Used for submitting transactions -- **local-state-query**: Used for querying the ledger state +- **chain-sync**: used for following the chain and getting blocks +- **local-tx-submission**: used for submitting transactions +- **local-state-query**: used for querying the ledger state. The node-to-client version of chain sync uses _full_ blocks, rather than just block headers. This is why no separate block-fetch protocol is needed. The @@ -109,9 +104,13 @@ local state query protocol provides query access to the current ledger state, which contains a lot of interesting data that is _not_ directly reflected on the chain itself. -[Read more about the networking protocol design and Cardano node communication protocols.](/explore-cardano/cardano-network/networking-protocol) +:::info + +Read more about the [networking protocol design here](/explore-cardano/cardano-network/networking-protocol). -### Command line interface (CLI) +::: + +## Command line interface (CLI) The node’s CLI tool is the 'swiss army knife' of the system. It can do almost everything, but it is quite low level and not very convenient because it’s @@ -119,12 +118,12 @@ text-based and lacks a graphical user interface (GUI). The CLI tool can: -- Query the node for information -- Submit transactions -- Build and sign transactions -- Manage cryptographic keys +- query the node for information +- submit transactions +- build and sign transactions +- manage cryptographic keys. -### Daedalus wallet +## Daedalus wallet Daedalus is a full node wallet that helps users to manage their ada, and can send and receive payments on the Cardano blockchain. Daedalus consists of a @@ -135,24 +134,19 @@ selection, transaction construction, and submission. The backend interacts with a local node via the node-to-client IPC protocol, and interacts with the frontend via a HTTP API. The backend also provides a CLI that enables interaction with the wallet. The wallet backend can also be used on its own --without Daedalus- via its API. This is a convenient way for software developers + – without Daedalus – via its API. This is a convenient way for software developers to integrate Cardano with other applications and systems. -We advise that most advanced users intending to use Cardano start with Daedalus. - -### cardano-db-sync +## Cardano DB Sync -The cardano node stores only the blockchain itself and associated information -needed to validate the blockchain. This design principle is about minimising -code complexity, and reducing computational cost and resource use, to keep the +The cardano node stores only the blockchain itself and the associated information +needed to validate the blockchain. This design principle is about minimizing +code complexity (and reducing computational cost and resource use) to keep the node's local interfaces as minimal as possible and to use external clients to provide a variety of convenient interfaces and extra functionality. In particular, the node does not provide a convenient query interface for historical information on the blockchain. This data service is provided by a -separate component using an Structured Query Language (SQL) database. - -Read more about: +separate component using a Structured Query Language (SQL) database. -+ [Cardano DB Sync and its components](https://docs.cardano.org/cardano-components/cardano-db-sync/about-db-sync/) -+ [SMASH](https://docs.cardano.org/cardano-components/smash) +Learn more about [Cardano DB Sync here](https://github.com/IntersectMBO/cardano-db-sync?tab=readme-ov-file#cardano-db-sync).