CIP-0063? | Transferring Stake Pool Ownership

[zhekson1]

First posted on the Cardano forum: https://forum.cardano.org/t/cip-transferring-stake-pool-ownership/95329/4

Describes a way to transfer stake pool ownership between sets of cold keys.

[rphair]

@nomadpool can you do these things to make sure the CIP looks the same as others in this repository?

• move your draft into a directory beginning with CIP (this name is temporary & doesn't have to suggest a CIP number)
• rename your Draft file to README.md
• create a header / preamble for your markdown text as described here (or use the header from an existing CIP as an example): https://github.com/cardano-foundation/CIPs/tree/master/CIP-0001#cip-header-preamble

posted on the Cardano forum: https://forum.cardano.org/t/cip-transferring-stake-pool-ownership/95329

Please consider including this forum link in that header as a Comments-URI since there is some dialogue starting to accumulate there. 😎

[rphair]

thanks @nomadpool for the updates & good to see this issue is getting more visibility on the Forum.

[SebastienGllmt]

Cardano originally talked about maybe having staking pools being able to delegate to other staking pools (which is a more general construct than what you are proposing). The reason this ended up not being included is because

1. It increased the time it takes to calculate stake information at the epoch boundaries (which is already too slow and causing issues in the protocol)
2. It wasn't clear what to do in case of cycles (even just detecting cycles van be made expensive by somebody attacking Cardano and making really long chains)

Your CIP refers to the CLI commands you envision (which is good!), but you may want to look at the cardano-ledger specification and propose something using that language instead since it's more specific than just a CLI interface. I think probably everybody would agree this kind of migration logic is useful, but it would be good to see specifically how you address the 2 issues mentioned above.

[rphair]

call for discussion today in monthly SPO Digest here: https://mailchi.mp/iohk/spo-digest-february-675602

[zhekson1]

@SebastienGllmt My (naive) solution would be to limit the length of any delegation chain to some reasonable value. This would limit the complexity of the stake calculation, and make it easier to detect (and prevent) cycles. My thinking:

Cardano's PoS is (ideally) a plutocratic system; the higher an entity's stake, the more power they have (power being a general term referring to authority over various mechanisms, such as block production, voting, e.t.c.). Delegation of these powers to other entities is necessary, but should be regulated such that the source of the power is never too far from the execution of the power. This reasoning remains true even if the main-chain was computationally powerful enough to accommodate higher "limit" values.

This chain delegation "limit" may be introduced as an update-able parameter, and can be enforced strictly, or via a disincentive similar to how pool over-saturation is currently handled (or a soft/hard cap combination of both).

I realize this is all generalizable to a far broader scope than what is being proposed in this CIP. What do you think?

Also, I am going over the ledger specs and revising the original draft. Will commit changes soon.

[SebastienGllmt]

Just a ping on this CIP to see if this is still something you intend to work on

[zhekson1]

Yes, I am working on it. I will have a revised draft with chain delegation and ledger specs ready by next week. Apologies for the delay.

[rphair]

@zhekson1 as per your last comment on the Forum, it's not necessary that you close this ticket but it would be helpful if nobody can find a way of moving this ahead. We just got 43 new CIP PRs in the last 2 weeks so now we have a combination of old and new backlogs.

As I remember there wasn't a compelling reason for adoption that would justify the migration effort for SPOs or implementors. So yes please either close this add some comments or content that will somehow keep this moving forward. 🙏

[Ryun1]

@rphair @Crypto2099 @zhekson1

We can probably close this one for now, unless any final objections?