CIP-36? | Update CIP-15 to support multi-delegation #188
Conversation
|
If you are not the author of the CIP, then it might be best to propose a different CIP altogether... CIP 15 specifically deals with Catalyst, I personally feel it is important to distinguish between fund allocation and governance. |
That's the case for this updated version as well. The changes proposed here are directly coming from new requirements for Catalyst improvements. (I am in the team that provides the backend for Catalyst, like 2 of the original authors of this CIP were before leaving the project) |
CIP-0015/schema.cddl
Outdated
|
|
||
| key_registration = { | ||
| 1 : $voting_pub_key, | ||
| 1 : [+delegation], |
There was a problem hiding this comment.
presumably this should be backwards compatible?
There was a problem hiding this comment.
It could be useful indeed, but that means we should also have a default implicit value for voting_purpose (which could be catalyst)
There was a problem hiding this comment.
If it's not mean to be backwards compatible, we could probably specify in the CIP a cutoff point where all registrations using the old format are no longer valid. If we don't want this kind of cutoff point, then the CIP should maintain backwards compatibility
There was a problem hiding this comment.
Added a legacy version for the voting_key field and used 0 as the default for voting_purpose since old registrations were meant for Catalyst only
There was a problem hiding this comment.
Yes, going forwards, we will have many voting purposes (both funding and governance). As you say, setting the default to be 0 (and assigning this to Catalyst) seems sensible.
There was a problem hiding this comment.
Concerning invalidating existing registrations, we will need to see how the Catalyst team use the new capability. They may well be happy with (or positively want) retaining existing delegations. New uses will need to use the new format, of course (we definitely want to allow different delegation choices for different voting purposes). There will be some semantics associated with the purpose, but that is essentially assigned externally to the chain. It would be possible to use the same purpose for multiple voting events if wanted. We shouldn't mandate that semantics.
As I see it, the advantage of invalidating old registrations would be
- all voters will need to think about their allocations (and not just continue with a single delegation)
- front-end and bridge tooling only needs to support one CIP-15 format
The disadvantages would be:
- voter disruption (need to re-register)
- cost (for each voter submitting a new registration)
CIP-0015/test-vector.md
Outdated
| @@ -56,10 +57,11 @@ a3d63f26cd94002443bc24f24b0a150f2c7996cd3a3fd247248de396faea6a5f | |||
| '1': '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0', | |||
There was a problem hiding this comment.
Probably we should have a test case for both the old value of 1 and a new test for the new value
There was a problem hiding this comment.
Yes, if this is fully backwards compatible. Otherwise you would presumably have one test for the original format and a different test for the new format
crptmppt
added
the
Update
|
As agreed, this is not optimal to merge into CIP15; I will propose a new one, so that wallets can signal support for CIP15 or both. This PR is now depreciated in favor of #200. |
Note that there will be a new governance API (under design, and still too early to share) that should abstract over the format. Any wallet or other tool that uses the API should not need to know which registration format has been used. Likewise the bridging tools should accept both the old and new formats when determining the voting power. |
|
This was discussed at the Editor meeting 38 (see notes)- it is expected to be resubmitted as its own CIP rather than an update |
KtorZ
changed the title
That would not be backward compatible with existing CIP-15 registrations. On the other hand, we can require tags to be used for all new stake credentials and leave the stake key as the special untagged case. The commits I've pushed follow this road by making it explicit that the stake key is only one of the possible credentials (and the only one supported atm). Let me know if other options are preferred. In addition, I've also encoded directly the limit for weights in the cddl data format and added some clarifications about the |
Update CIP-15 to support the latest requirements for Catalyst and Voltaire, namely the ability to delegate one's rights to vote to (possibly multiple) representatives and/or expert voters.
Not sure if this is the preferred way to update an already existing CIP, but in this case it's closely tied to a specific use case and the old version would not be used anymore.