Building a private, on-chain, implementation for RetroPGF

[samajammin]

Hello Optimism Collective!

Excited to share plans on a project our team has been working on over the past few weeks.

Our goal is simple - we’d like to add private, bribery-resistant, on-chain voting to Optimism’s RetroPGF rounds.

Who are we?

We’re the core team working on MACI, an on-chain voting platform which protects privacy and minimizes the risk of collusion and bribery. We’re an engineering team within PSE, which is supported by the Ethereum Foundation

You can learn more about MACI in our documentation.

What are we doing?

We’re building a proof-of-concept RPGF implementation that supports private on-chain voting for badgeholders of the Citizens House.

• Thanks to folks at Gitcoin & their work on EasyRetroPGF, we have a purpose-built web app that we’re forking for our frontend
• For the “backend”, we’re essentially swapping out the SQL database for the MACI smart contracts
• For badgeholder verification, we’ve built an EAS gatekeeper contract which ensures only OP badgeholders are eligible to register to vote
• In line with PSE’s mission and inspired by the efforts of EasyRetroPGF, we also open-source all our code in case it’s beneficial for others

Here’s the source code:

GitHub - privacy-scaling-explorations/maci-rpgf: RPGF with MACI

Here’s where were tracking our progress:

MACI team sprint board • privacy-scaling-explorations

Why are we doing this?

In many ways, Optimism’s RPGF rounds are already a massive success. It seems the process worked in round 3 but - like many of you - we see several areas that can be improved.

For one, the RPGF process currently depends heavily on the OP foundation to act honestly and competently. In round 3, the community had to trust that:

• Only badgeholders would be able to submit ballots
• No badgeholder ballots would be censored or manipulated or double-counted
• The final tally of ballots would be calculated correctly

If we think about what security properties are critical to a voting, Vitalik outlined this in his blog post (Blockchain voting is overrated among uninformed people but underrated among informed people) as well as anyone could:

Any voting system requires a few crucial security properties in order to be trusted by users:

• Correct execution: the results (tally of votes) must be correct, and the results must be guaranteed by a transparent process (so that everyone is convinced that the results are correct)
• Censorship resistance: anyone eligible to vote should be able to vote, and it should not be possible to interfere with anyone’s attempt to vote or to prevent anyone’s vote from being counted
• Privacy: no one should be able to tell which candidate anyone voted for, or if they even voted at all
• Coercion resistance: you should not be able to prove to someone else how you voted, even if you want to

Unfortunately RPGF currently fails in all 4 dimensions. As RPGF continues to grow, we think the need to enforce process integrity will be of upmost importance.

Talking with the folks from the OP foundation about, they’ve mentioned some key requirements for future versions of their RPGF stack:

• Provably correct execution - They’d want to demonstrate the legitimacy to community in terms of how ballots are submitted and calculated
• Privacy protection - They want to ensure not just voter privacy, but also vote privacy
  • Why? While voter privacy alone would offer some valuable protection, if the votes are public, there’s the chance that data sleuths would be able to deduce the identity of some badgeholders. e.g. say a badgeholder publicly declares a few projects where they have conflicts of interest. If they are the only badgeholder who does NOT vote for those specific projects, anyone would be able view their public ballot and tie it to that specific badgeholder, thus circumventing this supposed privacy protection
• Collusion resistance - given the money at stake with RPGF, bribery resistance is a key component for any RPGF implementation

What solutions exist?

We reviewed the options in this private voting report: State of Private Voting

It’s great to see an array of private on-chain voting solutions emerging! As you can see from the report, each has a unique set of features and trade-offs with their implementation.

Why did we decide on this implementation?

A number of projects solve some of the above requirements, but again - given the money at stake with RPGF, we feel that collusion resistance (”Briber Protection”, in that report), is an essential component for any RPGF implementation. Currently MACI is the only project with all 3 of these features:

An RPGF MACI integration has the potential to provide several important security guarantees to the RPGF voting process:

1. Correct execution: With MACI, user registration, voting data and poll logic is stored on-chain. While tallying computation is handled off-chain, ZK-proofs guarantee the correct execution of this logic. In this way, we know the result (tally of votes) will be correct, and the results are guaranteed by a transparent process (anyone can verify that the result is correct) .
2. Censorship resistance: With voter verification (via an EAS attestation gatekeeper) and vote submission happening on-chain, there’s no way for anyone (including the OP foundation) to censor any badgeholder votes.
3. Privacy: With MACI’s receipt-free voting scheme, we’re able to ensure that results are transparent, but it is impossible for outsiders to verify how any specific user voted (since on-chain votes are encrypted). Vote tallying takes place off-chain but ZKPs are submitted and verified on-chain, which guarantees votes are counted correctly without revealing the individual votes.
4. Coercion resistance: With MACI’s private, receipt-free votes, this makes cheating (like bribery) much harder. User’s cannot prove which option they voted for, and therefore bribers cannot reliably trust that a user voted for their preferred option. This prevents any bribers from simply reading the transaction data to see which option a user voted for.

Input/Feedback?

We’d love to hear feedback on this plan! The implementation is in-progress but we’re happy to make potential adjustments based on community input.

If there are any badgeholders interested in being user-testers for us, please let us know and we’ll get in touch to schedule an user interview once we have a working demo up and running on a testnet! Feel free to comment here, hop into the PSE Discord (#🗳️-maci channel), hit us up on Twitter/X, or reach out to me directly (sam at ethereum dot org).

Thanks!
Sam

[dmars300]

Hey Sam, I like what you guys are working on
I am quite interested in giving feedback, testing it and helping where I can.
One questions: Could this implementation ensure that Badehgolders don’t vote for their own projects? (without relying on the foundation to do the sampling?)
On the other hand, I have some ideas of running a mini-rpgf round ourselves at Cryptoversidad, we’d like to see if we could implement a prototype of this idea…
Nice work,

[artespraticas]

Nice idea and thanks for sharing. Best to all Optimitics

[samajammin]

I am quite interested in giving feedback, testing it and helping where I can.

Appreciate that! - will follow up with you

Could this implementation ensure that Badehgolders don’t vote for their own projects? (without relying on the foundation to do the sampling?)

Great question. In short, the answer is “yes”, this is solvable, but it’s still an area of research for us (and would require some changes to MACI). Basically we think this would require an additional step, where badgeholders are declaring their conflicts of interest on-chain, then submitting some proof-of-exclusion with their ballot which our MACI ZK circuits can check to confirm that they in fact did not vote for these projects. This would allow ballots to stay private but for us to cryptographically guarantee they did not vote for their own projects.

I have some ideas of running a mini-rpgf round ourselves at Cryptoversidad, we’d like to see if we could implement a prototype of this idea

Sounds awesome! Our team would be happy to help support you on this. This might be an ideal way to run a MACI-RPGF round in production but at lower stakes than an official OP RPGF round. I’ll circle up with you about this

[Carlosjmelgar]

Thanks for sharing this @samajammin!

While I agree with some the reasoning behind protecting voter privacy in RetroPGF, I also believe we should be baking in accountability into round designs. With great power comes great accountability.

@samajammin

• Privacy: no one should be able to tell which candidate anyone voted for, or if they even voted at all
• Coercion resistance: you should not be able to prove to someone else how you voted, even if you want to

Does privacy/ coercion resistance intersect with accountability in any way? I personally feel this can be gamed by tight knight groups that have long term overlap as they capture influence within DAOs and funding mechanisms. Does more transparency allow for community scrutiny to ensure correct execution and censorship resistance?

Hypothetical scenario: Projects A, B, C, D have overlapping badgeholder contributors and those projects compete against projects E, F, G, H (which may or may not have badgeholders as contributors).

How can this implementation ensure that:

1. Badgeholders in projects A-D allocate funding based on impact without favoring their overlapping relationships?

2. Badgeholders in projects A-D don’t cast votes that drag down the median result for projects E-H?

@samajammin

Coercion resistance: you should not be able to prove to someone else how you voted, even if you want to

Some badgeholders vote on behalf of their team/ project/ community. How can those contributors ensure that the badgeholder will cast votes as determined by the group and not change them based on their own measurement of impact?

@samajammin

For one, the RPGF process currently depends heavily on the OP foundation to act honestly and competently. In round 3, the community had to trust that:

• Only badgeholders would be able to submit ballots
• No badgeholder ballots would be censored or manipulated or double-counted
• The final tally of ballots would be calculated correctly

Does more transparency in this process allow for the community to take an active role in reviewing fair and honest participation from all stakeholders?

[gospelofchange]

This is for sure very interesting. I’d be happy to host a call to grease the wheels of conversation about the topic

[LauNaMu]

Hi Sam!
First of all, welcome to the Optimism Collective!

I’m incredibly excited to see more and more teams from the Privacy space joining and contributing to improve the governance infrastructure and tooling at Optimism and solve for concerns that have been identified through rounds. Additionally, as more members of the Superchain and even ecosystems adjacent or that are part of the Optimism Collective are experimenting with their own RetroPGF rounds (which reduces the load for Optimism to shoulder the costs for all public goods in the ecosystem) this new build offers them more privacy as well.

Feedback:

From the four security guarantees that you mention I believe 4 is the least prone to materialize with the current design of the infrastructure/process, and would therefore encourage the prioritization of research to implement proof-of-exclusion to this build.

While bribery is a threat, Badgeholders currently are unable to successfully prove to someone that they voted in a specific direction; to do so, they would need to get their signed ballot from the Agora team or the Foundation, which would require a much more complex set up with multiple stakeholders across different groups with different interests. However, we have seen the importance of being able to verify that Badgeholders are not voting for their own projects/conflicts of interest.

Based on comments from our last Badgeholder meetup, the sentiment was that there is currently a healthy degree of trust in the Optimism Foundation as an operator, and while moving for a decentralized process is in the interest of the Collective as a whole (aligned with the goal to decentralize governance) it seems the more pressing matter is to solve for CoI’s verification.

Additionally, including new rules of enforcement for CoIs seems to be aligned with the incentives that are now in place for Badgeholders to report their CoI publicly, which means that the build will serve to double down on this requirement while preserving the integrity of the process (internally and externally).

EAS would probably be the best tool to register this data on chain with a specific schema, where if people need to update their CoI’s (as happened in the last round) MACI could just look at the latest attestation to generate the proof when validating the signed ballot. Given that the MACI team is already leveraging EAS to gate voting, it may be a low hanging fruit to explore including it into another circuit (maybe).

Questions:

1. On “correct execution” would this build enable more complex calculations for distributions beyond “tallying the votes”? Or would what MACI enable is the building of a DataFrame as described here? Would an additional proof be required to ensure the right calculation was carried out, or is this proof of calculation contained in MACI?

As a Badgeholder, I’d also be interested in being a user-tester for the demo once it’s live.

[samajammin]

Hey folks! For those interested in kicking the tires on this stack, we just deployed a testnet round that’s ready for you to play around with. See instructions here:

MACI

[samajammin]

Hey @Carlosjmelgar - I appreciate the thoughtful comments!

You raise some interesting points that I think get into a core philosophical argument around the question: which is better for RPGF, an anonymous or public voting process? As you point out, there’s many considerations at play here… I’d love to see more broader debate around this & hopefully this project will help encourage this

To the points you raise - I think you’re right. With private voting, there are new risks, such as collusion that would be undetectable due to the inability for the community to scrutinize the votes of badgeholders. There are certainly some advantages to transparency. But on the flip side, as Vitalik mentions in his blog post, having public ballots creates a whole host of other risks, such as powerful lobbying groups that can easily coerce or bribe badgeholders. I think it’s ultimately a matter of tradeoffs that the community should decide on - which risks of collusion are we most comfortable with?

In any case, I think one thing is clear: the current process lacks any of these advantages (transparency/accountability, any guarantee of privacy, coercion resistance, censorship resistance or correct execution). So I think it’s also about experimenting with new approaches that iteratively improve things vs. necessarily trying to build the perfect solution on day 1 (which to the OP Foundation’s credit, seems to be the route they’re taking).

[samajammin]

Hey @LauNaMu - thanks for the warm welcome & the thoughtful feedback!

From the four security guarantees that you mention I believe 4 is the least prone to materialize with the current design of the infrastructure/process

I’m curious why you think this is the case? If I understand, it seems you believe because of potential votes for conflicts of interests (CoI)?

It’s good to know that solving for CoI is seen as a high priority. This is something we can certainly look into with future iterations of this MACI-RPGF stack (e.g. building in a cryptographic proof-of-exclusion).

One thing worth calling out is that (at least from my understanding) this current MACI-RPGF implementation wouldn’t have any LESS protection against CoI from the current RPGF stack, which involved the OP Foundation sampling ballots to see if any badgeholders violated this. This gets more into the details of MACI, which requires a “coordinator” role (which would likely be the OP Foundation in this case, at least to start). The coordinator is essentially the administrator of the round & does have some special permissions, including the ability to decrypt votes (in order to tally results off-chain). You can find more details on the coordinator in that link but essentially: with this current implementation, the coordinator could perform the same style of ballot sampling as they’ve done previously.

While bribery is a threat, Badgeholders currently are unable to successfully prove to someone that they voted in a specific direction

For sure, this is true. But as I’ve tried to lay out above, with the existing RPGF system this comes at the cost of a few other crucial security guarantees (namely censorship resistance & correct execution).

EAS would probably be the best tool to register this data on chain with a specific schema

Yes in the long run I think an approach where badgeholders are disclosing CoIs on-chain makes sense

On “correct execution” would this build enable more complex calculations for distributions beyond “tallying the votes”? Or would what MACI enable is the building of a DataFrame as described here ? Would an additional proof be required to ensure the right calculation was carried out, or is this proof of calculation contained in MACI?

The current MACI implementation outputs the final tally of votes (as opposed to as a DataFrame of ballots) in order to avoid leaking any vote data which could then be tied back to a voter.

In terms of enabling more complex calculations for distributions, that depends on what calculations you’re looking to do. It might be possible to simply take the MACI tally results & perform some post-processing on that result. Or it’s possible that new MACI ZK circuits would be needed (currently we support QV & non-QV tallying). Again, depends on the what specifically you’re looking to do.

As a Badgeholder, I’d also be interested in being a user-tester for the demo once it’s live.

Love it - will follow up with you

[nooblemon.eth]

This is awesome! Very interested in integrating this into our DAO stack for communities building on Lemonade as well. Please sign me up as a tester @samajammin

[andyguzman]

Hi everyone! Reviving this thread to give you few updates

• The MACI team published a technical solution to privately guarantee no conflict of interest. Will this be interesting to pursue? Who might be a good point of contact to discuss implementation details and tradeoffs.
• We’re also releasing a new version of MACI-RPGF with revamped UX/UI! Would anyone here be interested in playing with the prototype and providing direct feedback? Next are the guided-recorded demos:

• Voter sign up
• Project sign up
• Admin demo

Note: I’m Andy, Technical Product Manager part of the MACI/PSE team wish to be more active and involved here!

[andyguzman]

Would love to chat further and get feedback from you / support DAO stack integration