Understanding the Cardano Consensus

Each Cardano node maintains its own version of the ledger. To be able to do this, a node needs connections with other nodes and the ability to decide whether to accept new blocks. Come and see how new blocks are appended at the end of the ledger and how the immutability of the ledger is protected.

Why does Cardano need a consensus mechanism?

Every distributed blockchain network needs a consensus mechanism to ensure that all honest nodes maintain the same version of the ledger. Each node behaves autonomously and there must be no central authority in the network that would decide which version of the ledger is the right one. It can be said that authority is replaced by rules. Participants accept the rules by installing clients on their own nodes.

So, a consensus mechanism is a set of rules and processes that allow the nodes to coordinate and cooperate with each other, without relying on a central authority. It also provides security and reliability for the network, as it prevents malicious actors from tampering with the ledger or creating fraudulent transactions.

If most participants have the same Cardano client version installed, they accept exactly the same rules. The rules are complete and deterministic, thus everyone maintains the same version of the ledger.

Fraudulent participants try to change the rules on their nodes. Then, they try to deceive honest participants. However, if the majority of ADA coins are on the side of honest participants, their rules are followed.

Note that the propagation of blocks in a distributed network tends to be delayed, so at one point in time, the ledger version may differ slightly but only the last few blocks. However, the ledger history is the same on all nodes.

Consensus rules are transparent, as their definition is freely available to everyone in the source code on GitHub.

Understanding layers

Each Cardano node maintains its own version of the ledger according to the consensus rules defined in the Cardano client. We will show what the consensus depends on and where exactly the ledger is located.

You can think of Cardano as 3 layers where the higher layer depends on the lower one.

The figure below shows that the consensus layer depends on the network layer. The ledger layer depends on the consensus layer. In this way, the functionality of the individual layers is separated. They can thus be upgraded independently of each other.

The network layer maintains peer-to-peer connections between all distributed nodes in the Cardano network. Each node is connected to several neighboring nodes. This layer serves for the distribution of transactions and blocks over the Internet.

For greater security, the Cardano network uses two types of nodes: Relay nodes and nodes that maintain the ledger, let's call them consensus nodes (also block-producer nodes). Consensus nodes are connected to one or more relay nodes. An attacker cannot get to the consensus node through the relay node if the operator correctly sets up the connection between the relay and the consensus node.

The consensus layer is where the Ouroboros PoS consensus runs. In this layer, incoming blocks are validated and a decision is made on their acceptance. In the event of a fork, the winning chain is selected. If it is a block-producer node, a new block is minted here. In this layer, nodes maintain the local state needed for decision-making. For example, a list of active pools, a list of active delegation certificates, an active stake of all pools, etc.

The ledger layer maintains the state of the ledger and regularly updates it every time a new block is accepted.

The consensus layer does not need to know the state of the ledger (for example, an active UTxO set). The PoS consensus only needs to verify some fields from the block header for its operation. A newly received block is either accepted, in which case it can update the ledger state, or rejected.

Ledger

The Cardano ledger consists of a series of blocks that are linked by hashes. Hashes are unique identifiers that represent the content of each block. We'll talk more about that later. Let's first look at what the block looks like.

Each block contains a header and a body. The header contains metadata such as the slot number, the epoch number, the protocol version, the block producer ID, and the hash of the previous block. The body contains the actual transactions and other information that affect the ledger state.

If a Cardano node accepts a new block through PoS consensus, the body of the block updates the ledger state. You can think of this as adding a new block to the end of the blockchain, essentially accepting all the transactions contained in it as well. In the following text, we will focus on the immutability of the ledger.

We said above that blocks are linked through hashes. A hash is a unique and fixed-length identifier that is derived from the data of a block using a cryptographic (mathematical) function. The entire block, i.e. the header and body, is used as input for a cryptographic function that produces a unique 256-bit output. The hash function used by Cardano is called Blake2b.

The way hashing works is that if you take the same input and apply it to the same cryptographic function, it will always produce the same output. If you were to change even a single bit of information on the input (in the block), the output of the function would be completely different.

The hash of the previous block is an important part of the block header, as it ensures the integrity and continuity of the blockchain. With each new block added to the blockchain, it becomes more difficult to change the history of the ledger, i.e. the previous blocks, including their contents.

By including the hash of the previous block in the header of the current block, Cardano creates a chain of blocks that can be traced back to the Genesis block, which is the first block ever created on the network.

Cardano PoS consensus verifies the data in the block header that the node received. The node must decide whether to accept the block. One of the fields in the block header that the consensus verifies is the hash of the previous block.

Consensus must ensure the integrity and continuity of the blockchain. Consensus cannot accept a block if it would mean breaking continuity. This would happen, for example, if the hash of the previous block referred to a non-existent or too-old block.

Newly minted blocks have a sequence number (block number) and slot ID in which they were minted. It is very easy for the node performing the verification to decide (based on the consensus rules) whether the continuity and integrity of the ledger will be preserved by accepting the block.

In the image below you can see the time divided into slots. New blocks were minted exactly after 20 seconds in slots with IDs 1000, 1020, 1040, and 1060. You can see 4 blocks that only contain some fields in the block header. The green arrows show the slot IDs, that is, the slots in which the slot leaders minted new blocks. The slot leaders have assigned block numbers 15, 16, 17, and 18 to the blocks. The red arrows show the links between the blocks, i.e. the hash of the previous block.

It is not possible to remove, for example, a block with Block number 16 from the ledger, as this would disrupt continuity. The block with Block number 17 must point to the block whose hash is indicated by the letter Q (Q is the hash of the block with Block number 16) in the image and to no other.

The hash of a block depends not only on its own data but also on the hash of the previous block. Therefore, if an attacker changes any data in a block from history, the hash of that block will change, and so must be changed the hash of the next block, and so on. This would create a fork in the blockchain, where the attacker’s version of the block will not be accepted by the rest of the network.

This situation is indicated in the next picture. The attacker changed the body of the block with Block number 16. However, by doing so, he also changed the hash of the block, which now has the value X. The attacker must therefore also change the blocks with Block numbers 17 and 18. A fork was created on his node. An attacker can try to distribute the fraudulent chain in the network to other nodes. However, other nodes reject the fraudulent chain after validating the other fields from the block header.

Next, we will show how the network can deal with forks.

Consensus

Blockchain forks in the Cardano network occur for a variety of common reasons, not just when an attack is attempted. In our article, we described in detail how new blocks are minted and verified. You will also learn more about the local state that nodes maintain for the verification of blocks. Now we will focus on how Cardano can deal with forks.

First, however, we need to say something about the finality of blocks.

Cardano uses Nakamoto-style Proof-of-Stake consensus. A Nakamoto consensus is able to achieve a so-called probabilistic finality. Probabilistic finality means that under some assumptions about the participants in the network, we can only estimate the probability of the finality of blocks. This applies not only to the most recently added block but also to previous blocks.

For the last block, the certainty regarding the finality is the least (so rather uncertainty). The older the block, the greater the certainty that the block is final.

Reaching the eventual consensus means that at some point in the future, all nodes will agree on the immutability of a certain set of blocks. Reaching the eventual consensus may take a long time. Moreover, it is not possible to determine how long it will take ahead of time.

While the newly minted block can be accepted by all nodes in the network (if it passes verification), another pool (block producer) decides whether the block is final. The finality of the last block is not voted on by normal nodes, but only by a randomly selected block-producer node. This node reinforces the finality of the last block by deciding to attach its own block after that block.

Each additional block added is one more vote on the finality of all previous blocks.

In the image below we see 5 blocks. Each block was created by a different slot leader (block producer). Block 1 is most likely to be final (however, we still do not have absolute certainty), as 4 slot leaders voted for it and no fork has yet occurred. On the contrary, we have the least certainty with block 6. There is still a chance that a fork will occur after block 5. No one other than the block producer has voted on Block 6 yet.

Forks in the Cardano network occur for a variety of reasons. In one slot, 2 slot leaders could be elected who both independently minted a new block (they don't know about each other). It can happen that two slot leaders are elected in slots that are close to each other. The second slot leader did not have to receive a block from the previous leader and therefore did not follow the last block, but the previous block. This creates a fork.

In the image below, you can see how the blockchain fork occurred in the Cardano network after block 5. In slot 1058, the slot leader Alice was elected, and in slot 1060, the slot leader Bob was elected. Alice minted a new block 6 after block 5. The slot leader Bob was elected later and because he did not receive block 6 from Alice in time, he attached a new block also after block 5. So there were 2 blocks with block number 6.

As we explained earlier, consensus rules must be complete and deterministic. The protocol anticipates the emergence of this situation and can easily deal with it. The protocol will use the following chain selection rules.

1. The longest chain rule.
2. If both alternative chains have the same number of blocks, the chain with the lower VRF output in the last block is preferred.

The block header contains several fields that the nodes verify. The consensus layer verifies, among other things, VRF proof and VRF output to verify that the node was actually elected as slot leader and had the right to mint the block. Furthermore, the KES signature is verified.

In the image below you can see a similar scenario as above. We added the VRF output and names of slot leaders. Alice minted block 6 in slot 1058, and her VRF output is 39578. Bob mined block 6 later, in slot 1060, and his VRF output is 28887. They both attached block 6 after block 5, thus creating a fork.

The finality of both blocks 6 is low and very uncertain, as only one can remain in the blockchain while the other will be orphaned. In the picture, you can see another slot leader Carol, who minted a block in slot 1080. For her, the task was simple, as she applied the second rule for choosing a chain.

Bob's block had a lower VRF output, so Carol chose his block. Alice's block will remain orphaned including all transactions. The consensus decision is reflected in the ledger layer.

A fork can also occur when trying to push a fraudulent chain. An attacker could try to change the contents of a block deep in the history of the ledger or discard part of the blocks completely.

It is important to note that although it may be easy for an attacker to create a fraudulent chain locally on his node, it is essentially impossible to enforce a fraudulent chain to other nodes in the network.

Slot leaders are elected based on the total stake of pools, i.e. based on the distribution of ADA coins. Only elected slot leaders are able to insert a valid VRF proof, and VRF output into the block header and sign the block with a signing KES key.

As for enforcing a fraudulent chain, it is essentially an attempt to commit a 51% attack. For this, the attacker needs more than half the amount of coins used for staking. An attacker may not directly own all the ADA coins needed for an attack but can abuse delegated coins.

Conclusion

Consensus is essentially just a set of rules that decide the ledger state. The Key-Evolving Signature (KES) scheme and Verifiable Random Function (VRF) cryptography are used to vote on slot leaders and protect the ledger from overwriting. It was not explicitly mentioned in the article, but the KES keys used to sign blocks are regularly deleted, which is another significant obstacle for an attacker to attempt to overwrite the history of the Cardano ledger.

Each node behaves autonomously and maintains its own ledger versions and local state. It therefore knows how the stake gradually changed, knows all slot leaders, can verify block signatures, and knows the current (local) state. The attacker fights against all this.