Increased number of Orphaned blocks

You were just unlucky, nothing you can do against slot battles. The propagation delays matter when you are involved in a height battle. For example, if another pool is scheduled to produce a block 1-2 seconds later, it may not receive your block in time. In this case, your block will be ignored and their block will be accepted even if the slots are different. The red bars tell you how many nodes received your block (Y axis) within a given delay (X axis). If the first red bar is far away on the X axis, it means you are not telling your neighbors fast enough about the blocks. If the longest red bars are far away from the first red bars, it means it’s probably not your fault but the network has issues propagating blocks.

1 Like

I think @orpheus-ant does know this but for the benefit of others:

When another pool produces its block without seeing the previous block first, then this results in a fork. 2 block are produced, by different stake pools, for different slots, but with the same block number, and both blocks will contain duplicate transactions. Only one of the forks can be accepted by the consensus mechanism. These single block forks are also currently resolved by comparing the VRF score with the lowest VRF winning.

For more information see: Consensus should favor expected slot height to ward off delay attack · Issue #2913 · input-output-hk/ouroboros-network · GitHub

1 Like