CIP-0182? | Optimistic Constitutionality

[ptrdsh]

This CIP introduces Optimistic Constitutionality, changing how governance actions are approved under CIP-1694.

Overview

Learning from the last nearly 100 Governance Actions onchain, no proposal that DReps wanted approved got rejected by the CC. The CCs effort however was insurmountable despite this perfect agreement.

It turned out that DReps are excellent in filtering wrongful/bad proposals naturally by voting on their personal preference, regardless of constitutionality. This fact can be used to the network's advantage and reduce the cost of constitutional review drastically by borrowing from Zero Knowledge applications, where Optimistic Rollups (TRUE until someone says otherwise) is an effective expensive-verification-mitigation technique.

Optimistic Constitutionality shifts the CC from constant involvement to on-demand oversight, dramatically reducing workload and, among others, providing constructive aid to the ongoing debates around CC compensation.

Changes proposed

Instead of requiring the Constitutional Committee (CC) to actively approve every action, proposals are assumed constitutional by default and move forward unless one CC member raises an objection by voting "No"/"Unconstitutional" - a "constitutional challenge" or veto. If such a challenge occurs, the original CIP-1694 approval process resumes, requiring full CC voting and the other CC members then either confirm the veto-ing CC's challenge by voting no/unconstitutional as well, or overrule it by voting yes/constitutional with the defined majority threshold.

The required change is happening in the ledger logic for ratification, which is changed to:

$$\text{RATIFIED} \iff \left(V_{\text{CC}}^{\text{no}} = 0 \;\lor\; \frac{V_{\text{CC}}^{\text{yes}}}{|CC|} \geq T_{\text{CC}}\right) \wedge \left(\frac{S_{\text{DRep}}^{\text{yes}}}{S_{\text{DRep}}^{\text{active}}} \geq T_{\text{DRep}}\right) \wedge \left(\frac{S_{\text{SPO}}^{\text{yes}}}{S_{\text{SPO}}^{\text{delegated}}} \geq T_{\text{SPO}}\right)$$

RATIFIED = (zero CC no votes exist **OR** (CC Yes votes ≥ CC threshold)) **AND** (DRep Yes stake ≥ DRep threshold) **AND** (SPO Yes stake ≥ SPO threshold)

And, the introduction of a new protocol parameter ccOptimisticEnabled :: Bool to control whether Optimistic Constitutionality is active or not, is helpful.

Path to Active

This CIP requires additional code in the ledger, and can only be activated with a hardfork. Due to this, it will be beneficial to let the ecosystem vote on this via an info action, as this change will be packaged within a fork containing countless changes.

Possible Action NOW:
In order to not wait for the hard fork after the next hard fork to activate this and alleviate the CCs current pain, there is nice "soft activation" path forward, which could double as testing/confirmation period:
An info action, in which the CC announces it will from now insta-vote yes on everything by default without commentary, and only vote no once they are called or see issues themselves.

RISKS

• sleeping at the wheel
  Given that CC members are, and in fact must, be active community members, "sleeping at the wheel" risks are diminishingly low, as CC members (are assumed) to already follow Cardano Governance naturally anyway. This is additionally mitigated by now massively increased redundancy: Only 1 of (currently) 7 members must vote no.

• power abuse
  CC members could single-handedly block all approved, near-ratified Governance Actions by voting No/ calling out a "constitutional challenge" up until the last block of an epoch. This risk is real, and currently known possible mitigations for it, such as introducing approval window extensions are only increasing complexity a lot, introduce other issues, and overall provide no actual benefit.
  I postulate that the best mitigation for such power abuse would be to acknowledge the risk and rely on state of no confidence posteriori.

OPEN QUESTIONS

• I am not a ledger developer, so the currently contained suggested code changes under "Ledger Rule Changes" critically need to be reviewed. I used Opus 4.6 to generate them.

---

(rendered latest version from branch)

[ptrdsh]

An X user commented:

There is also a 3rd risk which is a hybrid of the 2 you have mentioned. If a constitutional issue is realised too late there won’t be time to stop the GA.

This is my response, and with it, i make a note to myself to need to incorporate such arguments in the CIP, and underline them with quantitative figures, sources where possible.

Fortunately, by now (after ~100 GAs) we know that its not realistic that CCs, DReps and all other community members are sleeping at the wheel simultaneously. "Given enough eyeballs, all bugs are shallow"-kinda thing happening in realtime.
Ask any GA proposer, and you'll hear that they are being "made aware" of constitutional "issues" every. single. time. - not by the CC and in nearly all cases unfounded, but the eyeballs are there.
Read enough DRep rationales, and you'll see that many quote issues with the constitution and reject the proposal because of it.
Its not a valid argument, as AIs cant replace humans in that matter, but loads of people use AI to assess/monitor constitutionality for their own additional personal opinion-building (also publicly available here http://proposalexaminer.cardanofoundation.org btw). Sure, those AIs wont spot intricate detailed violations, as we would hope the CC to be able to spot, but it underlines that "is it constitutional" isnt isolated to the CC at all - automatically.

Point being:
There is plenty of evidence that constitutionality review is more-dimensional than just the handful of people who are overburdened today to formalize a solid review, which in the majority of proposals wouldnt be required at all anyway, since the majority of proposals are constitutional.

OC would lift some/most of that burden, thanks to the ecosystem's collective review powers, which they will do in any case. Collective Intelligence at play and people cant turn off seeing and calling out issues. Its human.

In the end, i think optimistic constitutionality even enhances the quality of the CC and the protection they provides, as it will free them to focus on being the last line of defense, not formality warriors.

[rphair]

Thanks @ptrdsh - this looks like an intelligent & beneficial submission. I understand it will be admissible regardless of implications to "social governance" (see #937) because it's simply a Ledger change. On for Triage at the next CIP meeting — https://hackmd.io/@cip-editors/131 — and just some formatting considerations before general review begins here:

[rphair]

If the "phases" in this section could be converted into a nested bulleted lists, it would be much easier for reviewers, editors, and implementors to work with.

[ptrdsh]

Thank you, I agree. That section is anyway rather weak and would need some edits. Will change the formatting while doing so.

[rphair]

@ptrdsh I've committed the formatting changes so editors can focus on the rewrite issues... just please git pull these in to your working branch so a further git push (without force) will keep everything well documented here 🤓

[rphair]

As with the adjacent item, if the list above could be tick-boxed as it many other CIPs (YMMV [by browser, I hear] for getting this to work with ordered lists) then it could be visualised & processed more easily. Then this particular item can be added to it (maybe nested as a prerequisite of one of the main acceptance criteria).

[ptrdsh]

Nice idea. fully agreed

[rphair]

Since the goal of these is to keep the Path to Active lean, if this is a complex consideration it can be defined in one of the earlier sections and then the "decision" & potential task(s) entered into one of the concise lists in this section.

What the editors / CIP process are trying to avoid are new ideas about the CIP substance being introduced at the "last minute" in the final part of the document.

[ptrdsh]

Yes you're fully right. Thanks for spotting and flagging! Will change

[fallen-icarus]

Should a minority of dReps and/or SPOs be able to flag a proposal as potentially unconstitutional? If they do, the CC would be required to weigh in to over-rule their concern. The flagging thresholds could be ~30%.

[Thomas-nada]

To mitigate the risk of a single CC member sabotaging a proposal at the final block of an epoch, I propose the following modification to the ratification logic:

The Challenge Window ($X$ Epochs)

A Constitutionality Challenge can only be triggered during the first $X$ epochs of a Governance Action’s lifetime.

• Inside the Window: If a CC member votes No, the "Optimistic" presumption is voided. The action immediately transitions to Challenged status.
• Outside the Window: A CC member can still manually change their vote to No at any time for the remainder of the action's life (for transparency/dissent), but doing so will not trigger a challenge if one hasn't already been started.

[thenic95]

The argument could also be made that the DReps are closely monitoring the constitutionality assessments by the CC and naturally would not approve of an action that fails the constitutionality assessment.

[thenic95]

Optimistic Constitutionality aids to dissolve this by dramatically reducing the expected workload

I think the 'reduced workload' is an illusion, as the responsibility for 'catching' unconstitutional governance actions still rests with the Constitutional Committee (CC). CC members will likely continue to review every single action to ensure nothing slips through the cracks; otherwise, they risk being held liable if the treasury is raided. Relying on 'Optimistic' oversight risks a dangerous diffusion of responsibility, where every member assumes someone else is doing the vetting, leaving the door wide open for malicious actors.

Furthermore, I don't think this approach accounts for specific attack vectors, such as draining the treasury or implementing malicious parameter changes. For example, someone could submit a governance action in the final slots of an epoch and collude with the top 10 DReps to vote "yes." If no CC member catches this mischievous behavior in time, the action could meet the ratification threshold without the CC being able to stop it.

In my view, the risk is simply too high to consider this approach.

[rphair]

@ptrdsh looks like your last commit 0e38ae3 takes care of at least half the review points in #1164 (review), still visible above. These would be resolved & abbreviated automatically if committing through the GitHub UI: which is generally easier (only requiring a git pull back into the local fork) & shows useful evidence of peer review... as well as credit which is sometimes significant.

So if you need to make these changes outside the UI (and for the corrections above), can you "Resolve" each of the conversations to help us keep track of the review points that remain? 🙏

[thenic95]

To really simplify this proposal, it essentially changes how the ledger treats non-voting CC members on active governance actions.

Instead of treating non-voting from CC members as a NO, this change defaults the CC to a YES, as long as no CC member actively casts a NO vote. If even one NO vote is cast, the ledger reverts to the current rules, where not voting is treated as a NO.

I see two main risks:

1. Governance Action proposers could submit GAs close to the end of an epoch and collude with DReps to push a change through before any CC member notices it.
2. CC members hold an ultimate veto and could abuse their power by casting a NO vote right before an action would be approved. For example, let's assume a parameter change only obtains the necessary DRep or SPO votes in the last epoch of its lifetime. Because no CC member has voted yet, everyone assumes the action will pass. Then, in the final slots of the epoch, a single CC member votes NO to effectively veto the action, since the other CC members cannot quickly enough cast their YES votes. (Shout out to Megan for highlighting this!)

These are the main attack vectors I currently see.

[rphair]

@ptrdsh we agreed at the CIP meeting today that this should be confirmed a CIP candidate because of the quality & positive direction of the comments made by reviewers so far: on both the technical proposal as well as any implications for the overall governance process.

Next we would need you to respond to all the review points above before progressing this (marking the resolved things Resolved with a note about any change that was made). The comments you've already responded affirmatively to would make a great first update & when editors see that's happened we can pass this around for a second review & maybe put it explicitly on the CIP agenda then.

In the meantime please rename the containing directory to CIP-0182 and update the "latest version" link in the original post accordingly 🎉