CIP-???? | Tune Parameters minPoolCost and K

[ADARobinHood]

(see rendered proposal in branch)

[rphair]

@ADARobinHood it looks like this deprecates your own CIP-0074 merged just 3 weeks ago. If that's not what you want (i.e., if they should both be concurrently Proposed or Active CIPs), would you please explain in this CIP, and summarise here in the discussion:

• how the earlier CIP relates to this one?
• particularly, how the further adjustment of K fits in with the Path to Active of the earlier CIP (which calls for a "Protocol Parameter Updates" but says nothing about changing K)?

[TerminadaPool]

Large exchanges want to:

• Maximise rewards
• Maximise liquidity (minimise pledge and lock-up time)
• Maximise control (eg: preferential submission of their transactions, avoidance of over-saturating stake pools)

Increasing K will make pledge more effective. Cardano's staking design forces exchanges to choose between increased pledge for increased rewards and reduced pledge for increased liquidity. This proposal will shift the balance in the pledge direction somewhat and might push exchanges towards community staking. However, staking to community pools will reduce their control over saturation, and increasing K would make this more difficult to manage. Implementation of multi-pool delegation could help here?

[TerminadaPool]

I like this proposal better than CIP-0074 because I agree combining decreasing minPoolCost with increasing K is necessary for the reasons stated:

• Creates necessary "shake-up" to stimulate re-evaluation of pool choice
• Increases effectiveness (value) of pledge

[ADARobinHood]

@ADARobinHood it looks like this deprecates your own CIP-0074 merged just 3 weeks ago. If that's not what you want (i.e., if they should both be concurrently Proposed or Active CIPs), would you please explain in this CIP, and summarise here in the discussion:

• how the earlier CIP relates to this one?
• particularly, how the further adjustment of K fits in with the Path to Active of the earlier CIP (which calls for a "Protocol Parameter Updates" but says nothing about changing K)?

This CIP is not mean to deprecate CIP-0074. I actually proposed CIP-???? (Tune Parameters minPoolCost and K) on forum.cardano months before CIP-0074, I just didn't push it on GitHub until now.

Instead, alternative CIPs are meant to give options and provide rational for different thoughts on different changes. Community awareness, discussion, and mostly education is important on these concepts. Both CIPs give a window into the future if that specific CIP is chosen to implement.

Although I think CIP-0074 is a more intelligent choice followed by a separate CIP for K adjustment, this CIP-???? is an attempt to side with the gods (IOG), and preserve their minPoolCost as sybille protection. In order for minPoolCost to provide sybille protection it must not step on the feet of pledge, and allow it to do its job. The current imbalance between minPoolCost and pledge cannot be rectified without a K or a0 adjustment. As mentioned in the CIP, adjusting a0 is a non option because of the large gap between real pledge and saturation. Leaving K as is, balancing minPoolCost and real public pledge would result in a minPoolCost of only like 2 or something, which is too low to provide any real disincentive anyway.

It would be foolish to force any shakeup of stake, like adjusting K, without first or concurrently removing or drastically lowering minPoolCost. The incorrect incentives minPoolCost causes are covered in both CIPs and their discussion forums.

[ADARobinHood]

I like this proposal better than CIP-0074 because I agree combining decreasing minPoolCost with increasing K is necessary for the reasons stated:

• Creates necessary "shake-up" to stimulate re-evaluation of pool choice
• Increases effectiveness (value) of pledge

I agree that both a reduction (elimination) of minPoolCost and raising K is what's needed. My planned course was to propose CIP-0074 - Eliminate minPoolCost, then propose a separate CIP for a K increase. CIP-0074 HAS to be a prerequisite to the K increase.

I figured that by proposing them separately they would be more likely to get adopted as opposed to proposing 2 large parameter adjustments at the same time.

[rphair]

@ADARobinHood: This CIP is not mean to deprecate CIP-0074. ... to give options and provide rational for different thoughts on different changes ...

OK, then like CIP-0074 this CIP will also need a Path to Active section in order to merge it as Proposed if they are both to exist in parallel. If you think (or if it's decided in this discussion) that this CIP depends on CIP-0074, that's the place to mention it... likewise you can update the Path to Active of CIP-0074 if it involves either consideration or implementation of this one. 😎

[rphair]

@ADARobinHood this PR is coming up for "Triage" (initial presentation & cataloguing) at the Discord CIP meeting in about 90 minutes. Upon further consideration I'm going to recommend as I briefly suggested earlier in #387 (review) that this proposal and CIP-0074 be merged somehow: if not deprecating CIP-0074 outright since it is only a rudimentary version of this one.

alternative CIPs are meant to give options and provide rational for different thoughts on different changes. Community awareness, discussion, and mostly education is important on these concepts. Both CIPs give a window into the future if that specific CIP is chosen to implement.

Actually, that is what:

• ... a single CIP is for: if two proposals have the same goal, with a nearly identical solution and other essential components (even the same author in this case). If so it may have a complex Path to Active that depends upon input from company stakeholders, or the observation of gradually varying some initial parameters: including some "forks in the road" like you have between this & CIP-0074.
• ... a single CPS is for: if the solution is declared to be undecided (as you involuntarily argue for in this case, by presenting two divergent CIPs on the same subject). I'd say this is the least attractive option if you're concerned about adoption, because the less concrete presentation tends to delay adoption a bit & many in the community consider this to be urgent.

In either case, a single document is what would best focus attention on the problem at hand: not wallpapering the CIP space with functionally almost-equivalent proposals in hope of widening the path so that the protocol developers follow.

I'll ask editors @KtorZ @SebastienGllmt @crptmppt briefly how they feel about having these as 2 separate CIPs and will post here if there is any consensus otherwise & if necessary will update my review status accordingly. Only "Triage" is scheduled this meeting: but by the time a detailed review comes up I would suggest in open discussion that this PR be rewritten as an update to CIP-0074 if another option to consolidate these 2 proposals is not taken.

[rphair]

@ADARobinHood in light of today's CIP meeting discussion in the last hour, I'm demoting my last "blocking" review to an ordinary comment. Though I still believe your submission would work better as a single, combined CIP than two proposals, we (mainly including @KtorZ) agreed that different presentations of parameter sets are not the first thing the community needs to address this problem: but rather a functional dialogue and process between IOG and the stakeholders, operators and developers who might rely on these parameter changes.

Effectively all these RSS (Reward Sharing Scheme) proposals are in limbo until IOG produces, or accepts, something like a Cardano Problem Statement (CPS) which provides a framework to review RSS proposals. This has to be the first step in considering anything like your own proposal (or CIP-0074 for that matter).

I haven't seen you in this so far, but there's a Discord in which the efforts to engage IOG have been discussed along with other particular RSS schemes. Since we can't do anything to progress his PR until we have that framework, it might help to post any ideas about that here (please post or message me if you need an invite to this server... this thread also contains a link to similar discussions in an MBO-like group on Matrix): https://discord.com/channels/971785110770831360/971785110770831366

Review still stands, but no longer wish it to be "blocking" this PR.

[gitmachtl]

I would like to see things like a minPoolFee implemented together with such changes.

[rphair]

Closing after 3½ months of no activity and no word from author since end of 2022. Author pressed #358 through to merging but left this one behind, though I think this proposal is more comprehensive.

Now that RSS proposals have been granted Ledger status as updated across the board in #536 this one would also be a valid candidate if the author is still interested, though we might assume abandonment because there was no response to tagging @ADARobinHood in that PR.

Consequently if any constructive interest from the author, or another author/advocate that will take over editing and review, we can reopen this.

[rphair]

Retitling to remove 83 as per #387 (comment) - if this gets going again a new number will have to be assigned.