pallet-maci (Minimal Anti Collusion Infrastructure)

[pajicf]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "pallet_maci.md") and updated.
• A BTC or Ethereum address for the payment of the milestones is provided inside the application.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants at the time of submission.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once we successfully delivered the first milestone.

[CLAassistant]

All committers have signed the CLA.

[pajicf]

Just to clarify the last item on the checklist: "The grant will only be announced once we successfully delivered the first milestone."
Does it mean that we are not allowed to make any public announcements about the grant until the first milestone is delivered?

[Noc2]

Just to clarify the last item on the checklist: "The grant will only be announced once we successfully delivered the first milestone."
Does it mean that we are not allowed to make any public announcements about the grant until the first milestone is delivered?

That’s correct. We recently had a few teams that mostly were interested in the grants announcement and the badge and actually didn’t deliver anything. That’s something we want to prevent (especially if teams also have an on-going token sale or something similar).

[Noc2]

Thanks for the new application. I have a few questions: What zkps are you planning to use? Could you provide more information about the functionality of the pallet or maybe link to some design that you are planning to use? And it would be possible to reduce the price. It’s currently quite expensive for the delivery of only one pallet or are you planning to also deliver the necessary off-chain tools to use the pallet?

[pajicf]

Hi @Noc2 ,

The MACI pallet, as presented in the roadmap of the application, is the first step in building the Quadratic funding platform. One of the first problems we have to solve, before a trustless, fair and decentralized crowdfunding platform leveraging CLR algorithm are vote bribery and user collusion.

The pallet's main task is tracking the state of user votes in anonymous and secure way while making sure the zk proofs are correct and cannot be compromised by any party.

We are going to need to limit the possibility, effectiveness and reliability of any methods used to "buy" a "vote".
To do that, the pallet will have to utilize zero knowledge proofs.
Mostly based on the design originating from this thread, the pallet will use zk-SNARKs. The most similar contender for you to see what we're going to build would be the Ethereum implementation of the MACI design, which you can find here.

Yes, along with the pallet, we will create the scripts and tools needed to interface with the pallet to perform any needed tasks such as message processing, vote tallying, proof generation, proof verification etc.

As for the delivery, keep in mind that although the MACI pallet will be very useful on its own and be applicable to various other projects, it's also part of the broader Quadratic funding platform project in our roadmap and the funds will also partly fund the next stages of the development. We are willing to do this for 36_000DAI and we don't want this number to be a deal breaker, so if you see that you cannot agree to this give us a counter offer and we will do all our best to squeeze it in.

[Noc2]

Thanks for the detailed response. Could you integrate this information and details into the milestone 1 of the development roadmap? In general, the table lists basicly the requirements of the contract, so it’s always nice to have this as detailed as possible and it also makes it easier to get the necessary approval. Also include all the additional work, like scripts and tools. I can not provide a clear counter offer since I don’t know the opinion of the rest of the committee at this stage, but 36k sounds already easier to accept ;-).

[Noc2]

@pajicf Could you ping me once I should take another look at the application?

[pajicf]

Hi @Noc2, yeah it's ready for rereview 🙂

[Noc2]

Looks good to me. I will share it with the rest of the team. Potentially they might ask you to integrate more of the technical specification into the deliverables, but let’s see.

[mmagician]

The application looks good, but before proceeding I would like to understand whether you'll be building a ZKP library from scratch or forking/re-using an already existing repo - and if so which one?

[pajicf]

Hi @mmagician, we're glad to hear that!

Instead of creating a completely new library, we were planning to leverage existing tools to build the snark circuits.
To be more exact, we are planning to write the circuits using language such as iden3's circom or zkSync's zinc and verify the proofs with rust libraries such as bellman.

[mmagician]

I see, thanks. As far as I understand though, you can't just integrate circom into a pallet, right? Where (software/architecture-wise) are the circuits going to be built? Perhaps if you could provide an architecture diagram, that would clear some doubts.

Next point: I guess verification will form part of the pallet. I wonder if perhaps you could leverage existing work in this field that was done for substrate: a groth16 verifier ZeroPool. It would not only speed up your development, but also be a prime example of re-using components from other teams in the ecosystem. Let me know once you've investigated the possibility.

I have read through the related posts & linked articles and I get the concept. Nevertheless, I do have a hard time imagining how the actual implementation could look like, i.e. the public interface of such a pallet in substrate. I would appreciate if you could supply additional details regarding this, as seen here.

[pajicf]

Hi @mmagician , sorry for a slower reply, I was busy during the weekend.

Thank you for asking these questions, It's very important that we are on the same page and clear any existing doubts.

As far as I understand though, you can't just integrate circom into a pallet, right? Where (software/architecture-wise) are the circuits going to be built?

So yeah, you're right, this won't be part of the actual pallet but part of business logic executed off-chain by the coordinator. We marked the deliverable of these tools in the table as "Operation tools". As you can see in the diagram, the proofs themselves are generated off-chain but verified within the pallet.

Next point: I guess verification will form part of the pallet. I wonder if perhaps you could leverage existing work in this field that was done for substrate: a groth16 verifier ZeroPool. It would not only speed up your development, but also be a prime example of re-using components from other teams in the ecosystem. Let me know once you’ve investigated the possibility.

This looks as a good base to build upon, so we can do a spike and try to start and build with this. Thanks for pointing it out!

As for the interface of the pallet itself, here's a rough glimpse how it might look like, as well as a diagram showcasing the usage.

Functions:
Used for creating a new voting round
newVotingRound(coordinator): roundId

Used to end an active voting round
endVotingRound(roundId)

Coordinator address can be updated
updateCoordinator(roundId)

Used to signup users to current round
signUp(roundId)

Used by users to vote
vote(roundId, optionId)

Used by coordinator after generating a zero knowledge proof of
genuinity of vote state
publishNewMessageState(roundId, stateRoot, proof)

Used by coordinator to prove which party got how many votes
publishVoteTally(roundId, proof)

Used to verify the genuinity of the proof
verifyVotes(roundId)

Used to check the total number of votes of parties
totalVotes(roundId)

Getter functions
getCoordinatorPublicKey(roundId)
getTallyHash(roundId)

Config:
Origins which will be allowed to interact with certain functions of the pallet. This allows some implementations to levearge another pallet such as collective and have democratic processes of signup, coordination and such.
SignupOrigin
VoteOrigin
CoordinatorOrigin

State:
Merkle trees containing data about votes
MessageTree // This one is updated by the users
StateTree // This one is updated by the coordinator

[mmagician]

Ok that sounds good. Would you mind integrating the mentioned interface & diagram into the application document itself please?

Also given that for proof generation (and possibly for verification too, as discussed) you will be leveraging existing frameworks, the price seems fairly high. In the end the pallet and ops tools will only serve as "wrappers", as far as I understand (i.e. you're not going to code up the ZKP framework). My suggestion would be to keep it below 30k DAI, especially that it's been a while since you opened the application and other Committee Members haven't accepted it yet.

[pajicf]

Yeah, no problem, I'll update the doc right away.

We cannot reuse these proofs 1:1,

• Verification - we will be doing this as discussed, possibly using ZeroPool's solutions. So this is not just rewriting from Solidity but rethinking optimisation. Most probably we’ll need to do also contribution on ZeroPool because of this.
• Proof generation - We’ll try to reuse some existing code, we won't be making a completely new ZKP framework for this, but it won't be as simple as just creating a wrapper because some public/private inputs will need to change, because of platform differences and such. This is not trivial thing to do.

We are ok to reduce it to 30k DAI and move risk for the zk snark library onto our side because we want to move past this to other pallets as soon as possible, but we'd keep the current time estimate in case the proposed solutions that we'd reuse and save time turn out to not satisfy all the requirements of the product.

[pajicf]

Hey @mmagician @Noc2, is there any update on the grant?

[Noc2]

Sorry for the late reply. Marcin is currently off, he will probably reply next week. It seems the rest of the committee is currently not convinced about your application. Could you maybe specify the deliverables a little bit more? For example which programming language will be used for the scripts? Which offchain tasks can the user do via these scripts or could you specify the zk part of the deliverables better. As you know, the deliverables are basically the requirements of our contract and the committee would like to have them as well defined as possible.

[pajicf]

Hey @Noc2 ,

Yeah, no problem, it is an intricate product and we see why the committee still might not be confident about the grant.
Sorry for this taking so long and our deliveries not being defined well enough, we'll elaborate and define the grant details more thoroughly during the next week and ping you when it's done.

[pajicf]

Hey @Noc2,

We updated the proposal with much detailed deliverables description, and we also divided them into 3 milestones so you could have a much better overview of the development progress. Please let us know if there still needs to clarify some parts additionally. Besides that, I want to mention that we contacted a domestic academic institution focused on cryptography, and they are willing to assist with the zero-knowledge part of this product.

Also, we decided to decrease the overall grant fee grant by 10% (to 27k DAI) to indicate our wish to work on this project.
In the end, we hope this will be satisfying for the rest of the committee.

[alxs]

Looks good to me with the latest amendments and given your commitment. Note that you will have to make an amendment to the application if you end up using a library other than ZeroPool or not using it at all since it's now listed as a deliverable, but this would be no problem at all from my side.

[pajicf]

Hey @mmagician, could you take a look again, are there any changes that we should make to the grant?

[mmagician]

Apologies for the delay, it slipped under my radar.
Thanks for being flexible with regards to the price and the deliverables. I'm happy to go ahead with it. Good luck!

[github-actions]

Congratulations! As part of the Open Grants Program, we want to help winning teams acknowledge their grants publicly. To that end, we’ve created a badge for projects that successfully delivered their first milestone. Please observe the foundation’s guidelines when making any announcements; in particular, don’t announce the grant publicly before you've completed at least the first milestone of the project.

At that point, we will be happy to collaborate on an announcement about the work you’re doing. Please get in touch with us at grantspr@web3.foundation in case you're interested (at least two weeks notice is preferred).

[pajicf]

@alxs @Noc2 @mmagician
I just realised we haven't properly thanked you for accepting our proposal.

We are looking forward to working on this and we'll let you know as soon as our first milestone is submitted.
Thank you and cheers 🥂

[pajicf]

Hi @Noc2, @alxs, @mmagician

Since we started working on this grant, another project which we were working on prolonged. But because we were thrilled to work on the MACI pallet, we tried forming another team to work on the grant. But to no avail, we decided to pause the workings on the grant until the team is freed.

We felt a need to inform you that it won’t be delivered in the agreed time scope and we aren’t sure when exactly we can start working again on it. But the MACI pallet is in no way canceled but simply halted.

We apologise for this, but will surely inform you on our progress when we return to working on the grant.

All regards

[mmagician]

@pajicf Thanks for letting us know.
I would suggest that once you've resumed work on this project, you submit an amendment to the application document (another PR) where you state the new timeline. This way we're all on the same page.
Good luck!

[pajicf]

Awesome, we'll do that for sure, thank you for your understanding.

[alxs]

Hey @pajicf, quickly checking in here - any updates on the project?

[pajicf]

Hey @pajicf, quickly checking in here - any updates on the project?

Hey @alxs, unfortunately zkp parts of the problem in general proved too demanding for our team to tackle at the moment. We are still interested conceptually, but technically won’t be able to work on this in the imminent future.

[alxs]

@pajicf I see, that's unfortunate indeed. Since you don't plan to work on this in the foreseeable future, can we agree to terminate the agreement? You can always reapply if you find the necessary resources, and of course you're welcome to apply with a different project.

[pajicf]

Yeah, we're sorry, thank you for cooperation and when we are able to tackle this problem again, we'll reapply for sure.

All the best