Hashing Gov Polls and Process MIPs onchain

In the Governance Call on 14/05/2020, the MIP process was discussed further and, in particular, the necessity of having Process MIPs (and not just technical MIPs) go all the way to an executive vote on chain was discussed. Here is the tl;dr

Reasons for Executive

  1. Legitimacy
  2. Visibility
  3. Auditability
  4. Alignment of MIP and Governance cycles - i.e. having Process MIPs go through a separate route to ratification may cause havoc here.

Issues with Executive Votes

  1. LFW’s application for Core Personnel Onboarding has passed the Inclusion Poll, and seems likely to pass the coming Governance Poll. However, it then needs pass an Executive, and garnering > 60k MKR in an early-week vote may prove challenging.
  2. It adds cognitive overhead for MKR holders, who now have to vote even more often.
  3. Regular executives without regularly active votes can decrease the security of the hat.

Hashing MIPs

While the reasons for having Process MIPs go all the way to Executive Votes seem far more compelling than the issues this presents, it seems that we should at least create a hash of the document detailing the Process MIP being voted on, so that there is a clear, decentralised audit trail to add to the verifiability and legitimacy claims. We could use the same solution to make sure all governance polls are hashed on chain, rather than relying on the GitHub audit trail as we currently do.

Currently, polls are created here and then displayed on the voting portal when @rich.brown works his magic. The thrust of this forum discussion is to identify the clearest and easiest way to hash these .md files and reference them onchain. @Kurt_Barry recommended this, so perhaps he can weigh in?

Bonus Points: If you have other ideas of how to ratify Process MIPs without requiring an Executive, please feel free to discuss them here.

5 Likes

It has been poorly documented, but a quick note that polls are actually already hashed and available on-chain. To create a new poll, one must call the createPoll method on the polling contract1 wherein a hash of the poll document’s text (ie the content of one of those .md files on GitHub) is emitted as a part of the PollCreated event. So, to verify the poll document text you see on the UI, you could download the raw document (using the button shown below), hash it, and compare it to what was emitted on-chain.

It might also be worth noting that, in principle, GitHub is not a required for this to work. The document could just as easily be hosted on ipfs, aws, etc, and checked against the hash emitted on-chain.

1 links: mainnet polling contract, kovan polling contract

5 Likes

Ok cool - love finding little easter eggs like this. Note, though, that this is only the case for Polls, and not Executive Votes afaict.

@charlesstlouis maybe we then hash the process MIP at the Governance Poll stage, and reference that hash in the executive vote. Is there a better way to secure this attestation @Kurt_Barry?

3 Likes

A simple sha3 hash of the documents should be sufficient.

The main open question in my mind is whether or not we’d like to deploy a dedicated contract to store hash+short description for MIPs, major design decisions, etc. Just having this in the spells is very disorganized at best. Logs are probably fine for polls, which don’t last very long anyway, but storing more lasting and important things explicitly in one place might have convenience and transparency payoffs.

2 Likes