Cardano Architecture (consensus networking etc)

The Cardano node is the main core. The figure below gives details on how Cardano Node interacts with other nodes and also clients like wallet backend

Nodes are responsible for:

• Executing the Ouroboros protocol
• Validating and relaying blocks

• Producing blocks (some nodes)

• Providing information about the state of the blockchain to other local clients

Communication protocols

The node-to-node protocol is a composite protocol, consisting of three ‘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.

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

Two types of data flow exist:

1. Mini protocols communicate with mini protocols of other nodes by sending and receiving messages across a public network (internet); this flow is not covered within the scheme above but will be potentially designed for better understanding.

2. Within a node, mini-protocols communicate with each other by reading from, and writing to, a shared mutable variable, which is represented by boxes in the scheme. Arrows indicate whether a thread has read or write access to the shared state.

Ouroboros Slots and Probablistic finality

In Ouroboros, the time is divided into Epoch. Each Epoch is 5 days. Each Epoch is divided into slots. Slots are 1 sec. Currently the protocol schdules block on avg 20sec. So there are 21600 blocks per epoch. Since the longest chain method is used, transactions have probabilistic finality.

Any application built on top of Cardano and synchronizing its behaviour with the chain must be prepared to occasionally observe such rollbacks

Rollbacks happen on the Cardano chain, or any other truly decentralised blockchain for that matter, because it is essentially asynchronous in nature, eg. each node has its own view of the state of chain which it updates by communicating with other nodes, exchanging messages about known blocks, and this process takes time. New blocks are produced, which may be valid or invalid, and the state of the chain is eventually consistent, all nodes agreeing on the state of the chain only after some number of blocks have been processed.

The immutable part is guaranteed to be identical on all nodes, being k blocks in the past from current tip (on the mainnet k is 2160).

What happens for the node's Direct Chain observer is detailed in the following picture:

When new blocks are available, the ChainSync client receives a RollForward message with each new block. When a fork happens, it will first receive a RollBackward message with a point, which identifies the slot and block hash at which point the chain has been rolled back (abstracted as a single number in the figure), then resume receiving new blocks through RollForward messages