PCP_K-Parameter_EarnCoinPool

Doesn’t matter. Doubling the resources, to secure the same 70m ada staked by x servers and energy, without clarity on whether it justifies a meaningful MAV increase, seems illogical.

3 Likes

Like I explained before, there is NO doubling the resources… That’s just fake news.

you didn’t explain. you said what you think will happen. And what I was trying to say was also just what I think. since it was no news, it could also not have been fake.

1 Like

I explained it here.

I think we need to zero in on the reasons why we might consider changing K. The way I see it there are at least 5 challenges to be solved and they are all interconnected:

  • SPO Decentralization
  • Sticky Stake
  • Pledge being unimportant
  • Rewards/Fees sustainability
  • Making small pools feasible/competitive somehow.

My understanding is that changing of K is mostly aimed at the first two (decentralization and shifting stake). However, it is not clear to me that any adjustments to K will have the desired effect.

In the case of decentralization, it would be wise to remember that the MAV is not…

“number of pools to get above 51% stake”
it’s…
“number of SPOs to get above 51% stake”

Since K is directly related to an increase in pools (which itself is not a given) and not SPOs, I don’t think raising it will have the desired effect of increasing MAV.

In regards to “sticky stake”, raising K seems to be a band-aid fix to shake up the stake in hopes that it moves into single SPOs and new SPOs. I think that also is not a given, but unfortunately it’s also temporary.

IMHO we need to address the sticky stake issue first because stake needs to be “active” and “mobile” to support the security assumptions of Ouroboros. There are some CIP ideas for this such as requiring re-delegation every so often, expiring stake, or stake demurrage, but they are probably out of scope of this thread.

Once sticky stake is fixed we’ll be able to more easily see the impact of any further RSS changes. Perhaps the current reward sharing scheme (RSS) will converge on the intended K-pools and pledge/fees will work themselves out. If not, then I think ideas for RSSv2 as myself and others have pointed out elsewhere might be appropriate.

EDIT: If we do decide to adjust K, then I think the follow up question would be how gradually to implement the the change. I think it’s important to first decide on whether or not we should change it though.

6 Likes

Probably the only way of moving the sticky stake is to force redelegation (even to the same stake pool) after a period of time. And if a wallet doesn’t redelegate, the delegation would be lost (the wallet would be not delegated to any pool anymore).
This is a major change and it will probably not be implemented.

4 Likes

I agree it is a major change but I disagree that it probably won’t be implemented.

I don’t think the design architects and Ouroboros implementation engineers will be happy that their design isn’t properly implemented.

A change needs to be implemented. “Sticky stake” consists of stake that is old, inactive, and lost keys that is never going to re-stake no matter how maliciously a pool operator behaves. It creates a structural imbalance in the Ouroboros protocol whereby a bunch of early pools have more consensus power, and more voting power after Voltaire, than they should.

Staking rewards were always designed to be rewards for active participation. It is time to properly implement those design goals. Those that are not actively involved in staking don’t deserve to be paid staking rewards.

I think it is entirely reasonable to have users confirm their stake pool choice by submitting a confirmation transaction periodically. It would be simple for wallets to remind about this and it would be easy for users to do. If such a confirmation, or re-staking transaction, isn’t done every say 6 months or even 1 year, then an expiry mechanism should be implemented in the ledger so that this stake no longer counts towards that pool’s total.

3 Likes

When thinking about it, I noticed that it shouldn’t be much shorter than that: For small stakes – and if Cardano gets more adoption there will be even more small stakes – the fees of the confirmation transaction might otherwise eat up a significant part of the rewards gained from the staking in the first place.

3 Likes

I agree. That is another reason why I think the timeout should be reasonably long like 6 months or a year. If the user has small enough amount that the re-staking fee of 0.17 Ada every year will significantly affect his yield, then he should reconsider whether staking is something that he wants to do. I don’t think staking should be viewed as automatic. Stakers are actively participating in securing the protocol by being a partner with the stake pool operator.

In any case, putting a timeout on inactive stake would still be beneficial even if the timeout is incredibly long like 2 years. This is because the amount of disinterested, un-engaged, forgotten, and inaccessible, lost keys Ada is going to grow over time which will represent quite a lot of Ada. Some pools will retain this extra consensus power and voting power… Forever… No matter how maliciously they behave.

6 Likes

I understand the argument that there is stake that has been forgotten, lost keys etc, but we need to balance that off with people passively earning rewards (which has always been a selling point of Cardano).

You should be able to actively choose a stakepool and then passively gain rewards. Trying to force active redelegation on people, at their expense, sounds like a crap user experience for the (hopefully) majority of stakers that are already happy with their choices.

Also, how hard would it be for a wallet to implement auto redelegation and thus circumnavigating this “feature”?

Equally, I feel there is something operationally backward about trying to improve the security of the network by booting out stake that is currently securing it. It feels a lot like throwing the baby out with the bath water.

Just because SPOs dont like where people have delegated, or how passive they are in managing that delegation, doesn’t mean the protocol should start forcing people to pay to click “redelegate”.

1 Like

I think it would be expected, and a good thing, if wallets provide such functionality. The wallet can simply generate a staking confirmation for the user every 6 months or so whenever she is actively doing something else with her wallet. But, forgotten Ada and lost keys won’t do this. Consequently, inactive Ada won’t be taking rewards from the reward pot. This will result in more rewards retained for those that actually are alive, and at least minimally active.

Inactive stake is not in any way contributing to the security of Cardano. In fact it is doing the exact opposite. It is making Cardano less secure, more fragile. The reason for this is because inactive stake can’t or won’t move, irrespective of how maliciously the pool operator behaves. For example, a particular pool operator could form an alliance of malicious pool operators and then work with Amazon + Google to attack Cardano. And, despite all this, the inactive stake will remain staked to his pool providing him with increased voting power over the blockchain consensus. After Voltaire, this inactive stake will also provide increased voting power in governance actions where stake pools get to cast the deciding vote.

I don’t seek to influence where people choose to stake their Ada. Some users may even want to stake with a pool behaving maliciously and they can do this if they want to because Cardano is an open protocol. But, users don’t have to stake their Ada at all, they can do whatever they like with it. They can earn passive yield by using it to provide liquidity in some DeFi app, or use it as collateral for a loan, or just leave it in their wallet. Currently the staking yield is mostly less than 3% and falling, so they will likely earn more yield doing something else with their Ada.

Even if someone chose to stake their Ada and then forgot about it for several years. All I am suggesting should happen is that this staked Ada should get recognised as inactive after some period of time, like 6 months or 1 year. If the user then chooses to confirm their delegation then it will be immediately recognised as active again, because they made an active choice to support a particular pool for another 6 months or 1 year.

The design architects should have implemented the protocol this way from the beginning. It was an oversight because they assumed stakers would remain actively involved in checking the performance and behaviour of pools, due to financial incentives.

The point is: Staking rewards are payment for active participation in staking. Stakers are in partnership with their pool operator. Stakers are taking an active role in securing the protocol. Just how active that needs to be is up for debate. I don’t think confirming your delegation just once or twice a year would be too much to expect. But certainly set and forget forever, and lost keys, are not in any reasonable sense, playing an “active” role in securing Cardano.

1 Like

I think it would be expected, and a good thing, if wallets provide such functionality. The wallet can simply generate a staking confirmation for the user every 6 months or so whenever she is actively doing something else with her wallet. But, forgotten Ada and lost keys won’t do this. Consequently, inactive Ada won’t be taking rewards from the reward pot. This will result in more rewards retained for those that actually are alive, and at least minimally active.

I was suggesting a contract or wallet that does not prompt, but auto redelegates. Essentially ending up in the same situation we have today, only generating tiny fees periodically. In this case we would shake out the current dormant stake, but anyone that uses these new mechanisms and loses the keys will just be in the same position as today. I don’t think it’s a good idea to change the protocol for a one time shake out.

Inactive stake is not in any way contributing to the security of Cardano.

Any stake that contributes towards block production via correctly run node software will contribute towards the security of Cardano.

In fact it is doing the exact opposite. It is making Cardano less secure, more fragile. The reason for this is because inactive stake can’t or won’t move, irrespective of how maliciously the pool operator behaves. For example, a particular pool operator could form an alliance of malicious pool operators and then work with Amazon + Google to attack Cardano. And, despite all this, the inactive stake will remain staked to his pool providing him with increased voting power over the blockchain consensus.

Any stake, active or inactive, will compromise the security of Cardano if delegated to a maliciously operated pool. The only way dormant stake becomes a genuine concern to security is if the amount of dormant stake is a significant amount of stake assigned to pools that become compromised. I don’t know whether simply minting one block in a malicious pool is enough (I kind of expect the correctly operated pools to reject it) or whether we need more than 50% of blocks by malicious pools before we consider the network compromised.

Either way the amount of dormant Ada would need to be huge and I think Cardano has far bigger problems if this is really the case. If dormant stake really does account for that much of the current active stake then forcing it out does feel like an operational concern (e.g. dramatically reduce the number of assigned blocks), but I’m sceptical it is significant enough for this.

After Voltaire, this inactive stake will also provide increased voting power in governance actions where stake pools get to cast the deciding vote.

I agree this is a concern, not of k or decentralisation, but of the proposed governance. My understanding is that the decision to proxy delegate votes to SPOs was due to the very problem of dormant stake / passive delegators. There is something horribly cyclic and redundant about forcing people to be active delegates, because SPOs will get too much power via a mechanism they were given to combat the inactive nature of delegates. Surely if you force active participation then you dont need to proxy votes to SPOs? Maybe you would need to tweak the redelegation to include voting or whatever, but it does seem a better way to approach governance (removing the SPO proxy).

But certainly set and forget forever, and lost keys, are not in any reasonable sense, playing an “active” role in securing Cardano.

Whether you follow your pool and the community closely or just set fire to your keys and walk away the protocol doesn’t care - active participation is considered signing a tx to delegate to a pool. This might have been an oversight, but it’s what every existing delegate signed up to. I agree set and forget doesn’t feel in the spirit of “active” delegation, but it’s acceptable within the protocol that was signed up to.

I think previous votes have shown how little the average user cares about participating in decentralisation / consensus debates and that they just want the network to run smoothly. Forcing participation of people who genuinely don’t care and are not informed also doesn’t feel like it’s in the spirit of securing the network. It just sounds like a good way to put people off Cardano.

All in all - I don’t see any of this as being fixed by changing k so I think we’ve wandered a bit off topic :slight_smile:

1 Like

That is not possible so easily.

Contracts aren’t active themselves. Transactions have to be initiated either by a user or by some off-chain code in a dApp backend and the validator “only” checks if the transaction is okay.

And wallets are only active when the user opens them. Up to now, they also have followed the best practice of never storing keys unencrypted and requiring the spending password for decrypting them for every single transaction.

Even if wallet apps would deviate from that practice (bad, really bad), they could still only do the confirmation if the user opens them periodically, so that they even have a chance to execute. (And it also indicates that the keys are not lost.)

Your auto-redelegation would only be possible if users move their funds to custodial wallets, so that someone else does it for them. Do you really expect that users do that in significant numbers?

3 Likes

That is not possible so easily.

Contracts aren’t active themselves. Transactions have to be initiated either by a user or by some off-chain code in a dApp backend and the validator “only” checks if the transaction is okay.

And wallets are only active when the user opens them. Up to now, they also have followed the best practice of never storing keys unencrypted and requiring the spending password for decrypting them for every single transaction.

Even if wallet apps would deviate from that practice (bad, really bad), they could still only do the confirmation if the user opens them periodically, so that they even have a chance to execute. (And it also indicates that the keys are not lost.)

Your auto-redelegation would only be possible if users move their funds to custodial wallets, so that someone else does it for them. Do you really expect that users do that in significant numbers?

Thanks @HeptaSean. I was wondering how possible it was (hence the initial question) and you’ve confirmed what I suspected - it’s technically possible, but wouldnt work in practice. I still have doubts about forcing participation, but I agree I don’t think you could circumnavigate (in a sensible way) enforced redelegation

1 Like

Nobody is talking about forcing anyone to do anything. Users could choose to actively participate in staking whereby if they become inactive then their Ada will also become inactive after a period of time, because they are no longer active. Or, they can use their Ada in DeFi, as collateral, or to provide liquidity, or whatever.

Staking is an active role and users are rewarded for active participation.

By the way, some of the very early OG pools which received a lot of stake from the ITN days may have 20% inactive stake. That is quite a lot of extra voting and consensus power.

Something I find interesting is that opponents seem more prepared to gloss over the extra consensus power problem, but less prepared to accept the extra Voltaire voting power problem.

1 Like

No it won’t because the rewards belonging to not staked ADA flow back to the reserve.

That’s why I want a raise of k, so stake will be distributed amongst more independent actors. Not all stake that is now delegated to a multi pool or big single pool will stay with the same SPO after those pools will split.

Nobody is talking about forcing anyone to do anything. Users could choose to actively participate in staking whereby if they become inactive then their Ada will also become inactive after a period of time, because they are no longer active. Or, they can use their Ada in DeFi, as collateral, or to provide liquidity, or whatever.

Staking is an active role and users are rewarded for active participation.

Today staking is a passive role and users are rewarded for passive participation. It’s even in the docs here:

Users who hold a stake in Cardano can earn passive rewards for validating blocks.

and here:

Typically, the stake pool operator (SPO) installs and runs software compatible with the platform (the server node), while delegators take a more passive role. They delegate their stake to the pool.

No one that has staked ADA has committed to being active nor were they required to. Retrospectively changing this and removing delegations from consensus because they aren’t doing something they were never required to do feels wrong.

Introducing this in a way that only applies to new delegations would remove the aspect of changing the terms after the fact, but that wouldn’t achieve the goal of removing the already “set and forget” wallets.

By the way, some of the very early OG pools which received a lot of stake from the ITN days may have 20% inactive stake. That is quite a lot of extra voting and consensus power.

Something I find interesting is that opponents seem more prepared to gloss over the extra consensus power problem, but less prepared to accept the extra Voltaire voting power problem.

I don’t think anyone is trying to gloss over the consensus problem, equally I don’t believe it is in any way addressed by changing k. If your pool splits and the active delegation moves to the new pool and the inactive stays where it is then the MPO has the same power as today. If future voting takes in to account number of pools as a metric then they would arguably have more voting power.

I agree if we could force redelegation we would remove the forgotten/lost stake, but k doesnt solve that. That being said, I think removing lost/forgotten stake goes against the terms people signed up to and it removes that stake from consensus permanently. I know the latter point can be argued as a good or a bad thing, but personally I think having more assigned blocks across the network is better for stability than removing inactive participants.

As a small pool operator it does frustrate me that early adopters have an almost permanent advantage due to the forgotten stake, but I think we need ways to incentivise decentralisation. Perhaps a better strategy would be to offer additional rewards to delegates for active participation? It would take a lot of thinking through how that would work, and it’s a bit of a detraction from the current debate around k, but I’m thinking an incentive to affirm your pool choice or for participating in governance voting. Potentially rewards could even be higher for pools that have more “active” delegates, which would remove some of the early adopter advantage that has forgotten stake. This is a change to the RSS in it’s entirety though.

Ultimately, changing k only changes the saturation point. That may or may not trigger stake movement and it’s unknown whether that would move towards more or less centralised stake distribution. Personally, I’d like to see more stake shifted away from large MPO groups and in to the 100s of single pool operators, i.e. MAV going up.

FWIW I also see k as a failed parameter, which was never capable of doing what it was intended to do, e.g. it can’t ever affect decentralisation (fundamentally can’t take in to account pool groups) and it can’t control the size of the network (k=500 and we have ~3000 pools). For me - we’re wasting time trying to fiddle around with a parameter that has no tangible, guaranteed benefits.

2 Likes

Removing dormant/sticky stake won’t result in less assigned blocks. Slot leadership is calculated by active stake.

2 Likes

Somehow disagree. Changing rules with an announcement six months or a year in advance seems totally okay for me.

The docs also only speak of “more passive”, not “totally passive”. Proof of stake with delegated stake only makes sense if delegators are at least active in the sense that they put some thought in choosing their stake pool.

2 Likes