Small stake pools do have an advantage

There has been much recent talk about decentralisation concerns with multi-pool operators. I thought I would weigh in by pointing out that small stake pools do have an advantage.

Small pools have a lower VRF score due to their lower controlled stake. Of course this means that they are less likely to be awarded blocks. However, it also means that when there are slot battles and single block forks, the small pool is more likely to win.

I am a small stake pool operator. I was awarded, and successfully minted, 3 blocks last epoch. Two of these 3 blocks resulted in a larger pool missing a block.

  • One was due to a slot battle which my pool won.
  • The second was due to a 1 block height fork. My block was produced only 1 second after the previous pools block and my pool hadn’t received the previous block in time. Therefore my block was minted with the same block number and conflicting transactions.

In both cases the competing pools had much larger controlled stake and my pool was awarded the win automatically by the protocol due to my lower VRF score.

See https://github.com/input-output-hk/ouroboros-network/issues/2913#issuecomment-816953407
For further explanation.

Now consider the following:

  1. If the minimum cost per epoch is reduced to something small or even 0
  2. If it becomes easy to do multi-pool delegation
  3. If block propagation times increase to closer to 5 seconds resulting in much more block conflicts
  4. If the public become educated about this small pool VRF calculation benefit

As a general Ada holder it would be smarter to delegate to multiple small pools if the fees are otherwise equal because:

  • The disadvantage of irregular rewards would be mitigated by multi-delegation
  • The lower VRF value for smaller pools would result in slightly increase rewards
  • It would be uneconomic for larger pools to compete on the VRF calculation by splitting their pools as they would become too numerous to manage

It is difficult for small pool operators, but maybe we need to think more along these lines. Maybe there is some way that we can increase our VRF advantage aside from points 1-4 I listed above.

For example, if blocks were every 15 seconds instead of every 20 this would result in more awarded slots but probably wouldn’t increase the overall throughput of the Cardano network much because there would be more dropped blocks due to more conflicts. However, it would increase the percentage of successful blocks by small pool operators since they would win the conflict battles much more often due to their lower VRF scores.

Anyway, it is a different line of thought instead of just complaining about multi-pool operators.

1 Like

But that would also be true, when raising k, lowering saturation. And there it was never accepted as a valid argument.

In fact, if you are a medium capable system administrator, you do that on an army of virtual machines and the cost of firing up additional pools will rather quickly approach the 500 ADA deposit and nothing else. Setting up the first stake pool is an adventure, setting up the 20th is a matter of minutes.

3 Likes

Yes, I agree it is easy to spin up multiple pools.

However one additional problem the multi-pool operators have is trying to manage their delegators so that they keep their pools under the saturation limits. This gets harder as they get more pools especially since they can’t directly contact the delegators with only their wallet addresses.

On that point, we need to have input into just how any proposed implementation of multi-pool delegation would work. We should seek to ensure this doesn’t provide an automatic levelling method for multi-pool operators.

If we have multi-pools like Binance, i.e., exchanges that directly control a huge stake, it is not hard to manage at all. For multi-pools that get delegations from the masses, it’s the same like now: Saturated pools have lower projected ROI, so they rank lower on stake pool comparison sites, so the delegators distribute themselves.

In a way, multi-pool delegation is already there: You can use the account feature of adalite.io, ccvault.io and typhonwallet.io to divide your wallet into accounts staked to different pools.

Another possibility would be to generate multiple stake keys in one account and generate receive and change addresses with them to divide the stake of one account/wallet into different pools. That is also already possible with the protocol as it is and “only” needs to be implemented by some wallet.

So, the “fairness” depends on the pool selection user interfaces of the wallet apps just like it does now. And there definitely seems to be room for improvement.

Wallet apps will probably also want to propose a distribution of stake that is beneficial to the wallet owner. And that most likely will also benefit automatic levelling for multi-pools. I’m losing rewards, when delegating to a saturated pool, so it is good for me if my wallet app proposes to move the stake over to the next non-saturated pool, regardless if we are speaking about different single pools or different sub-pools of a multi-pool.

I hadn’t realised but I understand how wallets can implement multiple staking now.

It wouldn’t be that easy to enable multiple staking for hardware token users though without requiring multiple passwords.