Hi everyone, just sharing a bit of my perspective with our community about the recent issues involving slot battles, i rise some questions and would like to hear your feedback! Thanks
I would like to put my perspective on the factors that involve pools in datacenter vs. home pools in slot battles. Let’s start by remembering some points that an operator has to observe when running a pool:
-Software / OS Stability / Security / Backup
-Stability and quality of the data network
- Power grid stability
- Infrastructure / Maintenance cost
With these 4 points we can start our pool in an attempt to achieve high availability. The simplest objective here is to run a service where you have a satisfied user (and this definition of satisfied is definitely not a single item).
From the pools we have:
-Pools that run in data centers, this puts at the operators’ fingertips the convenience and stability of an infrastructure to run a service with a superior SLA.
-Pools that run on top of an infrastructure that the operator already has, in this case the operator is mostly re-using their infrastructure to run the service or purchasing one, this is also a nice way to avoid abrupt disruptions in the network in case of a massive database shutdown.
Without a doubt, the best option for the network would be a Type 2, but it does not fit for any operator or pool size.
Imagine the following, concern of a Type 2 pool operator in which he is taking out of his pocket to approach a datacenter level, improving his fiber, hardware parts, requiring an investment perspective in the expectation of a future return that he does not have date to occur, depending on the growth of the project and its pool.
Just to be clear here that at some point it is nice to have this combination of type 1 and type 2 to build a mix of benefits, but it will cost more.
What I want to emphasize here is, there is a group of operators who felt comfortable with this movement and the possibility of someone hitting a pole and breaking its fiber. On the other side we have operators who are in no condition to run a service in your locality or even the capital for that. In this case, what happens in my region.
Thinking about stability in the electric grid in my region is a long-term dream. Here there are many trees in a windy region close to the beach, any change in the weather throws the branches over the wires and the maintenance of this is far from ideal.
To run something locally you would need a battery bank, which is not very cheap here. The last time I was without light was two weeks ago, it lasted about 30 hours with a peak of instabilities and even burned some kitchen appliances.
My sister, who lives in Kansas when I asked her, had to think hard and concluded that she was never affected in the last 2 years
Electronic equipment here is becoming increasingly inaccessible, the tax on technology and services borders on the supernatural, something around 60% (now adds up to the 85% drop in the real in the last 24 months), finding a data center with a good price , quality and that is not in the hands of giants is an arduous task. On average the hosting services here cost 4x more and rising.
Each operator lives a different reality.
And it was because of these different realities that I decided to write this article. I’m an operator that uses data centers for the node, at the moment, it is still complicated to bring a stake operation where I live, a lot because of the infrastructure and the size of the stakepool.
Bringing the node to my region is something I definitely want to try, but like all operators I want to be able to deliver good service stability.
The question is, if you are a small stakepool in a place with no density of pools, if you can’t afford to fail, this is a guarantee of bad statistics, it will certainly hinder the growth of your pool and in parallel an attempt to further decentralize the node.
For smaller pools the race is to not lose money on the short-term operation and provide a good service. The pool needs to gain a good size so that you can make some changes, my conclusion here is that even without a good distribution of stake between the pools it is more difficult to decentralize!
Perhaps this part is controversial, as to what size of stakepool does not matter when trying to run a Type 2 in remote places! Perhaps this is the case for operators that have a node in first world countries where the probability of being surrounded by other nodes is much greater, has a great network, cheap components and can even have a reasonable latency to Europe. In those cases I can even imagine the guy who set up a raspberry threw it in the basement and slammed the door.
Slot battles and operator battles
I believe that the community may have already seen the problem of the slot battle being debated on several channels.
What happens here is that we have a physical limit on the internet today, and the rule is simple, with longer paths the longer the time for information to come and go.
I don’t even want to talk about the sadness that is the latency of my network, the number of points and routes connecting the USA and the EU to Brazil are significant, these routes with preference for delivering different packages, finding the best route or the best service is not an easy task. And here the highlight is, the physical limit still exists, no matter if I find the fastest route in my location.
But after all, what is the error, what is happening with such slots? What’s the problem?
The problem is that we do not have an implementation at the network, nor a consensus layer that can alleviate the problem of distance, this hinders the moment of deciding the winner of a slot battle.
This provides incentives for operators to behave in a certain way, everyone wants to be perfect when the factor is not determined by luck.
The operator seeks to position the node in a region that has a better connection with the largest possible number of nodes, causing the centralization of the nodes.
But is this the same thing as centralizing block production?
No, each stakeholder guarantees decentralization because they are autonomous. Here it is precisely the power of a network that is proof of stake, if an operator’s operation is closed somewhere, in a few seconds it will be running in a new place.
Decentralization is our community and our operators, infrastructure can end up centralizing, it does not affect the fundamentals.
Don’t get me wrong, it’s not THAT bad, centralization of stake would be worse, these are simple facts.
Just confirming, this is not a problem in the protocol, it is more a problem in the node, a network problem.
Solutions can be implemented on the network side as well as on the protocol side, but it is not interesting to change the protocol, since a solution can be reached via network layer management at the moment.
One of the solutions that would not change the protocol would be a dynamic adjustment to encourage nodes to operate from places with low node density.
At the moment I can’t get a clear idea of how this functionality should behave in a dense low-latency environment, but it could be a great option on the node for isolated operators over long distances.
The battle between small pools in remote regions and large pools intensifies here, if we have large pools dominating the production of slots in dense regions, this further tithes the likelihood of pools winning these battles at a distance.
The battle of slots, which should balance the return on staking, is now dominated by pools that have a high production of blocks, where the loss in performance is almost imperceptible compared to a smaller pool in the same situation.
Smaller pools that could perform better and become more attractive are at a disadvantage, and perhaps this is at the heart of the problem in a stake distribution in the future, making it difficult to spread the stake with a larger K.
In fact, testnet was largely more damaging to smaller pools, the problem with multiple block submission by larger pools was devastating for those who had their few blocks thrown out of the chain.
The search for perfectionism in our community of stakeholder operators is a reflection of the ideals on which cardano is based, not least that situations of this type are expected to cause questions of conduct that can be exacerbated, even by the interpretation of our community. Visibly Type 2 operators are unhappy about investing in a fixed location, but honestly I believe they should consider a mix in this case. Many large operators have 2 or more pools, leave 1 in one place and one in another.
My call here is more for a calm down in how we are treating each other, because for a brief moment all Type 1 operators were put in the same bag, along with those who moved their machines to gain the benefit. If the guy was in that region from the beginning now it doesn’t make a difference anymore, and the same for Type 2 operators who want to improve but are small and are experiencing difficulties.
If the protocol has a loophole so that the node configuration may open up an advantage, it will be discovered and explored; unless we identify them, disclose them, and commit to resolving them as part of our long term strategy on how to reach the common vision.
Is our network prone to centralization?
No, our consensus protocol can assure that.
Yes, as long as the incentive remains.
This is bad?
Yes, our community always has to look for improvements, Ouroboros chronos may have some answers.
And here’s an extra, we often see operators forming groups to test one thing or another.
What if our community formed groups or guilds, which support specific factors of the network?
One of them could be decentralization. How many of your delegates support dealing with a drop in performance in defense of infrastructure decentralization?
This group of community members could promote this, it would be interesting to see this active side of the community in an organized way.
That’s it folks, thanks for taking the time to try to understand my perspective on the problem and the community.
So what do you think? Should it aim for geographic diversity, or geographic consolidation is not that big of a deal in your opinion as long as the control is also not centralized? What would it take for you to move your node back to your home country, or delegate to a geographically dislocated pool?
Thanks for all those that are patient and help the others.