CIP-0175? | Stake Pool Hot Credentials#1140
CIP-0175? | Stake Pool Hot Credentials#1140Cerkoryn wants to merge 13 commits intocardano-foundation:masterfrom
Conversation
CIP-0175/README.md
Outdated
|
|
||
| #### 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.
CIP-0175/README.md
Outdated
| - `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.
CIP-0175/README.md
Outdated
| - **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>
|
I never made the connection that the keys inside the That being said, while I generally like community solutions to problems like this, and while the Ledger could technically look inside the metadata, for a core Ledger feature like this we shouldn't be (ab)using metadata. A certificate works perfectly fine and is relatively simple to add. |
from what I can remember this was discussed - or at least requested by SPOs - several times, before it became a "cold shower" thing. |
|
I think that idea came late in the design phase, and we were running out of release time back in the days. |
Yea, thats the way to go i think. Ledger decision are not based on metadata content. So we need a new registration/deregistration certificate for calidus spo keys. The thing is, with the current metadata solution, its also possible with pool cold keys on hardware wallets to generate the needed CIP8/30 signature and cose key. Such a new certificate would require to also add those functions into cardano-hw-cli and implementing it in ledger&co firmware too. |
|
This came up ad hoc at the CIP meeting today and the number of possibilities still on the table inclined @Cerkoryn to confirm that he will be doing some research & polling to choose which approach to take: including today's additional suggestion of using the BLS keys that must be created by SPOs to support Peras / Leios and will be added natively to the chain soon (cc @ch1bo). Once the desired approach is selected — also considering what @WhatisRT has suggested above — we would then go forward by asking Ledger to re-review. |
|
I would highly recommend to ask @lehins before doing any further ideas on how it could be implemented. BLS keys are not compatible with LightWallet Message-Signing on Cardano. And that was one of the major reasons the currently used Calidus Keys are based on normal ed25519 ones. So all standard tooling can work with those SPO hot keys. Would be a bit strange if we have to run two different SPO hot keys at the same time imo. We need a fast solution, not a complicated one. And nobody knows how long it will take until we see something about Peras/Leios really in the ledger. |
lehins
left a comment
lehins
left a comment
There was a problem hiding this comment.
Please come to next Ledger Working Group and we'll be happy to have a proper discussion about this CIP: https://luma.com/xju4zn8t
Co-authored-by: Alexey Kuleshevich <lehins@yandex.ru>
|
Thank you for the Ledger-WG-Meeting today, here are a few points/toughts of mine: The reason a new additional certificate is more preferable imo:
About the certificate itself:
About the key generation:
|
This is a very good question. For CC members we allow for multiple cold credentials to be mapped to the same cold credential. I think we should follow the same for Stake Pools as well. Implementing for stake pools of this approach will be quite a bit more involved though, when comparing to CC, because for CC we can just iterate over all of the members when we tally up the votes, because CC is usually small. I'll give it a bit more thought in the next few days, when I have a bit more time available for this and will make appropriate suggestions. |
CIP-0175/README.md
Outdated
| - `AuthStakePoolHotKey(poolId, hotCred)` | ||
| - `ResignStakePoolHotKey(poolId)` |
There was a problem hiding this comment.
We can get away with adding only one certificate instead:
AssignStakePoolHotCredential (KeyHash StakePool) (Maybe (Credential StakePoolHot))or in pseudocode:
- `AssignStakePoolHotCredential(poolId, hotCred)`
Nothingcase would remove hoot credential authorization if there was any- while
Justcase would overwrite whatever was there before with a new hot credential
The main benefit of this approach would be reduction in complexity (one certificate vs two) and reduction in necessary validation and contention prevention. With two certificates we would probably have to add some validation against prior state. For example in case of resign we would probably have to check that there was a hot credential there before.
In any case. Simpler is better, IMHO.
We'll also need to describe this as necessary change to CDDL
There was a problem hiding this comment.
This is the same way we handle it with current CIP-151, simply register with a blank "Calidus" key to revoke any previous authorization, cleaner and easier to maintain versus multiple certificate types.
CIP-0175/README.md
Outdated
| 1. A transaction MUST NOT include more than one of these certificates for the | ||
| same `poolId`. If it does, the transaction is invalid. |
There was a problem hiding this comment.
This is not necessary. It is ok to include multiple certificates with the same poolId`. It will be the last in the list that will be the final value. This is the same approach we use for all certificate, so no reason to deviate for this one.
CIP-0175/README.md
Outdated
| 2. A transaction MUST NOT include any SPO governance vote for `poolId` if it | ||
| also includes one of these certificates for `poolId`. If it does, the | ||
| transaction is invalid. |
There was a problem hiding this comment.
Why not?
It's ok for CC member to authorize hot credential and immediately use it int he same Tx
I don't see this as a problem. If that is the intention of the stake pool owner then so be it. Even if we require a witness for hot credential a stake pool could authenticate a multi sig that doesn't require any witness at all, in which case anyone in the world would be able to vote for that pool. Or the owner of stake pool A could authenticate 1of2 multi sig native script where one is owned by pool A and the other by pool B, which would allow pool B to vote on behalf of pool A). So, you can't protect against that. |
hmm |
hmmmmm 🤣 |
AFAIU this will affect Cardano's governance quite substantially by creating "stake pool dReps". Maybe this will not be an issue as long as the hot key can be revoked and a new vote immediately recast? That way if my stake pool dRep votes in a way I don't like, I can still vote directly on the current matter. But given how risk-averse stake pool operators are with their cold keys, we will likely end up with centralized voting power of stake pool dReps. |
I was going to say the same thing, we've "accidentally" created SPO DReps via this proposed CIP but I also don't think that's a bad thing. As written and following the same logic as a CC Hot Authorization you could immediately revoke/change your voting key if your SPO Rep votes in a way counter to your beliefs, otherwise, you can follow someone who you respect and feel has a better sense of the pulse on the right way to vote for those requiring SPO votes. IMO this is a cleaner/better solution than our existing "Always No/Abstain" options for SPOs. |
|
@fallen-icarus |
CIP-0175/README.md
Outdated
| ### Cold Key Override | ||
|
|
||
| For each `(govActionId, poolId)` vote slot, the ledger records both vote value | ||
| and `VoteSource` (`Cold` or `Hot`). | ||
|
|
||
| Overwrite rules: | ||
|
|
||
| 1. A `Cold` vote overwrites any existing `Hot` vote for the same | ||
| `(govActionId, poolId)`. | ||
| 2. A `Hot` vote MUST NOT overwrite an existing `Cold` vote for the same | ||
| `(govActionId, poolId)`. | ||
| 3. A later `Cold` vote MAY overwrite an earlier `Cold` vote. | ||
| 4. A later `Hot` vote MAY overwrite an earlier `Hot` vote, unless a `Cold` vote | ||
| has already been recorded for that pair. | ||
|
|
||
| Effectively, once any cold-authorized vote exists for a given | ||
| `(govActionId, poolId)`, that pair is locked against hot-authorized overwrites. | ||
| This applies regardless of transaction or block ordering history. |
There was a problem hiding this comment.
I'm not sure if this level of complexity is truly needed here. If a pool has a hot credential authorized, they can change this at any time (reverting to null/none or matching their cold credential). So we can then simplify the governance process for SPOs by only allowing votes via an authorized hot credential. This reduces the surface area of attack where an "SPO DRep" (i.e. I delegate my pool's voting power to @gitmachtl) casts a bad vote with his hot key but override the votes for ATADA with his cold key. Likely this would only happen once as I would delegate away from Martin if he did this, but the point still stands.
However, that does raise another issue, if I have a pool and I have voted with a "hot key" that is enabled at the time and alter nullify or change that hot key prior to the next voting snapshot/tally, does that vote count or is changing the hot key also effectively nullifying any votes that have happened between n and n+1 snapshots?
There was a problem hiding this comment.
Still letting allow ColdKey voting gives us an upgrade path without the need that every tool/wallet/hw-wallet is on the same page before we enable all of this.
There was a problem hiding this comment.
Given that a hardfork would be required before implementing this I don't think looking at tools/wallets/hw-wallet being ready for it is the end of the world.
There was a problem hiding this comment.
Also, the idea is that you would have a path to upgrade:
if (!authorizedHotKey) then: coldKeyVotingEnabled
if (authorizedHotKey) then: hotKeyVotingEnabled
if (HotKey === none) then: coldKeyVotingEnabled
But get rid of the complexity that both keys can be used simultaneously/interchangeably due to the complexity of calculating which key is valid/authorized at the time of a vote being cast.
There was a problem hiding this comment.
It can work either way, from the Ledger perspective, so I don't have a strong opinion on what we decide:
- Allow cold key to do the voting and give it higher priority
- or only allow hot credentials do the voting
I think the important point we for this discussion is that:
- poolId will need to be included with each vote, regardless of which approach we will take
- authorization of a new hot credential will immediately invalidate all old votes
Last point is important for the concern that was raised by the @fallen-icarus yesterday when a hot credential gets compromised, there should an immediate way to invalidate all votes made on behalf of the cold key.
Not exactly. We will need to make sure every vote will contain not just the hot credential, but also the poolId. This means, unlike DReps, there would still need to be a vote per pool. This is necessary to prevent an attack where a pool would submit unlimited number of votes by simply rotating its hot credential. So we will still need to track one vote per pool, the only difference will be that if hot crential is supplied in the vote and it matches the authorized one then we require a witness for hot credential, instead of the cold key. @fallen-icarus I am also leaning towards your suggestion where if a cold key was used for a vote then a subsequent vote by an authorized hot credential would get rejected.
@gitmachtl I did bring up this as a question in the meeting yesterday and I tend to agree with you. SPOs need to be actively voting indicating their readiness. We could make HardForkInitiation special and disallow hot credential voting for this action period. Thoughts? |
Based on the above, it sounds like me (ADAM pool) cannot simply piggy-back on the votes of ATADA pool because I would never have access to Martin's hot credential to sign my votes, so this is a bit of a non-issue aside from maybe some troll SPO making it seem like they were part of a larger group although that pool would never cast a vote? |
I guess that would open up the option to have the pool-id in the vote-certificate as an array instead of a single entry. So larger entities with multiple pools could still vote for there multiple pools with one hot key in one go?
Have to think about it, exceptions are always a bit confusing. Atm for me personally it would feel better to simply disallow using other ones hot hashes that simple. I am not sure if creating such as a SPO-Drep is a good or a bad thing tbh. This may need some input from other "governance" people? |
Correct ADAM pool using hot credential of ATADA pool would not automatically receive ATADAs votes. ATADA would have to actively cast a vote on behalf of ADAM pool. So, in a sense it could be viewed as "SPO DReps" in a sence, except such DReps would have to actively vote for each of their delegators |
No need to complicate things. They can just cast multiple votes in one transaction
I think you are missing my point. By allowing hot credentials, we allow scripts, which can be used to bypass this "uniqueness" protection that you are thinking of. As the simplest example, imagine 3 separate pools
All three hot credentials will be different, but all of them can be satisfied by |
|
It makes sense yes, i'am still not sure if - as i have said in the call - enabling scripts for this is a good thing or not. 👀 But i will not decide this. 😄 |
This seems pretty easy though. Can't you fit ~150 votes in one tx? It would also be public which pool ids are delegated to your hot key so this seems easy to auto-generate the required tx(s). If ATADA actually wants to be an SPO DRep, they would likely do this. |
I will not be a SPO Drep lol 😄 I am not voting in behalf of other SPOs... but thx. 🤣 |
This seems like a net benefit rather than a drawback (if any SPO is willing to serve in this capacity on behalf of stake pools that they do not control for whatever reason) and, it's contingent on both parties agreeing to the relationship so it's not as though I can force @gitmachtl to vote for me. |
|
I'm not saying that I like or endorse such setups, but there will definitely be a group of stake pool constellations where the SPaaS guy will appreciate the option to save time and customer costs by casting everything at once instead of dealing with many pools and cold keys. Question is then if this would increase the voting participation and clarity on things like HF support |
|
Removing |
rphair
added
State: Confirmed
|
@lehins I have on my calendar that there is a Ledger WG meeting today, presumably as a continuation of our discussion of this CIP. However, I don't seem to have a link or invite to the meeting 😅 If it is happening still, would anyone mind shooting me the link to join it? |
@Cerkoryn Sorry, I was unavailable last week during the regular time of the event, hence it wasn't scheduled last week and will happen this week instead Apologies for the short notice. We'll be holding a Ledger Working Group in 4 hours. If you could make it that would be awesome. We could discuss this CIP further. |
CIP-0175/README.md
Outdated
| - the pool cold key witness, or | ||
| - a witness that satisfies the currently authorized hot credential. |
There was a problem hiding this comment.
I'd suggest doing the same thing as with CC members, only cold key can authorize new hot credentials. If we don't do that it will require a bit of work:
- Support for Plutus scripts will need to be implemented for this new certifying approach
- Certificate will need to be explicit which hot or cold is to be used for authorization, since "either or" will not be automagically inferred by the ledger
CIP-0175/README.md
Outdated
| ### Certificate CDDL | ||
|
|
||
| ```cddl | ||
| ; Numeric certificate tag allocation is TBD in Conway ledger CDDL integration. |
There was a problem hiding this comment.
Conway will definitely not have this feature implemented
| ; Numeric certificate tag allocation is TBD in Conway ledger CDDL integration. | |
| ; Numeric certificate tag allocation is TBD in Ledger CDDL integration. |
CIP-0175/README.md
Outdated
| 4. A transaction MAY include SPO governance vote(s) for the same `poolId` as | ||
| one or more `AssignStakePoolHotCredential` certificates. |
There was a problem hiding this comment.
I am not sure what this point really means. Could you please elaborate. Maybe an example will help?
There was a problem hiding this comment.
I think I was thinking that you could vote and create a hot credential in the same Tx, but based on your comment for point #5 I think it's fine to let the ledger automatically inherit this property. I will just remove both points for simplicity.
CIP-0175/README.md
Outdated
| 5. Same-transaction vote authorization for `poolId` MUST evaluate against the | ||
| hot credential state resulting from certificates that appear earlier in that | ||
| transaction's certificate list. |
There was a problem hiding this comment.
Submission of votes is processed after certificates are processed, so this property will automatically hold. Just pointing out that it might be worth mentioning it here
There was a problem hiding this comment.
Since this is an inherent property of the ledger I think it's simpler just to leave it out.
CIP-0175/README.md
Outdated
| For each vote with `Voter = StakePoolVoter poolId`, authorization succeeds if | ||
| either of the following holds: | ||
|
|
||
| 1. The transaction includes a valid witness by the pool cold key for `poolId`. | ||
| 2. `poolGovHotCreds[poolId] = hotCred` exists and transaction witnesses satisfy | ||
| `hotCred`. |
There was a problem hiding this comment.
That's not the right approach. We need to try to be deterministic in this.
A better way would be for Voter to be changed to:
| StakePoolVoter !(KeyHash 'StakePool) (Maybe (Credential Hot))And semantics would be:
- If hot credential is present then witness for it is required
- otherwise it is the cold key witness is required
In the first case Ledger would ensure that credential matches the one in the stake pool state
10 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)