[JIP] Randomize the outcome of slot battles

[onyxstakepool]

Problem description Slot battles have a higher probability to be won when pools are geographically close together and thus there is low latency block propagation. Optimizing towards a high win rate has led to a concentration of the pools in Europe. This geographical concentration runs counter to the decentralization idea.

Proposed solution To randomize the outcome of a slot battle, select the block with the highest hash as a winner. This strategy decouples the block selection in a slot battle from the time of arrival of a block at a node and thus does not provide an advantage for nodes close together with low latency connections.

Additional improvements To prevent pool operators from mining the best block hash, the slot battles could also be decided by the random numbers generated by the vrf key in the slot assignment process. These numbers cannot be mined or manipulated. The block with the lowest number, derived form the vrf key, wins. Then the block hash comparison is only needed as a tie breaker in the case when the vrf numbers are the same for two blocks.

Network stability By introducing a network wide consistent block selection in the case of a slot battle the probability of a fork is significantly reduced and thus the network stability is improved.

Adversarial forks The special case of an adversarial fork can also be covered by using the block hash as a selection criterion. The hash has to be used as a tie breaker since the threshold values derived from the vrf key are the same by definition. This strategy also reduces the probability for a fork and thus improves network stability in the presence of many adversarial forks.

Impact on the consensus protocol Due to the fact that the branch selection based on the threshold value favors a specific resolution of a fork that would also have been present in a latency bases scheme the effect of the randomization is an improvement of network stability. The randomization thus does not impact the underlying consensus protocol.

Rollout Due to the fact that the randomization strategy only changes the probabilities of the selection of a specific candidate chain in the presence of a fork the modifications can be rolled out without a hard fork.

[nnorg]

+1. I would agree that it is natural for slot battles to occur but that a consistent advantage to a particular set of node characteristics is a negative.

[rickymac68]

I agree with this JIP. After analyzing pooltool slot battles by node location and % wins it is obvious that nodes will end up centralizing in northern Gerrman, NLBE, France, London, and Finland. The more remotely connected areas - Singapore, Japan, Korea, Island Nations, South America, and Africa will lose too many slot battles over time and become less desirable to stakers. The problem is not just a matter of latency, but having a large number of nodes located close to each other in the same geographic region, along with those nodes having a reasonable stake and being slot leaders.

Description of the slot battle problem is in this video https://www.youtube.com/watch?v=1r4z59hE-Es

[CryptoBlocks-pro]

This is true... I started out in Japan, and after winning 1 out of 9 battles, started looking into and noticed the better win statistics in Europe, so moved my pool there for the express purpose of winning more slot battles. There is financial incentive to win battles, so pressure to concentrate in winning areas, again counter to decentralization. I feel guilty for doing it, but to attract more delegators, I have to perform well.

[syndeton]

Thanks for starting this conversation. Agree 100% with all of the above. Losing too many slot battles has really set back my small stake-pool which doesn't get a lot of slot assignments each epoch. My overriding concern as an operator now ... which could be misplaced ... is how to increase my slot battle win rate. I recently moved from US to Europe and started winning some. If Cardano becomes as big as envisioned, could one see develop a low-latency arms race among large stake-pools perhaps similar to that seen with high frequency trading? Or does this incentivize pool operators to provide more for the ecosystem than just minting blocks and maybe offset lost rewards due to slot battles. Would be very interesting to hear if Coutts et al. have any data on some of this especially what they determined regarding how slot battles affect incentives for stake-pool operators.

[onyxstakepool]

Thanks for all the comments!

I have updated the original proposal with a method to prevent pool operators from mining the best block hash.

[AndrewWestberg]

I just wanted to leave my voice here saying that this is a pretty widespread issue. I created JorManager which a good chunk of the network is currently running. As such, I get to chat with a good number of operators via DM on Telegram to help get them set up, answer their questions, etc. A good percentage of operators have moved their pools to try and mitigate the slot battle losses.

[stanfieldr]

Perhaps it could go to the pool with the lowest stake since they would be most negatively effected by the outcome, could kill two birds with one stone that way... Or maybe a combo of the two ideas like x% luck, y% stake.

Scenario 1: Pool A 100m, Pool B 5m very high y%, low x% involved in determining outcome Scenario 2: Pool A 20m, Pool B 5m less about y% and more about x% in determining outcome, Scenario 3: Pool A 20m, Pool B 20m all about x% chance, no y% factored in outcome

I'm not good with math, but you get the idea... If they are relatively close in delegation size, then leave it up to chance.... but if it's a saturated pool vs the little guy, then maybe the little guy should have it to promote more pools

[onyxstakepool]

Perhaps it could go to the pool with the lowest stake since they would be most negatively effected by the outcome, could kill two birds with one stone that way... Or maybe a combo of the two ideas like x% luck, y% stake.

Yes, this is actually possible by using the threshold value that is computed from the vrf key to prove that the pool is actually allowed to mint the slot.

This threshold value must be smaller than a number that is proportional to the stake. Thus smaller pools are getting a higher probability to win the slot battle. (Assuming the smallest threshold wins the battle.)

[ghost]

Taking latency out of the equation for slot battles is a great idea. I would like to see a mathematical approach within the protocol to eliminating the geographic centralization of pools due to latency, thereby re-decentralizing the network.

[onyxstakepool]

@NicolasDP : I have added some additional thoughts to the original proposal. Please review.

[dcoutts]

Interesting idea, but if you use the block hash value then you open up a new range of opportunities for grinding attacks (i.e. using hashing power).

[onyxstakepool]

Interesting idea, but if you use the block hash value then you open up a new range of opportunities for grinding attacks (i.e. using hashing power).

@dcoutts : Yes, you are right. Taking the hash only is not sufficient, but as I have outlined in the additional improvements section, this problem can be mitigated by using the threshold value computed form the vrf key in the slot selection algorithm as the primary means for the block selection and use the block hash only as a tie breaker in special situations like adversarial forks.

[michaeljfazio]

Interesting idea, but if you use the block hash value then you open up a new range of opportunities for grinding attacks (i.e. using hashing power).

Could you just take a hash of the block height instead? Or is that too naive an approach to protect against grinding attacks?

[onyxstakepool]

Could you just take a hash of the block height instead? Or is that too naive an approach to protect against grinding attacks?

The block height will be the same for all blocks competing for a slot. So this is not a differentiation we can use as selection criterion or tie bracker for the block selection.

Using the threshold value for block selection and the block hash as on optional tie breaker is already sufficient as a slot randomization criterion.

[michaeljfazio]

Could you just take a hash of the block height instead? Or is that too naive an approach to protect against grinding attacks?

The block height will be the same for all blocks competing for a slot. So this is not a differentiation we can use as selection criterion or tie bracker for the block selection.

Using the threshold value for block selection and the block hash as on optional tie breaker is already sufficient as a slot randomization criterion.

Sorry I wasn’t very clear. I was proposing that for each slot battle the randomisation function could take a hash of the block height and compare it to a hash of each pool ID. Then select the “closest” match of the two for the default chain to follow. As the block height is effectively just an incrementing counter which all nodes can agree upon, then it may provide a suitable seed that cannot be manipulated in the same way that a block hash could (by including transactions which result in a desired hash).

[onyxstakepool]

Could you just take a hash of the block height instead? Or is that too naive an approach to protect against grinding attacks?

The block height will be the same for all blocks competing for a slot. So this is not a differentiation we can use as selection criterion or tie bracker for the block selection. Using the threshold value for block selection and the block hash as on optional tie breaker is already sufficient as a slot randomization criterion.

Sorry I wasn’t very clear. I was proposing that for each slot battle the randomisation function could take a hash of the block height and compare it to a hash of each pool ID. Then select the “closest” match of the two for the default chain to follow. As the block height is effectively just an incrementing counter which all nodes can agree upon, then it may provide a suitable seed that cannot be manipulated in the same way that a block hash could (by including transactions which result in a desired hash).

Yes, your scheme could also work. The key observation is that we need a random number that cannot be manipulated by the pool operators. The threshold value has this property and it is readily available for every block. There is no additional computation required except for the comparison operation of the candidate blocks.