Infimum application

[rhysbalevicius]

Project Abstract

This application is in response to the anti-collusion infrastructure RFP.

The goal of this proposal is to provide a minimum viable implementation of Vitalik Buterin’s proposed “Minimal Anti-Collusion Infrastructure” as a substrate pallet and CLI (for performing off-chain work, i.e. encrypting votes, processing messages, and generating proofs).

The scope of this proposal is intended to be a proof of concept, of which contributes to the development of a genuine minimal anti-collusion infrastructure within the Substrate ecosystem.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

---

Additional comments

I am aware that there is an existing open application in response to the RFP. I’m not sure what the proper etiquette is in this case, so please feel free to let me know if I should close this application in light of the existing one, and potentially re-open it in the future should it become appropriate.

I am also aware that there have been two previous applications for this RFP which had been accepted but then terminated due to lack of progress, and so it’s worth mentioning that the estimated timeline proposed in this application has been prudently influenced by that fact.

Thanks for your time and consideration.

[github-actions]

CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅

[rhysbalevicius]

I have read and hereby sign the Contributor License Agreement.

[Noc2]

Thanks a lot for the application. This looks good to me, and I will share it with the rest of the team.

[rhysbalevicius]

Hi @semuelle, thanks for the helpful suggested changes. I've gotten those changes in, as well as a few other minor corrections

[semuelle]

Thank you for the application, @rhysbalevicius. I am generally happy to support it, but could you add an example or tutorial that lets users quickly and easily test the architecture, as suggested by the RFP? Also, could you expand a bit on the contraints and limitations you mentioned, e.g. to what extent they are due to the proposed architecture and to what extent they can be improved upon given this architecture? I'd be particularly interested in weighted votes.

I am aware that there is an existing open application in response to the RFP. I’m not sure what the proper etiquette is in this case, so please feel free to let me know if I should close this application in light of the existing one, and potentially re-open it in the future should it become appropriate.

We are always happy to support more than one application/grant per RFP, because, as you can see, not all grants end in a successful delivery.

[rhysbalevicius]

Hi @semuelle, thank you for your feedback.

could you add an example or tutorial that lets users quickly and easily test the architecture, as suggested by the RFP

I've amended milestone 3.2 to include a tutorial and a complementary example poll. Please let me know if this is unsatisfactory or if there are any additional details you think should be added.

could you expand a bit on the contraints and limitations you mentioned, e.g. to what extent they are due to the proposed architecture and to what extent they can be improved upon given this architecture

The intent here is to minimize the level of complexity introduced into the scope of deliverables. By limiting complexity the hope is to help to limit the potential surface area for bugs, provide more of a modular framework to build off of, and thereby provide a solid foundation for future work.

The specific limitation you singled out is not a consequence of the architecture itself, but primarily a deliberate choice to reduce the complexity of the scope of deliverables. In order to permit weighted votes one would need to modify the circuits (delivered in milestone 2.2) used. Support for weighted voting, etc, is proposed under the future work section (2.iii). Ideally, in a “production ready” future v1 incarnation of the system, a coordinator would be able to easily create different types of polls which have weighted, ranked choice, etc ballots.

On the other hand,

• Processing in batches is indeed a consequence of the architecture. In particular, inputs to a circuit must be known at compile time (yet the number of participants may vary from poll to poll). This constraint could potentially be addressed by leveraging “recursive SNARKs” (see future work section 2.ii), or in theory an alternative architecture altogether (see future work section 1.i).

• Use of a trusted setup is a consequence of using Groth16, which is non-transparent. Naturally, improving upon this would rely on introducing a transparent system (this is noted under future work section 2.i).

• The choice for an individual coordinator to have at most one active poll at a time is a consequence of the storage layout (a coordinator may only have a single active set of keys at a time).

The potential solution(s) for each of these has been intentionally excluded specifically for the reasons mentioned above.

[nikw3f]

Thanks for the application. Can you provide more details on how the CLI tool will interface with the Substrate pallet?

[rhysbalevicius]

Hi @nikw3f, thanks for taking the time to review. My apologies for the delayed response.

Can you provide more details on how the CLI tool will interface with the Substrate pallet?

The CLI will mainly rely on polkadot-api as a dependency in order to call extrinsics and query state where necessary.

Within the context of the long term vision for the project we do not see the CLI as the primary way to interact with the system, but the shortest path to providing developers and reviewers alike a way to test the system, as well as dissect the inner workings and flow of interactions. Therefore we plan on designing the CLI to operate as a thin wrapper which consumes a module of functions.

In future work we would like to see this module consumed from within the context of a dApp as we believe this would provide an enriched user experience and lower the barrier to entry in terms of permitting interactions with the system.

Let me know if there are any details in particular you are wondering about.

[keeganquigley]

Thanks for the application @rhysbalevicius and for adding all the details about the pallet's public methods. I'd also be generally happy to support it, but I have one question: Does this mean that weighted voting won't be in the current scope since users can only cast a vote of weight 1?

[rhysbalevicius]

Hi @keeganquigley, thanks for taking the time to review.

Does this mean that weighted voting won't be in the current scope since users can only cast a vote of weight 1?

That’s correct. While the proposed design does not limit this as being added as a feature (and indeed is listed on the roadmap for future work), this was a deliberate choice to limit complexity in the initial version.

To elaborate a bit further on the thought process which went into this decision, the problem I’m trying to avoid is the following: how should “voting power” be decided?

For example, during the sign up phase voters could use a special voucher which encodes their voting power. Alternatively, a coordinator could be responsible for assigning the voting power to individual voters after signup. However, both of these approaches add friction to the overall user experience. Moreover, they are opinionated in how external systems may interface with them, and so in particular I’d like to be careful here in order to avoid limiting potential integrations.

The correct design for a flexible but sufficiently powerful interface does not seem immediately obvious to me and requires additional deliberation (ideally with feedback from the community). Since this feature could instead be built on top of a system which provides uniform voting power this seemed like the clear choice in order to move forward.

That all being said, I can definitely appreciate why this feature would be important to the community, and since it’s been brought up a second time now I’m wondering if excluding it would be considered a dealbreaker. I’m definitely open to suggestion for potential amendments to the proposal which address the above concerns!

[keeganquigley]

Thanks for the clarification @rhysbalevicius I'm willing to approve it as is and give it a shot.

[semuelle]

Thank you for the updates and the responses, @rhysbalevicius. Happy to proceed.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[rhysbalevicius]

Thank you for the updates and the responses, @rhysbalevicius. Happy to proceed.

Wonderful. Thank you all for the support 🎉

[keeganquigley]

Hi @rhysbalevicius how is milestone 1 coming along?

[rhysbalevicius]

Hey @keeganquigley. M1 is coming along well, just doing a bit of final clean up before submitting for review. You should expect to see a PR from me this week!

[keeganquigley]

Hi @rhysbalevicius are you making progress on milestone 2?

[rhysbalevicius]

Hi @rhysbalevicius are you making progress on milestone 2?

Hey @keeganquigley,

Progress is being made on M2, albeit at a slower pace than anticipated. There are some ongoing personal circumstances that have unfortunately reduced the frequency at which I am able to contribute to the project.

I anticipate submitting M2 for review sometime early to mid-next quarter.

[keeganquigley]

Thanks for the update @rhysbalevicius much appreciated. That's no problem, but in this case we would ask for an amendment PR to be submitted, since this will likely affect the timeline of M3 as well. Could you simply amend the application to modify the declarations of total duration and milestone durations? The PR will need to be approved by the committee but it should happen relatively quickly. By changing these to a more realistic timeframe, that should take the pressure off. Thank you!

[PieWol]

Hey @rhysbalevicius ,
it's been a while since we heard from you. After checking the latest amendment to the timelines it looks like the second milestone is already a few months overdue. Do you have any updates to share with us by now?
In case you chose to work on different projects and lost track of this grant then we will go ahead and terminate it.

Looking forward to hearing from you.

[rhysbalevicius]

Hi @PieWol, I greatly appreciate the ongoing patience with the timeline for this project.

In retrospect the amended timeline proposed was ambiguous but was intended to extend until this quarter, my apology for the lack of clarification.

At any rate, I am in the process of wrapping up the current milestone and will be submitting it for evaluation during the first week of December.

Thanks again,
Rhys