CIP-1694 | Guard security-relevant protocol parameter changes behind SPO votes

[WhatisRT]

These changes came out of recent discussions with security researchers. Guarding certain parameters behind SPO votes results in preserving the current security and liveness properties of the system without having to make further security assumptions.

This is WIP for now, since I'm not sure yet whether the list of parameters guarded behind this extra condition is final.

[lehins]

We'll need to add this new parameter to the list of security params: IntersectMBO/cardano-ledger#3952

[Ryun1]

Whilst we are editing CIP-1694, would it be possible to add a note about script-based constitutional committee credentials?
As these made it into the ledger design post the CIP, and I have found that most people are unaware of these credentials because of this.

[WhatisRT]

I've added that CC members can be scripts, that the new PParam minFeeRefScriptsCoinsPerByte is security-relevant and fixed the outdated claim that we go into no-confidence when we don't have enough active CC members.

[Hornan7]

If this can be done at the protocol level, you should add dvtMotionNoConfidence and pvtMotionNoConfidence to this list as well and remove the CC rights to vote on these 2 parameters that were designed originaly to remove them.

They already cannot vote on "Motion of no confidence" and "Update Committee" governance actions, for obvious reasons. Which is why I think, their right to vote on these 2 parameters should be given to SPOs instead in my opinion. 😄👍

[lehins]

Unfortunately that can't happen due to technical reasons, since dvtMotionNoConfidence and dvtMotionNoConfidence are not individual protocol parameters, but instead they are thresholds that are part of a threshold set, as such they can't be voted on individually. In other words, whenever a proposal is submitted that updates Stake Pool or DRep thresholds, all of the thresholds must be provided.

Moreover, drastic changes to the CIP are not possible at this stage.

The formal specification is complete and undergoing the audit at this point. Any changes right now will cause a significant delay to the release.

That being said, if you believe such functionality is very important, feel free to submit a CIP for the next era.

[thenic95]

Thank you for this explanation @lehins
Would you happen to have more information on the mentioned "threshold set" and what they contain?
Are the sets the different governance action thresholds for DReps and SPOs?

[lehins]

There are two separate protocol parameters one for DReps and another for Stake Pools. Both of which contain all the relevant thresholds.

[Hornan7]

Would you happen to have more information on the mentioned "threshold set" and what they contain?
Are the sets the different governance action thresholds for DReps and SPOs?

@thenic95 Here are the 2 "threshold set" grouped in square brackets:

What he meant is:
when you submit a PP governance action, you have to include all Protocol Parameters of the same "set" in the proposal file even if you change only one parameter from the same "set".

Thanks for the info @lehins 🥇

[Ryun1]

I have forwarded this PR to the Intersect governance parameter working group for comment :)

[Hornan7]

The only thing I would add is that, since we have the CC and Dreps votes on govActionDeposit already, I don't think adding SPOs votes would be nessesary. Unless we end up with no Committee at all.

But in that case, if you see this as a security issue, why all other deposits wouldn't be equally at risk? If risk there is. (dRepdeposit, poolDeposit, keyDeposit)
Because technicaly speaking, if the risk of having govActionDeposit not being protected by SPO would add the possibility of someone raising it to stall governance on Cardano, what would hold em to do the same with DReps deposit, Stake pool deposit, stake key deposit and hold anyone else from registering as a DRep, SPOs or their own stake credentials?

I can understand the importance of adding layers of difficulty to all other ones though (Transaction related ones), but I really don't think govActionDeposit is a big of a deal.

[WhatisRT]

This list of security-relevant parameters comes from multiple sessions with security researchers where we analyzed how the chain might break if certain parameters were set to bad values. There were some strict criteria for a parameter to be included, one of which being unrecoverability. govActionDeposit is unrecoverable if set too high: set it to a number over the total amount of lovelace in the system and you can never propose a governance action again. Other deposits don't have this problem, and they don't affect anyone who isn't already registered. There are issues with raising these too high, but the change is reversible.

While this may sound unrealistic, the point of the security-relevant parameters is to cover all possible attacks that satisfy these criteria. You only need to trust the SPOs to trust that the chain will not suffer from these attacks, no matter what happens with DReps & the CC.

[rphair]

Positive feedback from stake holders confirmed at CIP meeting today.