You can’t say it would be unfair is the fee is 100%… 
2 Likes
You picked out the one thing you agreed with, and made a post about it ignoring everything else?
How about disproving my other points, and giving your opinion on my proposal?
When increasing k, sticky dormant stake WILL suffer the consequences, as they’ll remain in a pool that will become oversaturated. If it doesn’t become oversaturated, there’s no harm done.
Can you comment on my proposal please?
1 Like
I agree with the RV master, k should be increased gradually.
There’s no logical reason to all of a sudden DOUBLE it, it’s also not the way we’ve done things in Cardano up till now.
Let’s discuss gradually increasing k, keep an eye on network health, decentralisation and stake distribution.
All the concerns of pools splitting etc. will also be less of an issue. No pools will likely split if k goes to 650 - 750 - … gradually. All other factors of pool/chain dynamics also constantly change, so every k increase will be within the correct dynamics of the change at that time.
3 Likes
Has there been any research done on the effects of…
- Network block latency vs. number of pools (both BPs and/or relays)?
- Block rewards vs. number of pools?
- Amount of stake needed to produce blocks vs. pools * saturation threshold?
I’d be interested to know what the tradeoffs would be in any of these cases.
It seems to me like one of the primary reasons for raising K is simply to shake up “sticky stake”, even if it’s only temporary before it settles again. If that’s the case, then maybe there might be something else we can try to mitigate that issue other than changing K?
2 Likes
Sorry it came across that way. I just thought you made a good point about dormant stake and I have been thinking about “sticky stake” for a while, so I wanted to also credit your terminology. I think we need to figure out a better way to address the “sticky stake” problem rather than just raising K to shake the system, with the hope that some stake will trickle down to smaller pools.
Regarding your proposal to increase K to 750 instead of 1000. I thought I had made my position pretty clear that I don’t think any increase in K will improve real decentralisation. I also don’t think it will shift much stake from large pools to small pools.
I tend to agree with @HeptaSean 's comment:
After reading the Ouroboros papers, I came to essentially the same interpretation.
2 Likes
I’m still struggling to see any benefit of moving k. Any argument that “shaking the tree” could make the network more decentralised can easily be applied to it making the network more centralised.
In Cardano we secure the network with stake delegated to pools. There is no slashing and with pledge almost meaningless the only thing really keeping a pool producing blocks is the stake delegated to it. In most pools this is predominantly stake coming from external delegates.
Intentionally causing disruptions to delegates does not seem fair to them and is essentially disrupting the block production layer of the network. In this case I dont think it would actually be too harmful as the impact would be fairly low (again asks the question of why bother), but i still don’t see it as a risk worth taking.
In my opinion k was intended to control the number of pools in the network and has failed to do so. It was built on the assumption that delegates will delegate optimally (they dont). It fails as a measure/control for decentralisation as it cant take in to account pool groups.
I don’t see any value in changing it and it feels needlessly disruptive to start tweaking the numbers to see what happens. The only sensible way to iteratively tweak k would be to choose a measure/metric to assess each change on. Choosing the metric will likely descend in to the same argument as everyone pushes for a metric that suits their narrative.
2 Likes
The block propagation delay does increase with the number of nodes in the network. However changing k from 500 to 1000 is not expected to make a noticeable difference.
3 Likes
Why is raising it slowly not being discussed? Doubling it will cause users to lose rewards. Why is preserving rewards taking a back seat to whatever simply doubling K achieves?
1 Like
What makes you think it is not being discussed? It is discussed here now and @MatthewCapps wanted to take the discussion from here into the Parameter Committee.
Up to now, here are only a few individual persons throwing in their opinions.
That being said: I don’t see the huge difference. Doing it gradually does not make it necessarily gradually for the pools and delegators. They still slide into oversaturation at one of those gradual steps and start losing rewards.
Maybe one huge step even gets more publicity so that more delegators get the memo that they should check if they want to change than with a lot of small steps each affecting only a few.
And I’m still arguing for lowering instead of raising k.
3 Likes
It’s a curve. The approach of doubling is choosing a stick over the carrot. If we decide to do it the most important thing should be reducing the impact on users rewards. That’s not the impression I am getting from the arguments I’ve seen. Aside from yours 
1 Like
Well, @Cerkoryn, @ChrisSTR8, @LambdaHoneypot, @intutionismRus, and me question if it should be raised at all.
@brouwerQ, @robbyja7, and you explicitly brought up that it should be done gradually.
I see nobody strongly opposed to doing it gradually up to now. But let’s see if we get more opinions in here.
2 Likes
Well, gradually increasing k is better for transitioning from a single pool to a small multi pool with 2 pools than doubling k in one go. Semantically, gradually increasing k with the goal of doubling k, is the same as doubling k in one go, so the rate of pool splitting will be the same IMHO.
So, personally I strongly oppose increasing k in one go or gradually for the arguments given, but if we can’t avoid increasing it, I prefer a gradual increase as this eases the transition of delegators to a split off pool.
I believe we should really ask ourselves what goal are we trying to achieve with increasing k? Is it Sybil protection? k failed at that, so why would increasing k help any? Is it to help decentralization? As I argued there are much better ways for that, like minVariableFee.
4 Likes
For clarity - I’m opposed to incremental updates unless a clear goal and corresponding measure is supplied. Iteratively changing parameters without a goal or measure is just stumbling around in the dark whilst disrupting delegators.
Once the goal/measure is supplied i’d base my thoughts on that.
What I’m still not seeing is a clear benefit of moving the param (in any direction) other than the (IMO flawed) argument of shifting stake to improve decentralisation.
4 Likes
I didn’t reply to this yet, because I have replied to many other variants of the same things before.
I don’t think raising K without first revamping the whole rewards formula is a good idea and you can find my analysis here:
In essence, raising K will not stop multi pool operators to spin up more pools. Many of them don’t even have to split their pools since they have already prepared for this K increase (they are less than 50% saturated). It’s therefore questionable how much ADA will flow over to smaller pools. But it is not questionable that single pools that pledged not to split their pool and are successful, will have to either also start splitting pools or see their delegators being forced out. Finally what is also not questionable is the fact that increasing K will require a lot more resources to run the same network (since more pools means more servers). This is worth it if MAV (decentralizationn of the network) will increase enough. But I wonder if you still think that MAV will increase enough after seeing my analysis above.
5 Likes
my 5 cents on revisited topic of K increase..
current main points 'for':
~~~~~~~~~~~~~~~~~~~~~~~~~~
1) call to action for a large portion of delegators, forced to make a decision with regards to their stake pool choice
2) moderate portion of delegators will relocate their stake to non-multi-pool-conglomerate stake pools, prolonging their lifespan,
increasing number of pools owning entities making blocks regularly
3) it's been done before, it improved decentralization before (according to both my personal number crunching, see https://pastebin.com/raw/iUMvQE5s
- from what I observed, it was the injection of more new staked Ada into the ecosystem by Binance and later Coinbase partially obscured
the overall improvements to stake distribution - as well as analysis from IOG on the topic in their blog). Would be nice to see if Balance
Analytics (or some other site, e.g. maybe some explorer) might one day have the ability to select a handful of pool groups and then plot a
chart of their stake / pool count between a range of epochs to easier visualize past parameter adjustments effects.
current main points 'against':
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) hurts 'good' single operators with currently near saturated pools
a) usually need to break some eggs to make an omelette
b) need to compare pool rewards at new proposed K level vs. average maintenance costs before claiming someone is hurt
c) some fraction of to-be-affected SPOs do not oppose the idea of spreading the stake further as evidenced by last year's SPO poll
d) pools that have moderate to good communication with delegators via various channels have multiple options on how to keep their
current earnings at existing level, i shouldn't need to spell them out - and if someone is running out of ideas where to move their
Ada, there is sure to be plenty of hands up with detailed descriptions of why this or that ecosytem contributor deserves an extra
piece of the delegation pie...
e) even first time K was increased, there were some people who had this sense of entitlement... at the end of the day,
as cliche as it sounds this is bigger than any one individual or cushy income stream.
2) multi-pooler operators will just double number of their stake pools
a) creating extra pools costs a bit extra in infrastructure / reconfiguration efforts
b) while institutional money in pools like Binance / Coinbase / ETORO we almost expect to be split across more new pools,
it's not always so clear cut with regular operators, and we've seen from the last year's poll, some promised not to do
further dividing (plus it probably doesn't make financial sense below certain level of stake in a pool in the first place)
c) as we've seen from data after last K increase, moderate amount of stake flows elsewhere, not necessarily staying with the
original MPO - people that aren't on social media channels often react based on what they see in a wallet (see General comments section
for some ideas on how to improve the distribution via wallet enhancements)
3) need plege-effectiveness improved before any further k parameter adjustments
a) "Our research team is in the late stages of finalizing an approach. They will soon present their findings,
and we will update the community then. However, the team has now concluded that a0 should change." were the famous words from
Colin in 2021 March blogpost. For years I tried finding out what happened to those findings but they seem to have been eaten
by a research lab dog.
b) We also have a couple of fairly well known CIPs that try to improve on pledge effectiveness (most notably CIP 50 by Michael L),
but they all seem to have stalled, some have been abandoned by authors due to lack of forward progress... plus if pledge effectiveness
is indeed a prerequite for more K adjustments, why don't we set up another poll with better laid out questions and if enough
participants think so, discuss pledge effectiveness first.
4) fear of increase in block propagation times and subsequently lost blocks
a) my understanding of the word from networking team is that they don't think doubling number of pools will have a
noticeable degradation in block distribution (can we simulate this/have we simulated this e.g. IOG and its AWS relays in the past?)
5) good enough decentralization as it is
a) yes, those who hear number 3000 and think that Cardano has 3000 more or less equally sized stake pools with independent
owners would probably say that... check Balance Analytics for the latest Minimum Attack Vector figures for the network
General comments/observations in no particular order:
a) effectiveness of K adjustment can be improved by education / visual cues / more detailed information for end-users in main wallets
e.g. what percentage of wallets even show a clear warning upon being opened that you're delegating to oversaturated
pool / soon to be oversaturated pool? some wallets inject their own company pools into first pages of ranked pools, others rely on
pool lists provided by websites without any transparency about what factors are being used to arrive at the given pool ordering...
mandating open sourcing of all these ranking mechanisms and subsequently making them configurable in wallets would be a step in the
right direction imho (ignoring Daedalus here, as much as i'd like it's staking screen to change i feel like it's futile banging
the head against that wall after all these years - although some extra ledger APIs to expose the underlying numbers that are used in
constructing Daedalus rankings would be appreciated...).
b) pool grouping (and subsequently dis-incentivizing/penalizing of larger formed groups) was never designed in the protocol,
wasn't properly considered in the simulations even after we had large pool groups that formed on Incentivized Testnet...
community-driven pool grouping curation is fairly effective thus far yet utilizing it for additional pressure on large pool
conglomerates is limited depending on the embracement of this topic by the main wallets in the ecosystem (currently only Eternl
i think... a bunch utilize adapools API results, no idea what random - seemingly rubbish - generator Lace uses, Typhon actually does
intentionally have a random pool list at the moment - room for improvement imho, as much as I'd like to tell myself it might drive
some people to do their homework/due diligence)
c) some explorer sites offer handy sorting/filtering capabilities with regards to pools - we are very much lacking on that front
in most of our wallets, if you want to improve decentralization slowly but steadily while educating the general masses add a few
more tooltips / question mark educational tidbits in easy to digest manner, we stand a better chance of the network succeeding if
we don't just have 'i just click on the first square in Daedalus and forget about it for a year' average wallet user.
3 Likes
Raising k won’t necessarily result in more pools… They’re already 3,000 pools, I don’t think we will suddenly many new pools because of the raise (besides some pool splits). The idea is that some stake will flow into already existing pools.
1 Like
Thats the idea yes, but the reality is probably another one.
I think people forget that we already increased K 1,5-2 years ago and we saw that alot of stake just moved to the newly opened pools from MPO’s.
3 Likes
That was an increase by a factor of 3.33 and they weren’t as much existing pools back then.
Also, even if all existing SPOs that need to open up new pools to keep their total stake, the amount of newly created pools will not double (there’re multi pools that aren’t saturated enough that they’ll need to spin up extra pools).
please have a look at the data i extracted here https://pastebin.com/raw/iUMvQE5s and let me know if you have some questions about what is being shown (in a nutshell, it’s the amount of stake and pool counts of largest MPOs at and a bit after the last K adjustment, and how that stake amount relates to amount of stake they had when K increase blog post was published announcing plans to increase it) - my interpretation of it is clearly a positive trend i.e. in most cases a reduction in pool cluster total stake, not increase.
1 Like
If anything is obvious about this thread, it’s the fact that increasing K is NOT obvious.
There was much more agreement about lowering the minpoolcost and most arguments aligned.
4 Likes