CIP-0175? | SPO Governance Voting with Calidus Keys#1140
CIP-0175? | SPO Governance Voting with Calidus Keys#1140Cerkoryn wants to merge 6 commits intocardano-foundation:masterfrom
Conversation
|
|
||
| #### Signature Payload Derivation (Strict) | ||
|
|
||
| Let `payload` be the CIP-0151 Registration Payload object (the map at key `1` |
There was a problem hiding this comment.
Maybe silly question
Can the Ledger read and interpret transactions metadata?
alternatively to transaction metadata
adding a register_calidus certificate?
similar to how Constitutional Committee Hot Credentials work
and then the same logic could be reused
although it wouldn't be aligned with current Calidus implementations
There was a problem hiding this comment.
Good question. TBH I'm not sure if the Ledger can read and interpret Tx metadata. I had to learn a lot of new things while writing this CIP and that never crossed my mind 😅
I'm not aware of how CC hot credentials work, but that's probably an alternative implementation that should be explored.
There was a problem hiding this comment.
Yeah I wondered the same thing and I suspect it's either not possible or going to be VERY annoying. IMO the path of adding a new PoolCert would probably be the least resistance, for the pool-related ledger state would also be available in that "POOL" ledger rule.
However, that would mean that we cannot re-use the Calidus key registration, which is purely metadata based?
Not sure if this defeats the purpose of this proposal or maybe the actual motivation is to use "some hot key" to do SPO voting (and not strictly Calidus keys)?
There was a problem hiding this comment.
BTW, what had me have a closer look to this CIP was a big similarity between this key registration and usage with the mechanisms that we are going to need for Peras CIP-140 and Leios CIP-164 (both will be registering BLS keys, but those we could use easily for authorizing SPO votes). CC @perturbing
There was a problem hiding this comment.
@ch1bo the thought of having a new PoolCert occurred to me as well, but the existing Calidus keys rely on token metadata and avoid making new certificates or changes to existing ones. It may be better to create a new certificate, but my understanding is that it would basically be a new Calidus/hot key and would make the old ones obsolete.
I'm open to either option, but it's probably worth further discussion. Also it sounds like if we will need new keys for Leios/Peras then maybe there's some opportunity to kill multiple birds with one stone.
Ryun1
added
State: Triage
|
Thank you for this proposal I have marked it as triage for the next CIP editors call 💪 |
There was a problem hiding this comment.
Agreed with @Ryun1: this is a natural step forward into maturity for the overall governance platform. If I recall correctly I think there's already been talk in the SPO & gov communities about how beneficial this would be.
rphair
changed the title
Co-authored-by: Robert Phair <rphair@cosd.com>
Co-authored-by: Robert Phair <rphair@cosd.com>
ch1bo
left a comment
ch1bo
left a comment
There was a problem hiding this comment.
Very interesting proposal and potential synergy with other CIPs that specify new key registration mechanisms.
| - `payload_cbor` = CBOR encoding of `payload` (byte string) | ||
| - `payload_hex` = ASCII byte string of lowercase hex digits encoding | ||
| `payload_cbor`, with **no prefix** | ||
| - `sig_payload` = `blake2b-256(payload_hex)` |
There was a problem hiding this comment.
This quite a funky signature scheme.. why not sign the original bytes (payload_cbor) directly?
Going the indirection via hex encoding, ascii encoding, and then ascii decoding (we can only hash bytes, not text) seems very odd.
There was a problem hiding this comment.
This was intended to match CIP-0151 v2's signing payload definition, which I believe was done this way to help with hardware wallet support.
| - **Reuse of existing standards**: Leverages CIP-0151 metadata to avoid | ||
| introducing a new certificate type. | ||
| - **Operational simplicity**: Key rotation and revocation follow the established | ||
| CIP-0151 nonce and zero-key semantics. |
There was a problem hiding this comment.
I appreciate these two bullets about re-using standards and keys we already have. However, CIP-151 seems to be a standard that is foreign to the ledger and now we aim to introduce it to it. The other comment thread by @Ryun1 may already have identified a challenge with this.
For the SPO user-journey though, this does not matter and we could register the same key in two ways. Although the "scanning metadata" way of CIP-151 could be deprecated if the ledger will keep track of it and expose that part of the ledger state.
|
So calidus keys are ED25519_BIP32 based and were created to have a method to do pool owner votings offchain. Its not limited to votings, calidus keys can also be used for logins, sign. As they can be imported into light wallets via the 24 word mnemonics they can easily be used for all kind of online actions. Eternl-Wallet, Typhon and so have already implemented message-signing for calidus1xxx ids. This all is already working and in a few days also used on ekklesia for SPO voting. Afaik, its not possible for the ledger to read metadata. But, if we can introduce a new Certificate - which is not a PoolRegistration one, SPOs are afraid of those - that would be a nice addition to the system. Calidus keys are hot keys and in there nature designed to be rotated at any point. They can also be revoked. So a new Certificate to Register and Deregister a CalidusKey - which should also be an extended ed25519 one like used right now - that is signed by the pool cold key would be the logical next step imo. For governance on the ledger level we already have a cold/hot system with the cc keys. So, if the ledger can hold this new hot key data and depends the voting results on those instead of the cold keys, that would be a nice shift in the future. There is no need to rush it imo, we can have a couple of spo votes on ekklesia before moving forward with this on the ledger level? I am not opposed to do it right now for sure. |
rphair
changed the title
rphair
added
State: Confirmed
rphair
left a comment
rphair
left a comment
There was a problem hiding this comment.
@Cerkoryn - our goal of continuing improvement of Cardano's governance system was a key factor in accepting this as a CIP candidate at the meeting today. As you also observed there, it will be most important to get early & comprehensive review from Ledger architects to look over all the implications of adding these keys much more intimately than they've been used so far.
@lehins @WhatisRT I hope haven't jumped the gun in declaring this a CIP candidate without going through the customary process of pinging you for a quick confirming review first. There were some other subject experts at the meeting today who agreed that were would surely be some way of doing this even if the spec needs to be fine-tuned or even the whole approach changed... looking forward to your reviews in any case.
@Cerkoryn please rename the containing directory to CIP-0175 and update the "rendered" link to your proposal accordingly 🎉
Co-authored-by: Robert Phair <rphair@cosd.com>
Co-authored-by: Robert Phair <rphair@cosd.com>
5 participants
After brainstorming this concept with the Technical Steering Committee earlier this week I've put together this draft CIP that will allow SPOs to vote on Conway-era Governance Actions by using their Calidus Keys as defined by @Crypto2099 and @gitmachtl in CIP-0151.
This CIP aims to extend the ledger state to index CIP-151 registrations and also complies with the CIP-151 goal of not needing to change stake pool registration certificates.
I believe @gufmar also expressed interest in this CIP during the call yesterday, so feel free to review at your convenience.
(rendered)