Info
Content

What are slot battles?

Introduction

Slot battles occur when a slot has been assigned to be processed by more than one pool at a particular allotted time during the course of an epoch. In this answer, we want to provide a more in-depth discussion of the context and consequence of the occurrence of slot battles.

Many of the themes found below are drawn across many resources from both the Telegram groups and Cardano docs and we hope to be able to credit all the themes to the correct original author's original publication.

Context and background information

If you are new to the process of how a blockchain works we recommend that you read the Cardano Foundation's GitHub article on "Producing New Blocks". In that article important ideas are issued including:

Slot Battles: a feature or anomaly of the Cardano network design?

From the outset, we need to understand that slot battles are a feature of the Cardano network protocol and not some anomalous error that has been inadvertently created whilst designing the protocol.

The Cardano network protocol has been designed to thwart the potential of DDOS (Distributed Denial Of Service) attacks. To that end, the engineering of the protocol meant that each network pool (also called "validator" in other blockchains) that gets assigned a schedule to process or validate blocks does so independently of the knowledge of any other pool's block processing schedule. A pool's schedule - also called a "leader log" - is a timestamped event where a pool is responsible for the processing of one of the slots (or blocks) to be added to the blockchain. Slots occur every second. On average a slot gets filled by a block every twenty seconds under the Cardano network protocol.

The allocation of leaders to produce blocks in slots for each pool that qualifies to process or validate blocks is determined via a lottery event using the Ouroboros Praos Proof-of-Stake VRF function.

The slot leader schedule is determined by each block producing node running its own local private lottery for each slot, and when it wins the lottery it can prove to everyone else that it did so legitimately and fairly and so it is indeed allowed to produce a block in this slot.

- Daniel Coutts in "Why does Ouroboros Praos introduce slot leader sets? - Reddit"

Each pool that qualifies to process blocks on the network has to have a valid operational node certificate and they need the Ouroboros VRF key pair to control the participation in the slot leader selection process.

A VRF key pair (or Verifiable Random Function Key Pair) is a cryptographic function that processes inputs and produces verifiable pseudorandom output. (A discussion of the VRF functions is beyond the scope of this answer for now.)

For further information on this crucially important function for the Cardano blockchain please check out these resources:
- Generating Randomness In Blockchain: Verifiable Random Function
- Boston University's Verifiable Random Functions (VRFs) Paper
- Ouroboros Verifiable Random Function

For an excellent discussion on why Ouroboros Praos introduces slot battles click here to read a great discussion on Reddit.

The lottery event in conjunction with the VRF keys creates a potential universe of assignable slots to any pool as a function of the amount of ADA staked and pledged to that pool.

It occurs with some frequency that one pool may have a slot assigned to them that coincides with another pool's schedule of slots. However, the results of the lottery event, to assign the number of blocks any pool may accrue, and the schedule thereof, is done in such a way that a pool is ignorant of any other pool's slot schedule. Pools schedules overlap on the fringes. It is those overlapped schedules that result in two pools getting themselves involved in a "slot battle".

See also this discussion on how often slot battles may occur on Telegram:

FROM:

If it's a multi leader slot battle it's 50/50 roughly on the outcome but chances of even being involved in one such battle are on the low side, maybe 5%

The way slot battles resolve

Prior to the launch of the Shelley Mainnet, during the Incentivised TestNet, the resolution of slot battles was determined either by how fast the pool's node propagated its block onto the network or by which pool had the lowest VRF result. However, the speed by which a pool propagated its block to other nodes on the network had the undesired effect of having the network conglomerated around high-speed network centres in the world (during the ITN one of those centres being Germany). So, in the end, the protocol chose to exercise priority (but not exclusivity - see below) to the pool that had the lowest VRF hash result to process and validate a block.

Subsequent to the launch of the MainNet a pool involved in slot battles would have a measure of their VRF hash made and the lower one would usually win. Pools that have a higher amount of ADA pledged and staked would often have a higher VRF hash whereas pools that had a lower amount of ADA staked or pledged would reveal a lower VFR hash.

A discussion on Telegram gives a more plain version of the process of the slot battle:

Forwarded from Luis Restrepo
... if you have the correct vrf loaded, bp node will try to produce all slots according to schedule. As long as the block doesn't align with BFT overlay schedule that is. If slot happens to align with BFT, node will report slot as not leader. In the case of slot battle both community pools will make the block and start propagating it through the network. Lets say node A create a block for slot X. And node B also create a block for slot X. Node C receives block from node A first and all that have a connection to node C pulls this block from node A. But then block from node B arrive at node C, and node B happen to have a lower VRF output for this slot than node A. Node C will then switch and put block from node B on tip instead. Its not that complicated but hard to express in a good way in words. Depending on how fast the blocks from each node in a slot battle propagate and who has the lowest VRF, they will spread differently before they are "killed off". Pooltool has a node listening for these blocks but if the loosing block is killed off before reaching pooltool node it will never end up in the orphaned table on pooltool. This is why you see some but not all orphaned blocks, depending on how fast you manage to get your block to pooltool node.

Also, on the subject of which pool is the victor in a slot battle:

FROM:

I've lost some pretty low-stake slot battles, the smaller pool is the "favorite" for them but is not the guaranteed victor

Lower VRF hash of a pool wins the battle most often

To understand why a pool with a smaller staked and pledged amount of ADA wins a slot battle more often than not over a pool that has a higher stake or pledge of ADA we can run an analogy. Imagine a dice with 100 sides. Each side represents the possibility of minting a block. The two pools in a slot battle run the dice to see who gets the privilege of minting the block. However, the bigger pool, which has been granted, for example, the privilege of minting 20 blocks has then a roll of the dice where it always lands on a number between 1 and 20. The competing smaller pool has, for example, been granted 3 blocks to mint during the epoch. This pool then gets the dice where it always falls only between 1 and 3. Since the likelihood that the bigger pool will most likely fall on a number bigger than 3 then the smaller pool is a favourite to win the slot battle.

FROM:

Basically, big pool has to roll a 20 or lower on a d100 to get a slot so their value may be between 1-20, whereas a small pool has to roll a 3 or lower to get a slot so their value may be between 1-3, there's always a chance that the smaller pool rolls a 3 and the big pool rolls a 1 or 2, but the odds favor the small pool if both rolled the same slot

 

Last word

This answer was written up in response to allay the fears that delegators of a pool who suffered a loss of a slot battle may feel their pool is not operating at its most optimal. It may seem counterintuitive that a superbly performing or large pool can lose a slot battle to a lesser pronounced or smaller pool out there. But the protocol allows for this to happen and it is not necessarily related to the actual performance of the physical pool node or operator running that node!

If the reader has made it to this portion of the answer then they will realize that the result of a slot battle is less about how fast a pool propagates its block on the network, server network latencies, and other physical metrics of a pool. The success of battle has more to do with cryptographic functions and the amount of ADA a pool operates on the network (that is, the pool with less stake being the favourite to win a slot battle).

Cardano to the moon!

 

Useful Resources:

Technical Authority: Duncan Coutts - IOHK Team: https://iohk.io/en/team/duncan-coutts

Published on 17th February 2021
by Jorge Pasocal - [BRUN] Stake Pool

 

https://cutt.ly/tk9jOyR
No Comments
Back to top