The Proof of Stake (PoS) algorithm is a consensus protocol that proposes the validation of blocks through cryptocurrency holding tests, and thus a node is chosen to forge a block.
A Proof of Work (PoW) system requires the validating node, that is the miner, to perform work at a cost of time and energy consumption. The task consists of performing an algorithmic calculation, with different degrees of difficulty, to obtain the correct result.
The consensus algorithm used in Cardano is called Ouroboros, and it is a proprietary version of Cardano’s Proof of Stake (PoS).
The current implementation of Cardano is highly modular. It includes the following components (different implementation use cases will use different combinations of components):
- Command line interface (CLI)
- Daedalus wallet
- Cardano db-sync
- GraphQL API server (Apollo)
- SMASH server
This diagram describes the interaction between the components of the Cardano:
The Cardano Node is the top level component within the network. Network nodes connect to each other within the network layer, which is the driving force to fulfill information exchange requirements.
This includes re-broadcasting of blocks and transaction information to establish better data flow. Cardano nodes maintain connections to peers that have been chosen through a custom peer selection process. By running a Cardano node, you are participating and contributing to the network.
The Node is the network structure, and the stakepool is the network entity that runs the Node.
The main functions of a stakepool are:
- Forge new blocks
- Verify new blocks
- Confirm transactions
It can act individually, but it also receives delegation (staking) from third parties, users who own cryptocurrencies on the network, who choose it to do so. That staking is the amount of ADAs delegated to a stakepool. A slot leader is randomly selected to forge a block, and has a higher chance of being chosen the more ADAs staked it has.
Ouroboros divides Cardano time into slots (every second), blocks (every 20 seconds), epochs (every 5 days). The slot is the nomination space to sign a block. The slot leader (node chosen by the protocol) is responsible for adding a block to the chain. There can only be one slot leader per slot.
Each epoch includes 432,000 slots, (60 seconds x 60 minutes x 24 hours x 5 days). On average, the protocol design expects a block to be validated every 20 seconds, totaling 21,600 blocks per epoch (3 blocks per minute x 60 minutes x 24 hours x 5 days). It may happen that, due to various network issues (old versions of some node, or several disconnected nodes), fewer blocks result.
So you can see that the design foresees 20 slots per block. As many slots are created per block to ensure continuity in block production, since if a designated node is not available, another follows. Thus, competition between nodes occurs, and it is called a “slot battle” between validating nodes, and thus the chain naturally forks all the time. Those little forks are quickly resolved and are only a few blocks long.
The slot battle is resolved by the Verified Random Function (VRF), which is used, among other things, to find out if a stakepool was chosen as the slot leader for a particular slot, and the one with the lowest output value returned by the VRF is determined to be the winner of that slot. The stakepool that ‘loses’ the battle does not collect rewards.
So, to calculate the slot signature, the factors that are taken into account are the VRF key, the percentage of active staking (sigma), and a parameter called Nonce that is random, Number that can be Only used Once, and is one of the input values of the VRF.
For this function, the slot ID, the Nonce, and the VRF key to sign are taken as input values, generating a random value as output.
If the output value is less than a certain threshold, which is determined by the stake pool’s staking, then it is crowned the slot leader for that particular slot. As I said before, the higher the staking of a pool, the more likely it is to become a slot leader.
Once assigned as the slot leader, the stakepool signs the block using the Key Evolving Signature (KES) signature key, along with the output computed by the VRF.
Finally, this new block created by said stakepool is transmitted to other nodes in the network.
Since a stakepool needs to be checking every second if it is chosen slot leader, it becomes imperative that it is online 100% of the time.
The Nonce value used in the VRF is used as a seed value to generate a random number. It is created by hashing the outputs generated by the first ⅔ VRFs of the blocks from the previous epoch.
Although a stakepool is not forging blocks, it plays a role within the network by verifying blocks and confirming transactions. The process, when not selected as slot leader, is as follows:
- the stakepool uses the VRF to check if it is chosen as slot leader for each slot, and if it has not been,
- it receives a new block signed by a node, paired with theirs,
- the stakepool verifies the VRF proof of the block, using the VRF public key of the stake pool that signed it, and if it is valid, it is added to the local blockchain.
An interesting property of Ouroboros Praos is that each Stake Pool tries to discover with the VRF whether or not it is chosen as the slot leader. Although the leadership assignment calendar is known in advance, the stakepools will only know which other stakepools were chosen as slot leader, when the block is received and verified.
The blockchain has nodes as its main network component, and the proper functioning and synchronization between them is key to scalability, otherwise the network would become slower due to its greater latency in communication.
But also the number of nodes has an impact on decentralization. Imagine two unique nodes in a blockchain. Wouldn’t that network configuration be dangerously centralized? Since they can collude to act dishonestly, for example, by censoring transactions.
You can find the stakepools and their relays here. In the graph above I show you [SWAG] with 2 relays, Jeff’s stakepool, one of the 2 co-founders of AdaPulse, along with GenZod [ZOD].