High level summary
We have undertaken an initial high-level security analysis of the CIP-1694 design. We summarise the analysis and our responses here.
Initial CIP-1694 Security Analysis and Responses
Section: The constitutional committee
- “For example, if we consider the hypothetical Constitution rule "The Cardano network must always be able to produce new blocks" - In this example, if the governance action to reduce block size to 0 is passed, then there will be no way of passing or enacting further proposals. That is, this governance action is completely non-reversable. Suggestion: Instating a built-in mechanism that checks (and perhaps enforces) that the proposed governance actions, if passed, can be reverted in the future.
There is a 'guardrails document' in preparation which captures issues such as these. Some of them may be automatable, as suggested; others will need to be evaluated by humans.
Section: Size of the constitutional committee
- A possible issue with very large committee sizes (or large number of proposals/voters in general) is that it may take longer to have votes appear on-chain, which in extreme cases may require longer voting periods.
Thanks. Yes, we’ve been thinking about this issue for a long time, see for example the section ‘Final safety measure, post bootstrapping’. We don’t consider this as an issue for the CC since they need to be elected while DReps can just register, so we expect the number of CC members to be much less than the number of DReps
Section: Terms
- The following sentence is a bit awkward to read: “For example, a committee of size five with a threshold of 3/5 a minimum size of three and two expired members can still pass governance actions if two non-expired members vote Yes.” —> Suggestion: “For example, if we have a committee of size five with a threshold of 3/5, then a committee of three non-expired and two expired members can still pass governance actions if two non-expired members vote Yes.”
Thanks. Yes, that suggestion is a bit easier to read.
Section: Registered DReps
- “Additionally, registered DReps will need to vote regularly to still be considered active.” - There is a minor issue with requiring “voting regularly”. That is, if there are no proposals to vote on for a long time, this means that no DRep can vote regularly (or they have to issue bogus proposals just to vote on them).
Thanks. We’ve added a mechanism to prevent that issue in the spec/code where if there’s nothing to vote on for an entire epoch, we increment the epoch that each DRep expires.
Section: Ratification
- It is a bit unclear why protocol changes: network group and technical group are two separate groups.
These correspond exactly to the groups that are administered by the Parameter Committee.
- I didn’t understand the rationale for requiring 100% “Yes” votes to pass “Info” type governance actions? It seems they have the least potential to harm the system.
Yes, it’s not about harming the system, since Info
actions have no direct effect on the operation of Cardano. The motivation is simply to record the actual level of support for the action.
Once an action is enacted it’s no longer possible to vote on it. So if there was e.g. a threshold of 50%, then there is no way of telling whether the support for it might eventually have reached 90% or higher if it was not immediately enacted when the threshold was reached.
Section: Content
- For Hard-fork initiation, the changed parameters should probably also be required as part of Additional data.
Protocol parameters can be changed in arbitrary ways by the hard fork and new ones might be introduced, so anything this action pins down might not actually be the value that will be present after the hard fork.
Section: Protocol Parameter groups
- It is a bit unclear to the reader what some of these parameters mean, for example: monetary expansion (rho) and treasury expansion (tau). Suggestion: Include brief explanations for the non-obvious parameters.
These are existing protocol parameters, described in e.g. https://cips.cardano.org/cips/cip9/9 or The Cardano Protocol Parameters Guide.
- With the current set of governance actions, it seems that it is not possible to add new types of protocol parameters, or categories of governance voting thresholds. Suggestion: Consider possibility of incorporating governance actions that allow addition of new protocol parameters, deletion of defunct protocol parameters, or modification of governance voting threshold categories.
All of this needs to be done via a hard fork. If we had an action that added a parameter then there is no way of giving it semantics anyway, since that must be done by logic in the code.
Section: Votes
- Is a constitutional committee member also a DRep? If so, do they vote twice, once as a committee member and once as a DRep?
They may or may not be (and they could also be an SPO). Note that this is fine, since these are completely separate tallies. This is also not preventable, since we don’t have an on-chain mechanism for identity. And yes, each credential gets to vote on each action for all roles in the governance system it has.
Section: Separation of Hard Fork Initiation from Standard Protocol Parameter Changes
- It is unclear whether there would be automated checks for whether a proposal is indeed a soft fork or hard fork, which would reduce human error in categorising proposals.
There is no on-chain mechanism that could enforce this, the best we could do is some kind of certificate. However, this may not be trustworthy, of course. We will consider this in future versions of Voltaire.
Section: Changes post Edinburgh workshop (July 2023)
- “All governance actions are enacted one epoch after they are ratified.” - I’m not sure if this line is currently in the main body of the CIP?
It is, but it is phrased differently: ‘All governance actions are enacted on the epoch boundary after their ratification.’
Section: Reduced deposits for some government actions
- Another downside of requiring endorsement from the constitutional committee is that this likely does not apply to constitutional committee-related proposals, such as no-confidence votes.
Indeed. We have no plans for this at the moment.