these days I hear lots of voices talking about the problem of multiple stake pools operated under one single brand.
I’d like to describe the problem by comparing the SPO market with the capitalistic markets in our world as those countries are facing the same issue: The richer you are, the easier it is to get richer, the poorer you are the harder it gets to get rich; If you’re born without privileges the harder it gets for you. This leads to monopolies which is the opposite of decentralization.
You can easily adapt this to the current situation in the Cardano SPO network: There is a small number of saturated pools minting the majority of the blocks directing people over to their new pools. The large number of small pools trying hard to get delegations are not profitable.
This problem was thought about from early on and this IOG blog post describes quite well the theoretical incentive of not splitting up your pledge for running multiple pools, but in practice it still is financially attractive to set up a second pool if your first pool is already saturated. In fact, this is even promoted by adapools.org as you can direct people to your other pools in case of saturation.
I know IOG is aware of this problem, but I think mitigating this problem will probably not be as simple as changing one protocol parameter, neither will this problem be solved in the next few weeks as there are other priorities, I suppose.
Though, we SPOs have quite some power and I’d like to discuss a possible way to mitigate the problem:
From time to time, every SPO requests the api.clio.one API (probably most of them by using the guild-operators’ topologyUpdater script) for maintaining a list of healthy peers. What if we set up a banlist of peers belonging to multipool operators so those IPs won’t make it into the topology.json. Of course, it needs to be treated very carefully, must be open source and can only be changed with at least n approvals on GitHub. This enables us to exclude egoistic operators towards a more decentralized network.
Thank you for bringing this up! This is indeed a severe problem. But banning/excluding participants is not right. This is an open network - everybody is entitled to participate. Currently those “egoistic” pool farmers do not violate any rules - it’s by design: a “flaw” in the system.
From my point of view we need a significant change in the Blockchain’s parameters/rewards formula. I’m sure IOG put some brain power on this already. I hope the modification can be achieved on the community vote via Catalyst.
The network should be open to everyone. Everyone is entitled to participate. By design, there is a flaw in the system. I agree on all those points!
I am not saying I want to exclude participants (as people), but I am saying excluding participants (as pools) that are clearly just another business branch of the same person. The person operating 5 pools can of course keep at least one of them.
Yes, there are currently no such rules designed by IOG and built into the system at the moment, but that doesn’t mean we can not create rules on the level we are empowered to do. I fully agree it should be fixed on a protocol level, but I also think it’ll take quite some time to get there. I am not sure if this can even be solved on the protocol level, but I am happy to be proven wrong! Still, why not fix the issue ourselves on the highest level until it gets fixed on a lower level.
This is not excluding people, its defining rules as a group of SPOs for our little sub-community within the network and enforcing them. Rules that should be common sense and beneficial to the network.
As a side note: The topology updater is just a temporary tool and so would be a banlist. Once P2P arrives on the node the problem needs to be solved in a different way already.
I think the issue with using an ID structure is that there would be no way to tell association if the pool operators wanted it that way. I guess it would still make it more difficult to hold onto delegators who needed to rotate out, but not impossible. There is something else needed here.
