I agree with @Terminada and @intutionismRus here and I oppose raising k. I’ve outlined my thoughts about it here on X albeit with crappy MSPaint graphics. Please read the whole thread.
4 Likes
I am not opposed to raising K. But, I am interested in thinking about the incentive problem more widely and what tools Cardano has to combat the forces to centralise. I am frustrated that CF hobbled one of the community’s tools (social pressure), which admittedly was a somewhat weak tool, but nevertheless it did previously have some teeth and might have gotten stronger through awareness with the release of the Edinburgh decentralisation index research paper. Hopefully this paper will highlight the problem all blockchains face and educate the community about why we need decentralisation, how to measure it, and what tools we have to manage it.
This brings me back to the social pressure “tool”. All this education relies upon people talking about the problem, educating others and then using SOCIAL PRESSURE to influence how various multi-pool operators behave, as well as how their delegators behave.
The K parameter provided a clear and simple metric, or signpost. Basically if the pool operator had more stake than 1/K of total stake then he could only achieve this by being a multi-pool operator. Furthermore, it is possible for the community to work out which operators were multi-pool operators through monitoring and highlighting any that didn’t publicly disclose this fact over time. And, dishonesty can have long term consequences on reputation, so most multi-pool operators do elect to publicly disclose the fact.
I find this entire debate particularly frustrating when you consider that Cardano’s proof-of-stake design relies significantly upon community engagement. We don’t use slashing to punish pools. Our protocol is based upon the premise that delegators will point their staking keys at the pools they prefer. And, that they will re-point their staking keys if a pool operator does something detrimental to reduce the value of the Cardano financial operating system.
Decentralisation is a big factor in calculating Cardano’s value. It was a very simple narrative, when educating users about how to select a stake pool, to prefer single pool operators. Now what do we tell new users? Maybe a multi-pool operator with only 2 or 3 pools is OK??? But that would depend on the size of each pool. So maybe we should get new delegators to manually add up all the stake each multi-pool operator has delegated in order to make some sort of assessment??? Maybe we should ask for some new tools, such as graphs, to highlight which pools are hurting decentralisation??? @ccgarant and @Nicholas_Gilbert are doing a great job with their Balance stake pool metrics page. Maybe wallets need to calculate such things rather than simply preferentially ordering single pool operators???
Unfortunately, the clear narrative that multi-pool operation hurts decentralisation by undermining the design purpose of the K parameter, is now weakened.
5 Likes
Always was …
2 Likes
Not according to good reasons outlined by the Cardano design architects: https://iohk.io/en/blog/posts/2020/11/13/the-general-perspective-on-staking-in-cardano/
4 Likes
I think multi-pool operators are generally okay except for two particular cases:
-MPOs with a small ratio of pledge to stake.
-MPOs in the MAV.
This was addressed in the above link by IOG as well:
Be wary of ‘pool splitters’ - Pool operators that run multiple pools with small pledge hurt delegators and smaller operators
However, changing k doesn’t really seem to solve either of these. I think it’s worth taking a look at what the primary purpose of k is and whether or not it is effective in its task.
4 Likes
I disagree with the premise that raising I will “only” allow/promote a few/small number of SPOs. I think it would allow a rebalance of stake and potentially distribute it to already established SPOs. I say potentially as it may also just result in delegators running to the next spun up pool by their favourite SPO (mpo or single), but it also has a positive potential. All of this is from a change or movement of delegation point of view.
From a network point of view I am limited in my knowledge of the impacts from a technical perspective, but as the original parameter committee mentioned, they would tweak one parameter at a time and see what happens. The system didn’t break with a change in minFee (it was expected to), and as noted above, k = 1000 is a reasonable next step, I am in favour of it.
I also assume the k = 1000 fits within the parameters guardrails that are being developed, so it is reasonable to make this change.
1 Like
Let me share my opinion on the matter, and propose an alternative:
Why exactly does, if k needs to change, it need to be a doubling to 1000? I would propose changing it to 750.
It’s a nice middle road and first step:
- saturation point will be around 52m. This change is not so impactful for currently saturated pools, and it makes splitting a pool less attractive since your not losing that much.
- there’s the issue of dormant stake. lowering saturation to 52m will make active delegators move, but dormant stakers might not be impacted (that much)
- active delegators will be incentivised to rethink their pool, and might redistribute stake towards the edges and increase decentralisation.
Changing k=750 IMO seems to tick all the boxes for supporters of the change, while downplaying the possible impacts the people against the change warn for.
I welcome comments from both sides on the change to 750.
5 Likes
Happy to re-iterate my arguments why I voted “NONE” in the SPO parameter poll last year.
Yes, increasing k will force delegators to move, but I strongly believe this will not help decentralization, it also brings the risk with it to decrease quality of operations.
Increasing k will just lead to the majority of the currently about 270 pools close to saturation to split, I will split, I have a business behind this by now. Not all pools splitting will allocate the same resources to the new block producer as the old one, double the cost, but might want to keep costs the same, so the performance per block producer will overall most likely go down, diminishing network performance.
Decreasing minStaticFee from 340 to 170 ADA didn’t really help decentralization either, as I expected. This change only strengthened the race to zero and leads to even more badly managed pools due to cost cutting, hurting the network.
As we know, block reward has been decreasing, current block reward is about 500 ADA.
Let us assume a small pool just starting out minting one block per epoch. The SPO is forced to take 170 ADA of that 500 ADA, so with the minStaticFee alone the pool will be very unattractive to delegators as the effective cost is still about 35% which is still very high and unattractive to delegators. At the same time it halved the only income small pools have, breaking even more pools IMHO.
Replacing the minStaticFee with a minVariableFee of e.g. 5% however will finally result in an even playing field for small and large pools alike. If you mint one block the fee is 5%, if you mint 50 blocks the fee is 5%, this should help decentralization.
Why a minVariableFee? From experience I have seen the strong race to zero, so to prevent a race to zero, I see high merit in setting a minimum setting.
5 Likes
Yes: “sticky stake”.
Proponents of increasing K should identify the reason they want K to increase. Deep down the reason is hope that it will force some stake to shift from large pools to small pools. I think some stake might shift, but I am concerned that it will be very little, and the reason for this is: “sticky stake”.
Deep down, we all know that any increase in K won’t significantly change the number of pool operators that need to be compromised in order to control the chain. In other words, the real decentralisation level is unlikely to change with an increase in K.
The real problem is “sticky stake”
Basically there are a heap of incumbent pools that got in early and received a lot of early delegation. Many of these early delegators are largely disinterested in the day to day activity, they don’t check stake pool fees or saturation levels, probably some have even lost their keys. This stake is not moving, and many large pools are benefiting from it.
Most of the large pool operators were also early, so they have lots of “sticky stake”. They also will have contact details for some of their larger Ada holders, because they probably know some personally. If K is increased, then these large pool operators will manage the situation as follows:
- Spin up one or more new pools
- Contact their known larger holders and ask them to re-stake to their new pools
- Their original pools will keep chugging along with the “sticky stake” remaining delegated
Maybe we should try to fix this “sticky stake” problem?
Why should “sticky stake” remain staked?
Staking is supposed to be an active process. The Ouroboros design assumes that stake will move if a pool operator starts behaving maliciously. The designers talk about stakers as being in a partnership with the pool operator. Stakers are supposed to be paid rewards for their active participation.
There is also a security concern with allowing sticky inactive stake to remain staked. This is because no matter how maliciously the pool operator behaves, this “sticky stake” won’t move. For example, someone could take over the pool keys and attack other pools by deliberately creating forks when their block VRF is lower than the previous block VRF. Such action would cause other pools to lose rewards but it wouldn’t matter how much outrage the community voiced, the “sticky stake” won’t move, and the malicious pool can proceed unperturbed, leveraging it’s “sticky stake”.
The current implementation doesn’t fulfil the Ouroboros design objectives. Staking rewards are supposed to be for active participation, and community recognition of bad behaviour should be able to induce stake to move.
Users who simply stake once and then disconnect for years, or lose their keys, shouldn’t be rewarded for staking, since they are no longer active. Furthermore, inactive stake should be un-delegated after some period of inactivity unless there is some sort of “I confirm my pool choice” action.
5 Likes
I don’t agree this will result in double the cost. When you have a well saturated pool, you should also have multiple relays. When splitting the pool, you don’t need double the amount of relays; you can use the same set and divide them amongst the two pools, maybe add just one. Also because of the min fee we now have, your income and hence budget will increase somewhat.
I also think that the idea of increasing k is that stake will mostly flow to other pools where some of them will get well saturated and they will bear the cost of more good infrastructure. You’re very much allowed to split your pool and hope your delegators will divide between the two, but that’s not the idea of increasing k I think…
I even saw it lead to pool splitting! One well saturated pool with a fairly high pledge (couple of millions) first changed it’s fixed fee from 340 to 170 and split a couple of epochs later and moved the majority of its pledge to the new one. The effect of such combination of pledge and saturation is not that big, but also not nonexistent, so it hurts their delegators (which might have chosen the pool for the high pledge). Because of the accompanying fixed fee change, they won’t notice it as much, but they were still beter off if the peldge stayed with the higher saturated pool…
You mean why a minVariableFee in your last sentence I think? I also would like to see a min margin, but that’s another discussion and this one is about k. 
My thoughts
Maybe we can try something else? Increase k gradually, e.g. by steps of 50 or 100 every 5 or 10 or 20 epochs. We then use some metric that combines decentralization and network health to evaluate the change. As long as decentralization doesn’t get worse, we keep on increasing until we reach a given value (e.g. 750 or 1000). If the metric gets worse, we stop increasing. That way, well saturated pools and its delegators aren’t confronted all of a sudden with a pool with 150-200% saturation.
3 Likes
Yes, of course, this is what I meant to say, sorry for being unclear on that. I doubt that all single then splitting pools will double the cost of their blocks producers. Relay cost could remain static, but demands will also increase for the relays if the split pool saturates and p2p selects those shared relays thus more often. So eventually the SPO will most likely have to invest into more relays than what he had as a single pool or up the performance of those shared relays, to keep up performance (or risk performance as I argued)
Fixed that last sentence on minVariableFee, thanks. As ‘k’ fails at its purpose of Sybil protection and is here solely discussed as a means to increase decentralization, I feel we can’t discuss ‘k’ without discussing alternatives to help decentralization. Or if we only want to discuss ‘k’, I strongly oppose to increase ‘k’ for the arguments given.
3 Likes
Not strictly true. You can run multiple pools with the same block producer. Needs some hacking, but is totally possible.
Also, you don’t really need relays at all. The cheapest (and not advised) way would be to run multiple pools on just one cardano-node with no relays and advertise that machine directly as “relay” (possibly with multiple IP addresses assigned). We will never be able to tell the difference from the outside.
If the operators know what they are doing such a setup might even be better administrated than a large fraction of the pools following those copy and paste guides but not understanding at all what they are doing there.
3 Likes
This is what should be done imo. Makes me very uncomfortable that we are presented with a double or nothing choice. This is how we spread the stake out. Doubling K all at once will be chaos.
4 Likes
Block rewards will continue to decrease significantly with the reserve slowly getting depleted. And there is no sign that transaction fees will be able to make up for that. They are a very tiny fraction of rewards right now and to change that we would have to multiply transactions (with the chain being sometimes close to congestion already) or raise transaction fees (while the community is proud of the low fees and despises Ethereum for its high but arguably sustainable fees). The third – quite outlandish – possibility would be to admit that “fixed supply” was just a fringe economic theory, ditch it, and keep subsiding rewards by inflation forever. I see none of the three things happening, so we will have much less rewards in the future.
Which is why I would consider lowering k. We don’t need that many pools and we can only finance a much lower number with the rewards. Most rarely if ever produce blocks. They are frankly irrelevant for decentralisation and it changes nothing if they are gone. (SPOs who rather do that as a hobby out of technical curiosity can, of course, always continue even with irrelevant stakes.)
k is supposed to be the target number of fully saturated pools. We are ridiculously far away from that with an MAV in the 30s. And there is no hint that the network converges as it was “predicted” by the game theoretic speculations in the original reward sharing scheme paper. Seems it was quite bad game theory there. Moving k further away from reality, creating an even larger friction, will not fix anything in my opinion.
Move k down to something like 100 and let MPOs honestly consolidate their operations in single pools!
And in the longer run work on the things that need changes to the ledger: Replacing minPoolCost by minPoolMargin and replacing k and a₀ by maxLeverage determining saturation as a multiple of pledge. That way pledge would finally really matter.
3 Likes
I think that falls under diminishing performance. Such a setup is very risky because the same node has to manage a lot of connections and check every slot if it has to mint a block. Also, pool splitting will happen for well saturated pools that have a lot of blocks scheduled, so a lot of switching between pools and a lot of chance that two elected slots are too close to eachother to be able to.
Yep. A real solution would have to hack the node itself to be able to run multiple pool configurations. Made harder by the chronic unavailability of Haskell developers.
But: As far as I know, the node can now reload configuration without restarting it completely which should make switching by script from the outside much faster.
2 Likes
I don’t think lowering k is up for debate here… Also if you want to do this, the whole pledge thing should be revisited first. With a lower k, the effect of pledge will be less (just changing a0 can’t fix this) so you even have less advantage of a higher pledge than you have now. Even the few pools that do benefit from a higher pledge now won’t anymore…
Why not?
You probably mean “lower k” (or equivalently “higher saturation”, since pledge only becomes relevant close to saturation with the current formula).
2 Likes
Yes, fixed this.
I don’t think they will consolidate their pools.
Say you are an early pool operator who now has 3 pools. You guess that your first pool has lots of “sticky stake”, maybe the second has bit less “sticky stake” and the third one you only just opened, so it has no “sticky stake”. Here is what you do:
- Tell all the large holders you know to move to pool no 3.
- Gradually increase the fees on pools 1 and 2 towards 100%.
- Profit.
When the rest of the Cardano community points out that you are still running 3 pools and asks why don’t you close the other 2? You say: “Well I have tried to get all the delegators to move to my main pool no 3. I have even increased the fees in my other 2 pools to incentivise the move. For some reason there are lots of delegators that are just disinterested and I can’t force them to move. It would be terribly unfair on these poor delegators if I was to close down my other 2 pools so I will keep them open until all the delegators move.”
Even with 100% fees the “sticky stake” won’t move. The maximum profit for the operator is to just leave the pools open.
I wonder just how much “sticky stake” some of the early multi-pool operators are benefiting from. Eg: How much sticky stake exists in the 29 1PCT pools?
We need to fix the “sticky stake” problem. It is not just a problem for fair distribution of rewards, but also it provides extra unfair leverage over the blockchain consensus.
3 Likes