Alternatives to the 3 of 9 multi-sig for CGP approval

Governance
1

As discussed on the governance call of August 19th 2021. @Yaz

Background

  • At present, Celo Governance Proposals need to be approved by a 3-of-9 multi-sig in order to move the referendum stage (see documentation here).
  • This step is intended to prevent whales (large CELO owners) from making a malicious or self-benefiting proposal and pushing it through by reaching quorum and a majority of votes (which assumes that other CELO holders either don’t take enough notice to vote against it).

Challenges

  1. This allows the signers of the multi-sig to exert veto power over proposals (specifically, if 7 or more want to block, they can). This problem is exacerbated because the 9 signers are not currently public.
  2. Making public the 9 signers potentially puts them personally at risk (e.g. to doxing, bribery, etc.).

Comparison with Uniswap

  • Uniswap protocol does not have any multi-sig step to prevent malicious proposals. Governance process here.
  • Uniswap lays out a number of potential “attacks” and allows them to be dealt with by economic incentives, protocol participants withdrawing funds, and the threat of a hard fork. Worth reading here.

Use of a DAO instead of the multi-sig
It was proposed that some form of DAO could control the multi-sig step. To me this seems like an unproven approach that would add further complication and centralisation to the game theory of making proposals.

Recommendations

  1. I suggest that a list of risks and scenarios be built out just as Uniswap has done under “Adversarial Scenarios”
  2. I suggest that a timelock be added after a referendum is approved before the code can be deployed. This at least gives an opportunity for the community to react/withdraw before a malicious approval comes in. It also gives time for a hard fork.
  3. I suggest that a timeline be set for phasing out the multi-sig.

I am interested in hearing from the community on risks present within Celo (but not Uniswap) that would warrant this multi-sig step.

5 Likes
2

Hey, I also agree that there are clear issues with MultiSig approver.

Here is another. potentially simpler suggestion:

  • Lets change the default to be that all upvoted proposals get approved, unless MultiSig explicitly rejects a proposal.

So we switch from “by default rejection”, to “by default approval”. This makes it clear that when Multisig rejects a proposal they took an action to do so and will make it more obvious that they should provide reasoning behind it.

3 Likes
3

Fine, that would be a step in the right direction @thezviad and would be good to do asap. The next step would be to move the multi-sig to the community. The last step would be to get rid of the multi-sig.

D’you want to go ahead and create a CGP?

4

Bumping this! Don’t have specific thoughts on how to improve, but several governance proposals failed to get approved in the last weeks which was pretty annoying and caused a lot of double and extra coordination work

1 Like
5

@tim , there’s a situation here where we have a private (I assume clabs) multi-sig that is not being proactive in approving proposals.

I believe the signers don’t want to be public for doxing reasons.

We clearly need to move away from this. As a first step, can we get the multi-sig substantially moved to public community members? At least then we can unblock the CGP process (where proposals that are getting sufficient votes are then blocked by this inactive multi-sig).

Then we could bring a CGP that makes this mult-sig step be default approve (and the multi-sig can proactively vote to block if needed).

@Patrick , @thezviad , @willkraft , @ebeth , @CalicoKittencat , @Evan-Ubeswap

1 Like
6

Hey thanks for raising this. Speaking here in a personal capacity, and as one of the members of the governance multisig…

First, on what happened this week:

The three proposals that were submitted were not able to be verified using the released CLI. The approvers checked this and asked for a new release of the SDK and CLI. After this happened, one approver approved, and the other approvers weren’t able to verify and approve within the 24hr window. So the proposals needed resubmitting, a 24 hr upvote period passed, then the proposals were approved. I realize none of this detail was shared on Discord, and that’s something we should address.

On the bigger question of governance approvals:

The governance system was built by @asa in a very short space of time before mainnet launch. I think it was an incredible achievement but I think if you ask Asa he would do a lot of things differently if he were to build it again! In the post I’ll focus only on the approval piece…

On the non-technical side, the role of the “approver” on the running protocol is intended to be:

  • Make sure the proposal does what it says: Does the CGP match the code to be executed? Are there any unintended side-effects or ambiguities that are not covered in the CGP? Does the CGP and the code match the discussion on the forum?

  • Make sure the proposal does no harm: It is all too easy to do something that irreversibly and totally borks the network. Are we certain the proposal is not going to break any dapp or part of the core contracts, or cause funds to get stranded, or put the security of the network at risk?

  • Make sure voters can verify the proposal: does the released version of celocli allow a user to look at the proposal and CGP and come to their own conclusions about the above?

What the approvers’ believe their role is NOT:

  • Policy: Making a decision on whether X should receive funds from the community fund – that’s for voters.

  • Quantitative parameter settings: Whether a parameter should be X or Y, so long as either don’t violate the bullets above, should be for voters, not approvers.

Would love to use this as a starting point to codify this role, document it properly, and make it accountable to the community. Input welcome.

On public membership of the multisig: I found a message to Asa from 16 April 2020 suggesting this membership should be public and saying “the community deserves to know who their approvers are”. So I definitely agree and its been a longstanding miss that we haven’t moved on this. This wasn’t intentional – rather that there was a huge roadmap of work to focus on. But we should get this done.

The role is very technical – more like an auditor. This is also a good point to include more individuals in the multisig, and rotate out those who can’t or don’t want to play this role. I do feel it’s an important but narrow part of ensuring Celo’s continued availability and security.

On the technical side, the first thing we should look at is making the approval stage happen alongside the regular voting in the referendum stage. That would give longer for approvals, and allow voting to start earlier and/or shorten the governance timeline by 24hrs. The second decision point is whether we change this to a “veto” as oppose to an “approval”. Again, would love thoughts on this.

1 Like
7

@Pinotio.com The Uniswap links you added are 404s for me. can you update?

8

Hi @tim , I can’t edit the original post from August, so here are the new links (Uniswap moved stuff around):

Uniswap governance process (note they require proposals to be audited, and reimburse costs for that, this seems to me an update to what they had previously written explicitly).

Uniswap adversarial scenarios.

You make a good point that there is this important audit step.

Right now, clabs is acting as the auditor. It seems to me this auditing step needs to be done before the proposal even goes to a vote. It would also seem sensible that the auditor (currently clabs) issue a brief report either approving or rejecting the proposal.

So, is the easiest option for now just to:
a) move the multi-sig approval to before the vote (requires a CGP)
b) make the multi-sig public (swapping members if needed)
c) have the multi-sig issue a short report on each proposal and why it passes/fails.

At the very least, I would think we should do b) and c) immediately (no CGP required). I guess one challenge is that I’m guessing clabs is under-resourced which is why the proposals are not passing (which would require a longer term solution)?

Longer term, it would be worth potentially allowing proposers use external auditors (reimbursable by Celo treasury) and just submitting the audit report with the proposal (and abolishing the multi-sig step) = uniswap style.

9

Right now, clabs is acting as the auditor.

The multisig actually is a range of community members, though some are cLabs team.

It seems to me this auditing step needs to be done before the proposal even goes to a vote.

So on the one hand it kind of is: the approval step happens before the proposal goes to a vote. The first step is upvoting, designed to prevent spam proposals but possibly unnecessary… then approval. The challenge is this window is a fixed 24 hrs which is very tough when approvers span many timezones.

But I am guessing you mean before the proposal is even made? Right now, all Core Contracts deployment changes are audited by OpenZeppelin. They append the results to Celo Contracts Audit - OpenZeppelin blog (or at least, they used to – I will find out if they are being published somewhere else). But the actual contents of the proposals are only created after the audit report is done, and any fixes made, and then those fixes reviewed and signed off. It may be possible to have them involved in auditing the proposal itself. However, I think it’s important anyone in the community can (and does) make proposals, without having an auditor on retainer.

Longer term, it would be worth potentially allowing proposers use external auditors (reimbursable by Celo treasury)

Maybe we can see if Open Zeppelin or other auditors would accept a retainer through the community fund to participate in the multisig.

It would also seem sensible that the auditor (currently clabs) issue a brief report either approving or rejecting the proposal.

I agree about the brief report, and reason for approving or rejecting. That is a good process to have.

10

Ah ok, my misunderstanding. That is fine. Agreed that 24 hours is short and would ideally be longer.

11

Hi @tim who is in the multisig now? Yaz in the call says these people are powerful like congress members who can stop governance without listening to celo community. To me, if uniswap which is a very successful project with lots of attention can not have approvers then why is this step needed???

1 Like
12

+1 on combining approval stage with voting stage. Actually i think all stages (i.e. upvoting, approval, voting) can pretty easily be combined in a single voting stage. Governance is slow enough already and removing unnecessary delays will only help.

I am also strong proponent of “veto” vs “approval”. Imagine if “multisig” became unavailable for some reason (majority owners lost keys, bad code upgrade of multisig contract itself, etc, etc), we would need to do a very complicated hardfork to ever pass anything in governance. Assuming most proposals will be valid anyways, it makes sense for default to be “approved” and to have an ability to “reject” proposals at any time in a week long voting period.

3 Likes
13

I certainly would! We’ve learned a lot since the governance process was designed that I think suggest a less conservative approach. At the time, the world knew a lot less about on-chain governance than it does now, and almost nothing about on-chain governance on Celo. As such, Celo’s governance protocol was deliberately designed to be “defensive” in two ways that we could consider changing.

  1. Proposals are rate limited by the upvote/queue/dequeue mechanism.
  2. Proposals cannot be executed without proactive approval by a quorum of technical experts.

Unfortunately, (1) was designed in a way that adds a lot of code complexity and makes proposal timing hard to reason about, and IMO the simplifications that would come with getting rid of this “feature” strongly outweigh the risk added by not having rate limiting.

However I believe in keeping (2) for now. In the end, governance proposals are not that different from pushing a commit to production, and understanding and verifying the contents of a commit (or a governance proposal) requires specific technical expertise that not all voters will (or should) have. Because of the asymmetries of governance (a single proposal can do more damage than good) IMO it’s worth having this extra layer of defense.

@thezviad’s suggestion of “veto” instead of “approval” is interesting, my feeling is that it would be better if and only if there was rate limiting, otherwise the approvers run the risk of not being able to do proper due diligence on every proposal. Personally I would rather remove the rate limit to simplify things and keep “approval” over “veto”. Perhaps there is a separate way we could imagine overriding the approval multisig to protect against some of the risks he mentioned (e.g. proposals with a “supermajority” can pass without approval).

With respect to the recent approval hiccups, it seems to me that the problem stems from:

  1. A 24 hour window to approve proposals
  2. Some confusion about when that window is (due to the complexity of the rate limiting feature)
  3. Varying levels of responsiveness and engagement from the approvers

I would suggest we take the following actions in the near term:

  1. Investigate combining the approval and referendum stages (I think this can be done easily and safely)
  2. Publicize the names of the approvers, and rotate out those who would prefer to remain anonymous

Longer term, I think we should look into adopting a simpler governance protocol. Obviously changing out the governance contract carries some risk but I think as long as we are very careful we should be able to do it safely.

3 Likes
14

Following up on this thread –

We’re overhauling the governance multisig, rotating out inactive members, and would love to invite community members to join – After this process we’ll publish the new membership list. Please apply here!

You can also track the work to make the approval stage run concurrently with the referendum stage here: Parallelize approval and referendum governance stages · Issue #8734 · celo-org/celo-monorepo · GitHub

2 Likes
15

Another quick update – after a discussion at the governance call in December. We have been working with @ericnakagawa and @willkraft to overhaul the approvers multisig. We have 5 new individuals we are rotating in, and 2 we are rotating out. We are also going to propose new guidelines per this thread for the approval process, and make the bios of approvers public. I’ll send along further updates on this thread when we’ve got them.

1 Like