Admittedly, this GitHub issue will be controversial, but it’s very important, and it's not a joke, nor a publicity stunt. This is a product issue, as in “Product Management”. It is also a technical issue, as technology will likely play some part in its solution. And lastly, it’s a governance issue. All of that makes it a bloody mess, and hence, controversial. The above issue was written in the language of Scrum — something that IOHK reportedly practices in their ongoing effort to become more agile as time goes on (a good thing, but a difficult thing). This issue will be abstract by design, more as an invitation to engage in thoughtful dialog, so that we can hear some of the best ideas for solving it. I am just starting the dialog in a formal manner, after hearing a fair amount of chatter on one of the stake pool channels, and thinking about it plenty on my own prior to that. I do not have all — or perhaps even any — of the answers. That is up to the collective “us.”
To start the dialog, let’s pick this user story apart, piece by piece...
First, the persona: as a Small Pool Operator. We should all be striving to be small pool operators. (There’s that word, “should”... let the holy war begin!) Currently, we live in a world where “the strong survive” and “the powerful rule”. This is capitalism. I’ve believed in it for a long time. Probably many of you have as well. It is a great outlet for pursuing our dreams, and it has some great elements.
Yet after the financial crises of recent years (and even before those), it became clear that the system is utterly broken. It doesn’t work well for the majority of us. Hence, the advent of crypto currencies and blockchain technologies. Many of you probably believe in these opinions, otherwise, you probably wouldn’t have gone through the trials and tribulations of being involved in this testnet. It takes real work to be involved in this effort, and yes, many of us believe there will be rewards if we put in this work. But any of you that have worked at a startup company know that those rewards are far from guaranteed.
So back to the persona...
Why should we be striving to be small pool operators? Small is relative, but the simple answer is that if we allow large pool operators, we will be right back in the same financial system that we came from. If you’re the lucky one who becomes the biggest of all pool operators, then you may very well leave the table with everything, when it’s all said and done. And in that scenario, everything will be said and done relatively quickly. AND, you’ll have nobody to party with because everyone else will be poor! How fun is that?
Even IOHK, CF, and Emurgo should want to be small pool operators (from their current position of being large pool operators). Why? They’ve basically said so, many times over. If they become small pool operators, they win, because they’ve achieved the decentralization that they have so often espoused. Decentralization means that nobody is too large, including the folks that built the system. But they already know that...
So how do we make sure that everyone is a small pool operator, that gets to the second portion of the above user story: “I would like to have incentives baked into a Cardano Constitution (and the Ouroboros protocol)...” Remember the part about this being a product; technical, and governance problem? That’s what this portion of the user story is speaking to. We need some form of constitution, so that we can all adhere to it as our primary mission statement as holders of, and believers in, the Cardano ecosystem and community. The constitution needs to be governed by all of us, and it needs to be enforced by the technology of the Ouroboros protocol.
One suggestion to help being a small pool operator remain a viable thing is to require a minimum fee for all pool operators. Is this anti-capitalism? The alternative is that the small fish get eaten by the big fish, who subsequently get consumed by the even bigger fish. Soon, there’s only one humongous fish, floppin’ around by her lonesome on the beach, in glee because she won the game. Or did she?
So what does that minimum fee look like, and what is the mechanism that adjusts it, but never allows it to disappear, so that huge players, such as giant centralized exchanges, can’t come in and offer “free staking” and and drive everyone else out of the game? In a world of transferred costs and cash-back incentives, at the very least, a required minimum fee provides transparency into any loss-leader strategy that might be devised by the ultra greedy. I’d rather be just a tiny bit greedy, because I think I’ll have a lot more fun and there will be far less to worry about in life. Perhaps many of you are similar? If so, what are some thoughts on this minimum required fee, and the adjustment mechanism that must go with it? A 2% margin that you can’t undercut? 2% of the available rewards per block, calculated based upon the total available incentive pool that the Cardano Treasury has set aside for a given year? Something else? These are but a few off-the-cuff examples, and I’m quite certain that someone out there has better ideas than me.
This brings us to the third portion of the user story — why do you want all of the aforementioned crap? To protect your investment, that’s why. To protect your investment in your children, that’s why. To protect your investment, in your grandchildren; parents; significant other; best friend; favorite cause; etc, etc. That’s why. You’ve invested money; time, and energy into this project in one way or another. Some of you may want to make a quick buck (...er, ADA) and then skeedaddle (a highly technical term). I suspect that’s a minority, because Cardano just ain’t that kind of project. If you’re here now, you’re probably here due to mettle, constitution, and perseverance. You’ve done the research. It speaks to you. And now there’s a snag. What will you do? Hopefully join the conversation and solve this problem! You have the power and the capability. Use it... or lose it!
(Btw, thank you to some of the folks that have stuck their necks out to make the testnet difficult, and really test it. Without them, we may never have corrected some of the problems that we’ve already corrected, or we may never have found those problems until it was too late. I've been just as frustrated as the rest of you with the early network instability, but for every difficulty encountered, there is hidden goodness. Let's recognize that.)
Thank you for reading... but please do more than just read. Note that Ouroboros has many of these elements built in, but we're learning that it hasn't considered everything just yet. We need to help improve it through shared ideas that will yield solutions.
For thoroughness, here are the acceptance criteria for this story:
Acceptance Criteria:
1.) An incentive scheme by which small pool operators will be able to thrive without giving up in frustration because some large player uses a loss-leader strategy to undercut and price-out the small pool operators.
2.) A mechanism by which the incentive scheme can be mutated to fit the changing times, but never eliminated through the force of larger players. Q: should this be only via governance, or should a technological element be present to enforce various aspects of the mechanism?
3.) A focus on the technical issues that are hurting the smaller pool operators the most (eg: killing their performance, through no fault of their own... eg: vaporizing blocks).
4.) Modification of the k factor to reduce saturation thresholds so that stake is spread out over the many pools that exist, not concentrated on the few.
Without motivating all pool operators, the majority will drop out and we'll end up centralized, just like every other project out there. We're better than that! If there are other, fairly major acceptance criteria that are missing, please add them (go for the core essence, not hair-splitting detail).
Without going into right/wrong/why on some of what you've said, not sure if github is the right place for scrum talks
"One suggestion to help being a small pool operator remain a viable thing is to require a minimum fee for all pool operators" - so what exactly does a small pool that hasn't produced any blocks in an epoch need to do to qualify for your minimum fee/reward? That was not made clear in your suggestion...
I am totally with this.
Only early PO or whales really had a chance at this. Once, by power of ADA, by rep, by PRs or simply by luck, but once you become an operator of a big pool, you are set and the algorithm will keep assigning blocks to you; and it becomes practically impossible for the little guy to get in the game ... no matter how stable or in sync his/her node is or how much resources in terms of money/time he/she dedicates to the pool. At the same time, you see the IOHK pools standing there in the corner with several hundreds millions of ADA each …
If we are striving for decentralization the protocol must incentivize the existence of a large number of reasonably sized pools. And if this is the case, which I think is clear for everyone including those running the big pools, this change should occur as soon as possible, because we want to test the ITN with real world conditions, Ain't we?
I believe that we should consider the increase of the k factor as soon as possible to at least 500 (equiv to 0.2% saturation); because otherwise there is absolutely no incentive for small pools to be spending time and resources in a game that, under these conditions, becomes unplayable
Can you please provide your understanding as to what does 'increase k to 500' actually achieve as far as rewards go, citing whitepaper/design documents?
Perhaps this conversation should be with the Cardano Foundation first, not the developers writing the specs? Maybe open an issue here https://github.com/cardano-foundation/incentivized-testnet-stakepool-registry/issues
"One suggestion to help being a small pool operator remain a viable thing is to require a minimum fee for all pool operators" - so what exactly does a small pool that hasn't produced any blocks in an epoch need to do to qualify for your minimum fee/reward? That was not made clear in your suggestion...
@hodlonaut, thanks for the comment. I wasn’t suggesting that small pool operators get freebies for doing nothing. They absolutely need to produce blocks, just like any pool operator that wants to earn rewards and participate in the protocol. And as mentioned, small is a relative term.
I consider small to be someone running a pool with anywhere between 1 and say 30M ADA. You might have a different concrete definition of small. But those are just arbitrary numbers. Concept is more important.
A large pool would be a player like a Binance or a Coinbase, and we could just allow them to run two giant stake pools, and the protocol would probably run fine for a very long time. (IOHK can even continue to do its awesome scientific research and development activities in that scenario.) Is that what we all want? I’m sure they would do a great job, and the pools would be very efficient, with the best IT infrastructure, and they would charge zero fees for staking. Great for you as a staker, right? If you really wanted to, you could then “compete” and run a pool with zero fees to try to attract stakers away from the two mega-whales. But why spend the money, time and effort running a pool where you will actually have to lose something (eg: time, money, and/or effort) in order to continue running that pool. Letting those two mega-whales run the whole show is far easier, and you can still earn great rewards for assigning your stake to them. Sounds simple and a win-win, yes? Or perhaps, no? What are you giving up in that scenario? Do you want to give that up? How about the next pool operator? Does he or she want to give that up? Why did it bother so many pool operators on Telegram the other day that someone was running a pool that had 0 fees and zero margins, and was describing a somewhat non-committal attitude to running that pool if they got busy with something else? Why were pool operators so concerned when one operator put in a Pull Request to open 26 additional pools, for a total of 35, under the control of a single operator?
This story (partially technical, so it’s in the technical backlog on GitHub) is about building that elusive stuff that you would otherwise give up in the scenario above. There were heated conversations about this topic on Telegram, just two days ago. I’ve simply opened an item in the technical backlog so we can take action, as a community, instead of just talking about it and getting busy with our next little technical task.
(@hodlonaut, I chose to reply to your comment first as a platform to clarify some things that may not have been clear in my original feature request, and the motivations for why I made that request. Thank you for asking your question, as this is how dialogs commence. I’m not trying to be a troll; be inappropriate; or be a jerk. In fact, I was quite anxious and nervous when I first hit the submit button after writing it. That said, these are hard questions and will require community involvement to resolve, unless we just want to let “them” figure it out... whoever “them” is. It’s all rather uncomfortable, but that often means it’s important.)
Folks, I'm listening and considering what to do with this one. Waiting for a couple of private conversations to complete. For now, I will refrain from adding any more to this. May close it and/or move it to a different forum. Not interested in disrupting developer workflow; lecturing anyone; being a pest, PITA, etc. We're all busy, I recognize that. This seemed like a topic that people cared about, that needed to turn from talk into action. Just trying to facilitate that and not be a hidden opinion. That said, there is a balance to strike in attempting to help, while also being a good citizen. On hold for now...
I totally agree with you. I agree with you because our goal is decentralization. Eventually many capitalists will kill small pools. Then small pools think that a new concept of delegation is needed. We will study for small pools.
Do not let them leave ...
Folks, I was completely misinformed about all of this, mostly through my own lack of time to research the many good information sources that IOHK, etc has made available to the community. For starters, please see:
https://iohk.io/en/blog/posts/2018/10/23/stake-pools-in-cardano/
and
https://www.adaizen.com/a-sobering-reality
and
https://forum.cardano.org/t/a-sobering-reality-for-cardano-stake-pool-operators-owners/22848
and
https://iohk.io/en/blog/posts/2018/10/29/preventing-sybil-attacks/
Huge thank's to Priyank, who spent much of his own time in a very good private conversation with me to enlighten me about what has already been done on the research front. Many in our community need to take the time to read and understand how staking works to a sufficient level of detail so that the entire community gets stronger.
With each day that passes, I am more and more impressed with the work that IOHK has already done on the research and development side, and I was already impressed and a big believer. If anyone needs help understanding, please send me a note. Helping you understand will be my way of paying it forward.
The staking mechanism has certain design principles that it was trying to achieve, and I now think it's largely done that job, including looking after the little guy and addressing much of the acceptance criteria in this user story. I have more work to do myself, including diving into several of the academic papers at some point when my overextended schedule allows, and I also encourage others to do the same. Apologies to those who have spent any amount of time on this. It was my intention to help make things stronger, which is why I am closing this issue.
Most helpful comment
Without going into right/wrong/why on some of what you've said, not sure if github is the right place for scrum talks