In the Ouroboros Praos, the Proof-of-Stake consensus algorithm used by Cardano, it is possible for a Stake Pool's blocks to be orphaned.
Orphaned Block: A block that was created and then discarded by the nodes in the network under certain conditions. Blocks that are orphaned do not count towards a Stake Pool's performance and are not used when calculating Stake Pool's rewards.
Conditions for a Stake Pool's block to be orphaned by the network:
Slot Battle
Height Battle
Slot Battle
In our previous blog post, we mentioned that each Stake Pool verifies their slot leadership independently with their private VRF key as part of the Ouroboros Praos consensus algorithm. This implies that it is possible for two or more separate Stake Pools to become a slot leader for a specific slot.
How does the network decide which block to use to grow the blockchain if two or more blocks are valid for the single slot? This is the basis for a Slot Battle.
Figure 1 below illustrates how a Cardano node in the network handles these blocks.
When nodes receive two valid blocks for a single slot, the block with the lower VRF Proof value is chosen as the latest block and is propagated throughout the network. The other block becomes orphaned and unused. Slot Battles are unavoidable in Ouroboros Praos and the result of them is a matter of luck. However, Stake Pools with less active stake have an edge in winning slot battles because they are more likely to generate lower values of VRF_Proof over a larger competing pool.
Height Battle
Another way for blocks to be orphaned is through a race condition called a Height Battle. A block will be orphaned if the block is not propagated to the Stake Pool who's next to generate a block.
Figure 2 below shows how a block is orphaned by not propagating its block fast enough to the Stake Pool who is making the next block.
Even though the nodes in this network received X's block first, it is later orphaned because Y's block comes at a later slot, but has the same Block Number as X's. This is because Y did not receive X's block in time to increment the Block Number counter. X and Y both send the same block number throughout the network but at different slots. Nodes will choose the block with the higher slot number and orphan the other.
In order for a block to avoid being orphaned from a height battle, it is critical for the block to reach the next Stake Pool in time, before it generates the next block. Figure 3 illustrates how X is able to quickly propagate its block to Y, so it can send block n+1 after X's block.
To completely prevent blocks from being orphaned from Height Battles, it is important that the block gets propagated through the entire network within one second (1s), since the length of a slot on Cardano is 1s. That way, you can always ensure that the next block producer will have your block and build the network on top of it.
To propagate a block through the network quickly, you need a large enough diversity of peers whom are also connected to other peers. The current implementation of cardano-node does not support P2P at the time of writing this, so peers are manually added. It can also be detrimental to have too many peers, as it will slow down your node's processing ability to propagate the block due to management of too many peers. The current recommended amount of peers for a single node is 20 or less.
A helpful tool to watch network statistics to see block propagation times for Stake Pools and orphaned blocks is PoolTool.io.
References
[1] Ouroboros Praos, EuroCrypt 2018 https://eurocrypt.iacr.org/2018/Slides/Tuesday/TrackA/01-03.pdf
[2] Randomized Outcome of Slot Battles, GitHub, https://github.com/input-output-hk/jormungandr/issues/2156