General Grant Proposal

• Project: RSA GitHub Wallets POC
• #11

Project Overview 📄

Overview

Use the RSA signature that GitHub supports to generate off-chain zk proof from the commit message or pull request data, just like how zk email generate the proof from email payload. Use the zk proof to integrate with AA wallet and perform operations. The circom circuits supporting succinct RSA signature proof is already made by zk-email. We can also use their relayer to generate and submit proofs to the AA bundlers.

Project Details

Provide as much detail as possible about the project's expected final state.

• Scope of Work: PoC, Blog Post or Spec on HackMd

• Key Features

  The RSA GitHub Wallets POC project integrates several core components to create a seamless and secure system for authorizing transactions via GitHub operations:

  • GitHub User/Wallet Account Owner: Users hold GPG keys to submit signed commits to GitHub. These signatures are used to generate off-chain zk proofs for on-chain verification.
  • Relayer: A crucial component that listens to commit events, parses commit messages, and generates zk proofs from them. The relayer then submits these proofs to the AA bundler. Additionally, we will experiment with the possibility of using GitHub Actions as part of the CI/CD pipeline to execute relayer tasks.
  • Wallet Account on Chain (AA Smart Contract): This on-chain component verifies the zk proofs generated from signed commit messages and executes the corresponding user operations (userOp).

• Use Cases and Potential Impact

  • Developer Transactions: Streamline project financing by allowing developers to authorize transactions directly from GitHub.
  • Collaborative Funding: Facilitate collective fund management through shared AA wallets, with transactions authorized by GitHub activities.
  • Community Incentives: Encourage open-source contributions by enabling commits or PRs to trigger payments from a project's AA wallet.

• PoC/MVP or other relevant prior work or research on the topic

  • ZK email and ZK email wallet

Team 👥

Team members

• Hung
  • Email: [email protected]
  • Telegram: lilioo826
  • Discord: lilioo826

Team Website

• N/A

Team's experience

• Skills Required: typescript, solidity, rust, zk
  The portfolio page of the team member: https://lilioo826.notion.site/lilioo826/Portfolio-89deb16b44f24c568a5994c52bcdaf64
  • Completed a PSE grant project on Semaphore before involving skills and knowledge for typescript, solidity, zk
  • Built an MPC wallet project in rust
  • work as full-time blockchain developer at [native.org](http://native.org). Mostly using typescript and solidity at work

Team Code Repos

• not created yet

Development Roadmap 🔩

Overview

• Total Estimated Duration: 3 months
• Total Estimated Working Hours: 240 hours
• Full-time equivalent (FTE): 0.5
• Expected Start Date: TBD
• Expected End Date: TBD

Milestone 1: Research and Design

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated Delivery Date: TBD

Deliverables:

1. Background Research: Conduct research on existing solutions and technologies related to off-chain zk proofs and GitHub GPG key signatures.
2. System Design: Develop a detailed system design document outlining the architecture and components of the RSA GitHub Wallets PoC.
3. Specification Write-up: Create a comprehensive specification document for the project, including technical details and requirements.

Milestone 2: Circuit Development

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated Delivery Date: TBD

Deliverables:

1. Circuit Implementation: Develop and implement the circom circuit for verifying GitHub GPG key signatures.
2. Testing: Create a test suite for the circuit to ensure its functionality and robustness.
3. Documentation: Provide detailed documentation on the circuit design, implementation, and usage.

Milestone 3: Relayer Development

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated Delivery Date: TBD

Deliverables:

1. Relayer Implementation: Develop the relayer component to listen for commit events, generate zk proofs, and submit them to the AA bundler.
2. GitHub Actions Integration: Experiment with integrating the relayer into GitHub Actions for automated execution.
3. Testing and Documentation: Create a testing guide and documentation for the relayer.

Milestone 4: AA Wallet Setup

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated Delivery Date: TBD

Deliverables:

1. AA Wallet Configuration: Set up an Account Abstraction (AA) wallet to accept zk proofs and execute transactions based on the verified commit messages.
2. Documentation: Provide detailed documentation on the AA wallet setup, configuration, and usage.

Milestone 5: Integration and Testing

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated Delivery Date: TBD

Deliverables:

1. End-to-End Testing: Conduct integration testing to ensure all components work together seamlessly.
2. Bug Fixing: Address any issues or bugs identified during testing.
3. Documentation: Update documentation to reflect the integration process and testing results.

Milestone 6: Finalization and Outreach

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated Delivery Date: TBD

Deliverables:

1. Summary Report: Compile a comprehensive summary of the project, highlighting key findings, challenges, and future directions.
2. Blog Post: Write a blog post to share the project's outcomes, insights, and potential impact with the wider community.
3. Code Repository: Ensure all code is well-documented, organized, and available in a public repository for community access and contribution.

Additional Information ➕

• Reference Material
  • GitHub commit message signature
    • https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification
  • ZK Email and ZK email wallet
    • https://github.com/zkemail
    • https://github.com/zkemail/email-wallet
  • Account Abstraction
    • A reference implementation of AA: https://github.com/eth-infinitism/account-abstraction
    • AA detailed explanation:
      • https://www.youtube.com/watch?v=B6sN8EXszP8
      • https://reyerchu.com/moodle/pluginfile.php/376/mod_resource/content/13/Decrypting%20ERC4337_%20Technical%20Architecture%20and%20Transactions.pdf
      • https://www.youtube.com/watch?v=MHZ0LwpKcpI

General Grant Proposal

• Project: Tooling to enable micro benchmarks for GPU/MSMs #22

Project Overview 📄

Overview

Implement micro benchmarking tooling for doing MSMs/using GPU on Mobile.

Refer to following for detail

• Proving with GPU on mobile oskarth/mopro#22
• Implement micro benchmarking tooling for doing MSMs/using GPU on Mobile oskarth/mopro#21

Project Details

• implement a basic tooling on real iOS device
• provide documention to benchmarks and instructions to the usage of tooling

Team 👥

Team members

• Names of team members

  • Fu-Chuan Chung
  • Moven Tsai

• Discord handle

  • foodchain1028
  • moventsai

• Email

  • [email protected]
  • [email protected]

Team's experience

• Fu-Chuan Chung
  • PSE ZK Summer Open-source Contribution Program Fellow
• Moven Tsai
  • PSE ZK Summer Open-source Contribution Program Fellow

Team Code Repos

• https://github.com/FoodChain1028/mopro-21

Development Roadmap 🔩

Overview

• Total Estimated Duration: Duration of the whole project
• Full-time equivalent (FTE): Workload of an employed person (see)
• Estimated start date: Jan 11st 2024

Milestone 1: run_msm_bench() development, Arkworks MSM integration, FFI & UDL extension.

• Estimated Duration: 1 month
• Estimated delivery date: Feb 11st 2024
• FTE: 0.6
• FTE for us: 12 + 12

Milestone 2: Swift testing on a laptop, initial performance analysis

• Estimated Duration: 0.5 month
• Estimated delivery date: Feb 25th 2024
• FTE: 0.6
• FTE for us: 12 + 12

Milestone 3: iOS app integration, real-device testing, and benchmarks documentation

• Estimated Duration: 1.5 month
• Estimated delivery date: Apr 11st 2024
• FTE: 0.75
• FTE for us: 15 + 15

Deliverables and Specifications

0a. Codebase

We plan to develop a micro benchmarking tool for further enhancements in mopro project. Therefore, we expect the codebase is suitable to integrate back into the mopro project. We have initiated the main work in gpu_explorations directory in mopro-core.

0b. Documentation

We will ensure that all modifications are thoroughly documented. This includes detailed guidelines in the README for running the tool, along with the initial benchmarks observed on an iOS device. Our documentation will clearly explain the purpose and usage of each component, making it easier for future integrations and enhancements.

0c. Testing Guide

we aim to develope a Swift test to assess initial performance on a laptop. This is a precursor to the more crucial phase of testing on an actual iOS device, which will provide real-world performance metrics. We are outlining a comprehensive testing guide that includes procedures for Swift testing on laptops and detailed steps for running the tool on iOS devices. This guide also establishes benchmarking standards for recording and interpreting performance in various testing environments

Additional Information ➕

We have partially completed Milestone 1, which can be seen here

Open Task RFP for Simpler version of government id backed voting system with FHE

Executive Summary

• Project Overview: Simpler version of government id backed voting system with FHE

Project Details

• Scope of Work: TO BE FILLED OUT
• Expected Outcomes: TO BE FILLED OUT
• Technical Requirements: TO BE FILLED OUT

Qualifications

• Skills Required: TO BE FILLED OUT
• Preferred Qualifications: TO BE FILLED OUT

Administrative Details

• Grant Liaison(s): TO BE FILLED OUT
• Estimated Project Duration: TO BE FILLED OUT
• Project Complexity: TO BE FILLED OUT

Additional Information

• Relevant Tags: TO BE FILLED OUT
• Reference Material: TO BE FILLED OUT

Submission Details

• Proposal Deadline: TO BE FILLED OUT
• Submission Instructions: TO BE FILLED OUT

Open Task RFP for implementing fft lib in many programming lang mul

Executive Summary

• Project Overview: implementing fft lib in many programming lang mul

Project Details

• Scope of Work: TO BE FILLED OUT
• Expected Outcomes: TO BE FILLED OUT
• Technical Requirements: TO BE FILLED OUT

Qualifications

• Skills Required: TO BE FILLED OUT
• Preferred Qualifications: TO BE FILLED OUT

Administrative Details

• Grant Liaison(s): TO BE FILLED OUT
• Estimated Project Duration: TO BE FILLED OUT
• Project Complexity: TO BE FILLED OUT

Additional Information

• Relevant Tags: TO BE FILLED OUT
• Reference Material: TO BE FILLED OUT

Submission Details

• Proposal Deadline: TO BE FILLED OUT
• Submission Instructions: TO BE FILLED OUT

Open Task RFP for Integrate a GPU-friendly proving system

Executive Summary

• Project Overview: Integrate a GPU-friendly proving system
• refer to following for detail
  • zkmopro/mopro#22 (an umbrella issue),
  • zkmopro/mopro#15

Project Details

• Motivation: to speed up proving on mobile
• Scope of Work:
  • integrate the proving system and get a baseline
  • get it to run on GPU
  • Get iOS/mobile GPU work with above work
  • doc
• Expected Outcomes:
• Technical Requirements: Swift, Rust, Proving system, Note this issue has a preliminary stated in mopro 22, which is to at least get it work

Qualifications

• Skills Required: You know Swift, Rust, folding scheme

Administrative Details

• Grant Liaison(s): TO BE FILLEDOUT
• Estimated Project Duration: TO BE FILLEDOUT
• Project Complexity: Medium

Additional Information

• Relevant Tags: Mobile Proving

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Send out issue in this repo and comment under zkmopro/mopro#15 and link back to this issue in your proposal. Refer to proposal template for more details.

Open Task RFP for Combining zkps with FHE to replace bootstrapping.

Executive Summary

• Project Overview: Combining zkps with FHE to replace bootstrapping.
• Detail: There’s one issue that’s inherent in FHE, that is the problem of noise accumulation. After every operation the noise in ciphertext grows. If the noise exceeds a certain threshold, it results in decryption failure. To allow unlimited operations, we can use something called bootstrapping. But bootstrapping is expensive. Alternatively, we can ZKPs with FHE to avoid bootstrapping. The idea is simple. After certain number of operations the server sends the ciphertext back to the client. The client decrypts the cipher text and re-encrypts (hence reducing noise) and sends it back to server along with correct zk-proof of decryption and re-encryption. The server then carries on with the computation. This adds interaction, but can be useful in some applications.

Project Details

• Scope of Work: PoC, Blog Post or Spec on HackMd
• Expected Outcomes: Design several test case to pass roundtrip test
• Technical Requirements: FHE

Qualifications

• Skills Required: FHE
• Preferred Qualifications: N/A

Administrative Details

• Grant Liaison(s): Name, GitHub, email of the person(s) responsible for evaluating and keeping track of this project.
• Estimated Project Duration: Applicant may estimate
• Project Complexity: Medium

Additional Information

• Relevant Tags: FHE
• Reference Material:
  1. https://github.com/yuriko627/zk-fhe-playground

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

General Grant Proposal

• Project: Implement msmAccel trait for sppark-msm and icicle-msm (#32 (comment))

Project Overview 📄

Overview

Implement the msmAccel trait which is mentioned at https://github.com/privacy-scaling-explorations/halo2/pull/277/files#diff-919910df38e231a60a5d3776e9a3f9cf0891a4c414c6b38cd9ba24ae7e6bda84 for Sppark-MSM and Icicle-MSM, and then integrate the msmAccel trait into halo2 at the end.

Team : Langlands

Team members

• 0xhhh
• [email protected]
• @long_hhh

Team Website

• https://github.com/cyl19970726

Team's experience

Participated in the development of Ethstorage's proof of storage and also participated in the development of EigenZkVM. Recently I have been doing research related to msm.

Team Code Repos

*https://github.com/cyl19970726/halo2/tree/zal-intergration

Development Roadmap 🔩

Overview

• Total Estimated Duration: 5 weeks
• Total Estimated Working Hours: 70 hours
• Full-time equivalent (FTE): 0.35
• Expected Start Date: February 26th 2024
• Expected End Date: Mar 30th 2024

Milestone 1: Implement msmAccel trait for Icicle-msm

• Estimated Duration: 2 weeks
• Estimated Working Hours: 30 hour
• FTE: 0.375
• Estimated delivery date: Mar 10th 2024

Milestone 2: Implement msmAccel trait for Sppark-msm

• Estimated Duration: 2 weeks
• Estimated Working Hours: 30 hour
• FTE: 0.375
• Estimated delivery date: Mar 24th 2024

Milestone 3: Use different msm versions (Sppark, Icicle, Cpu) for benchmark test on Halo2 proof-system.

• Estimated Duration: 1 week
• Estimated Working Hours: 10 hour
• FTE: 0.25
• Estimated delivery date: Mar 30th 2024

Deliverables and Specifications

0a. Codebase

We plan to Implement msmAccel trait for Sppark-msm and icicle-msm at the zal-intergration branch of halo2, and then integrates into halo2 at the end

0b. Documentation

We will provide both inline documentation of the code and a basic tutorial that explains how to use different msm versions using different implementations of the msmAccel trait.

0c. Testing Guide

The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests.

0d. MSM Algorithms Integration

icicle
sppark

0e. Benchmark

Benchmark data between Halo2 proof-system using different GPU versions and CPU versions of msm in the same test environment.

Open Task RFP for simple python lookup argument implementation

Executive Summary

• Project Overview: simple (educational) python lookup argument implementation

Project Details

• Scope of Work: implement plookup, Caulk+, baloo, cq, lasso, LogUp+GKR in python
• Expected Outcomes: Implementation and Blog post explaining your work
• Technical Requirements: Python

Qualifications

• Skills Required: Detail the skills and experience that would make a candidate well-suited for this project.
• Preferred Qualifications: Any additional skills or experience that would be a plus.

Administrative Details

• Grant Liaison(s): Name, GitHub, email of the person(s) responsible for evaluating and keeping track of this project.
• Estimated Project Duration: Timeframe for project completion, including any key deadlines.
• Project Complexity: Medium

Additional Information

• Relevant Tags: Lookup
• Reference Material:
  • https://www.youtube.com/watch?v=uGjbczKGm4s&ab_channel=TheBIUResearchCenteronAppliedCryptographyandCyberSecurity

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

Open Task RFP for Mobile GPU Prover

• Overview: This is an umbrella issue covering the follows:
  • #22
  • #23
  • #24
• Instruction
  • Read each sub-issues detail and original mopro repo
  • Submit proposal as issue in this repo and comment in mopro upstream issue (22)
• Reference Material:
  msm
  • https://hackmd.io/@tazAymRSQCGXTUKkbh1BAg/Sk27liTW9
  • https://github.com/arkworks-rs/algebra/blob/master/ec/src/scalar_mul/fixed_base.rs

Open Task RFP for A SNARK to prove X prime numbers exist below Y

Executive Summary

• Project Overview: This project aims to familiarize you with the concept of recursive snark (or IVC) You have to apply the primality test recursively given Y and calculate X. This is more of a project for learning purposes.

Project Details

• Scope of Work: A PoC and blog post
• Expected Outcomes: A PoC and blog post explaining your methodology
• Technical Requirements: Not specific framework

Qualifications

• Skills Required: know snark
• Preferred Qualifications: know recursive SNARK/Folding

Administrative Details

• Grant Liaison(s): TO BE FILLED OUT
• Estimated Project Duration: 100 hr
• Project Complexity: Medium

Additional Information

• Relevant Tags: Recursive SNARK
• Reference Material: Primality test

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

General Grant Proposal

• Project: #18

Project Overview 📄

Overview

This is a project combining ZKP with FHE to replace bootstrapping.

Project Details

The project aims to replace a bootstrapping process in Fully Homomorphic Encryption (FHE) with ZK proof. We aim to write a ZK circuit about the correctness of decryption and re-encryption on the client (trusted site) and integrate it with existing (or newly generated) FHE code. We will make a working program that appears whole FHE processes, specifically the ZK process, replaced from bootstrapping. We will design several test cases for verification of the program. Also, we will write multiple articles about the entire FHE process and our project, and make a final paper explaining our project.

• Language: Rust, C++, Python, Circom
• Theoretical Knowledge: FHE, ZKP

Team 👥

Team members

• Names of team members: YoungWan Kwon (@000wan)
• Email (Required): [email protected]
• Telegram handle: phenol0
• Discord handle: 000wan

• Names of team members: Changmin Cho (@indextree)
• Email (Required): [email protected]
• Telegram handle: indextree
• Discord handle: index.tree

Team Website

• https://zk-strapping.github.io/

Team's experience

• Finished 2023 ZK Summer Contribution Program
• 2nd place on Ethcon Korea 2023: torch2circom, Built upon keras2circom and circomlib. Implemented some mathematical libraries about matrix operations.

Team Code Repos

• https://github.com/ZK-Strapping/ZK-Strapping

Development Roadmap 🔩

Overview

• Total Estimated Duration: 8 weeks
• Full-time equivalent (FTE): 1.0
• Expected Start Date: Jan 15th 2024
• Expected End Date: Mar 10th 2024

Milestone 1: Implementing FFT in ZKP (grant will only be given them for milestone1 for now)

• Estimated Duration: 4 weeks
• FTE: 1.0
• Estimated delivery date: Feb 11st 2024

Since FFT is essential for CKKS scheme, this milestone aims to provide at least working (even if inefficient) real number FFT circuit in ZK. We’ll try to use zkVM or zkLLVM tools for this.

1. We will first learn about zkLLVM or zkVM tools like Nil or RISC0. (For ~1 week)
   • https://docs.nil.foundation/nil/
   • https://dev.risczero.com/api/
2. We will design real-number FFT proof using RISC0, Nil. We’re planning to meet offline and write codes concentratedly. The work process will be shared via Telegram group.
3. Furthermore, we will learn the details and implementations of CKKS scheme. We will write an article about CKKS and upload to our Github blog. (For ~3 week)

Milestone 2 (grant will only be given them for milestone1 for now)

• Estimated Duration: 3 weeks
• FTE: 1.0
• Estimated delivery date: Mar 3rd 2024

We will implement CKKS scheme in ZK circuit if Milestone 1 succesfully ends.

It will include writing zk circuits, designing proper tests, and writing a documentation post in GitHub.

The details will be decided after completion of the Milestone 1.

Milestone 3 (grant will only be given them for milestone1 for now)

• Estimated Duration: 1 week
• FTE: 1.0
• Estimated delivery date: Mar 10th 2024

We will make the final article(paper) about what we’ve done, and upload it on GitHub page.

Additional Information ➕

Milestone 1 repo: https://github.com/ZK-Strapping/zk-fft
Team blog repo: https://github.com/ZK-Strapping/ZK-Strapping.github.io

It's agreed by FHE research team and applicants that the grant will only be given them for milestone1. If the milestone 1 accomplished well the following milestone could be consider to grant.

General Grant Proposal

• Project: #14 PIR for Hash Path Retrieval

Project Overview 📄

Overview

Merkle hash path retrieval using PIR.

Project Details

In most cases, when the hash path is sensitive, applications have to maintain the tree (or have a way to recompute the tree) to compute the hash path privately.

This project aims to mitigate this by using PIR to privately request the hash path for some encrypted index query.

Output:

• Rust library for authenticated data structure operations + private hash path retrieval.
• Document describing design decisions and implementation.

Team 👥

Team member

• Names of team members: Wisdom Ogwu
• Email: [email protected]
• Telegram handle: wmadab
• Discord handle: iammadab

Team member

• Names of team members: Ginika Chinonso
• Email: [email protected]
• Telegram handle: NonsoFrancis
• Discord handle: mikefrancis

Team's experience

We have experience with ZK, FHE, and building complex systems.

ZK:

• https://github.com/iammadab/zk
• https://github.com/Ginika-Chinonso/crypto_primitives.git

Merkle AVL Tree:

• https://github.com/dashpay/grovedb/blob/master/adr/merk-proofs.md
• https://github.com/dashpay/grovedb

Team Code Repos

• https://github.com/builldx/merkle-pir

Development Roadmap 🔩

Overview

• Total Estimated Duration: 4 weeks
• Total Estimated Working Hours: 120 hrs
• Expected Start Date: March 4th, 2024
• Expected End Date: April 1st, 2024

Milestone 1: Design Document detailing mechanism for private hash path retrieval

• Estimated Duration: 2 weeks
• FTE: 0.75
• Estimated delivery date: March 18th, 2024

Here we explore the solution space, settle on concrete decisions and write a document detailing our decision and why we made them.
Some interesting things to explore:

• best representation for the authenticated data structure / are there some authenticated data structures that this won’t work with?
• private construction of full query from the user’s private seed query
  • e.g. user specifies index on the leaf layer and the index for all other layers are privately constructed.

Milestone 2: Rust library implementation

• Estimated Duration: 2 weeks
• FTE: 0.75
• Estimated delivery date: April 1st, 2024

1. Pick a specific authenticated data structure, implement its operations
2. Implement method for privately retrieving its authentication information (e.g. hash path).
   • ability to encrypt query
   • ability to produce encrypted hash path proof
   • ability to decrypt encrypted hash path proof
   • tfhe-rs or sunscreen will be used to implement the fhe logic
3. Add use-case documentation to library readme

Open Task RFP for Porting real-world ML model(s) into ZK

Executive Summary

• Project Overview: Porting machine learning models that are actually used in real-world applications into ZK

Project Details

• Scope of Work:

1. Select a small (such that a powerful laptop can prove) ML model that has been used in real-world applications (no toy problems like MNIST or Boston House Price, etc.)
2. Construct the model in ZK using any DSL/compiler of your choice.
3. Create a minimal demo UI so that people can interact with the model and generate proofs.
4. Measure the performance of the original version vs. the ZK (quantized) version.
5. Document the process, including any difficulties you encounter.

• Expected Outcomes: a demo app, a repo of the codebase, an article documenting the process
• Technical Requirements: Tensorflow/Pytorch, any ZK DSL

Qualifications

• Skills Required: knowledge of Tensorflow/Pytorch, ability to port ML models into ZK DSLs (any of your choice), proficient writing skills
• Preferred Qualifications: professional experience/advanced degree in machine learning is a plus

Administrative Details

• Grant Liaison: Cathie So (@socathie, [email protected])
• Estimated Project Duration: 120 hours
• Project Complexity: Medium, expected to conduct independent research

Additional Information

• Relevant Tags: ZKML
• Reference Material: cryptoidol (not exactly a real-world use case, but at least playable by users)

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

Open Task RFP for Halo2 Soundness Bug Examples

Executive Summary

• Establish a repository featuring small halo2 circuits, each presenting a unique soundness bug.
• This task is reopen for proposal submission, you may reference #15 for technical detail.

Project Details

• Scope of Work & Expected Outcome
  Establish a repository featuring small halo2 circuits, each presenting a unique soundness bug. Each entry should come with an exploiting example to:

  • Educate users on recognizing and understanding these bugs.
  • Advise on avoidance strategies.

• Technical Requirements: halo2

Qualifications

• Skills Required: halo2

Administrative Details

• Grant Liaison(s): @miha-stopar
• Estimated Project Duration:
• Project Complexity: Medium

Additional Information

• Relevant Tags: ZKP, Tooling
• Reference Material: Reference link

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

Open Task RFP for Quantum Computer Canary and Safe Exit

Executive Summary

• Project Overview: Quantum Computer Canary and Safe Exit

Project Details

• Scope of Work: TO BE FILLED OUT
• Expected Outcomes: TO BE FILLED OUT
• Technical Requirements: TO BE FILLED OUT

Qualifications

• Skills Required: TO BE FILLED OUT
• Preferred Qualifications: TO BE FILLED OUT

Administrative Details

• Grant Liaison(s): TO BE FILLED OUT
• Estimated Project Duration: TO BE FILLED OUT
• Project Complexity: Hard

Additional Information

• Relevant Tags: Post Quantum
• Reference Material:
  https://ethresear.ch/t/how-to-hard-fork-to-save-most-users-funds-in-a-quantum-emergency/18901/16

Submission Details

• Proposal Deadline: TO BE FILLED OUT
• Submission Instructions: TO BE FILLED OUT

Open Task RFP for Mobile SNARK Proving Kit

Executive Summary

• Project Overview: Develop a mobile-friendly tool akin to websnark, harnessing GPU and TPU for rapid proof generation.

Project Details

• Scope of Work: TO BE FILLED OUT
• Expected Outcomes: TO BE FILLED OUT
• Technical Requirements: TO BE FILLED OUT

Qualifications

• Skills Required: TO BE FILLED OUT
• Preferred Qualifications: TO BE FILLED OUT

Administrative Details

• Grant Liaison(s): TO BE FILLED OUT
• Estimated Project Duration: TO BE FILLED OUT
• Project Complexity: TO BE FILLED OUT

Additional Information

• Relevant Tags: TO BE FILLED OUT
• Reference Material: TO BE FILLED OUT

Submission Details

• Proposal Deadline: TO BE FILLED OUT
• Submission Instructions: TO BE FILLED OUT

Open Task RFP for Different backends/proving systems for Semaphore v4

Executive Summary

• Project Overview: Different backends/proving systems for Semaphore v4 (maybe implementing it in Rust/Halo2, etc)

Project Details

• Scope of Work: TO BE FILLED OUT
• Expected Outcomes: TO BE FILLED OUT
• Technical Requirements: TO BE FILLED OUT

Qualifications

• Skills Required: TO BE FILLED OUT
• Preferred Qualifications: TO BE FILLED OUT

Administrative Details

• Grant Liaison(s): TO BE FILLED OUT
• Estimated Project Duration: TO BE FILLED OUT
• Project Complexity: TO BE FILLED OUT

Additional Information

• Relevant Tags: TO BE FILLED OUT
• Reference Material: TO BE FILLED OUT

Submission Details

• Proposal Deadline: TO BE FILLED OUT
• Submission Instructions: TO BE FILLED OUT

Open Task RFP for ZK-friendly ML model explorations

Executive Summary

• Project Overview: Explore specific dataset/ML problem that will be looked up in the ML literature and find out which one is more ZK-friendly based on different metrics

Project Details

• Scope of Work:

1. Select a popular ML dataset/problem statement of your choice, e.g. Boston House Price, Iris, etc. (no MNIST)
2. Search in the literature for at least 3 types of ML model architecture that works well on this dataset. Neural networks of different architectures are considered ONE type of model.
3. Define the metrics that you will be comparing the models by, e.g. number of constraints/lookups, performance degrade during quantization)
4. Port the model into ZK to run the benchmarks, using any ZK DSL or ZKML compilers of your choice.
5. Write the final report.

• Expected Outcomes: a research report on the exploration (see reference material), a repo of the codebase
• Technical Requirements: Tensorflow/Pytorch, any ZK DSL

Qualifications

• Skills Required: knowledge of Tensorflow/Pytorch, ability to port ML models into ZK DSLs (any of your choice), proficient writing skills
• Preferred Qualifications: professional experience/advanced degree in machine learning is a plus

Administrative Details

• Grant Liaison: Cathie So (@socathie, [email protected])
• Estimated Project Duration: 160 hours
• Project Complexity: Medium, expected to conduct independent research

Additional Information

• Relevant Tags: ZKML
• Reference Material: Example of benchmarking using MNIST dataset

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

Open Task RFP for RSA GitHub Wallets POC

Executive Summary

• Project Overview: We can add RSA sig into git commits or PR as git supports it. Using that, we can use GitHub as our signature publishing tool for some transaction and combine that w/ an AA account together
• Details: GitHub supports RSA signature via GPG key. Upon performing actions, such as sending commits or PRs, we can use the signature to generate an off-chain zk proof, and submit the proof on-chain to trigger an AA smart-contract (Wallet Contract). After any action is performed on GitHub, anyone who has access to the commits and their signatures can generate the userOp to trigger the wallet contract through AA pipeline. Note that the wallet contract requires to have access to the RSA public keys in advance. The circom circuits supporting succinct RSA signature proof is already made by zkemail. We can also use their relayer to generate and submit proofs to the AA bundlers.

Project Details

• Scope of Work: PoC, Blog Post or Spec on HackMd
• Expected Outcomes: Show case several scenarios where the smart-contract responds to the signature generated on GitHub.
• Technical Requirements: typescript, solidity, rust

Qualifications

• Skills Required: typescript, solidity, rust, zk
• Preferred Qualifications: used zkemail SDK before

Administrative Details

• Grant Liaison(s): @ETHorHIL
• Estimated Project Duration: 150 hr
• Project Complexity: Hard

Additional Information

• Reference Material:
  • A reference implementation of AA: https://github.com/eth-infinitism/account-abstraction
  • AA detailed explanation:
    • https://www.youtube.com/watch?v=B6sN8EXszP8
    • https://reyerchu.com/moodle/pluginfile.php/376/mod_resource/content/13/Decrypting%20ERC4337_%20Technical%20Architecture%20and%20Transactions.pdf
    • https://www.youtube.com/watch?v=MHZ0LwpKcpI

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

General Grant Proposal

• Project: simple (educational) python lookup argument implementation #20

Project Overview 📄

Overview

simple (educational) python lookup argument implementation

Project Details

• implement plookup, Caulk+, baloo, cq, lasso, LogUp+GKR in python
• provide

Team 👥

Team members

• Names of team members
  • Yu-Ming Hsu
  • Jing-Jie Wang
  • Paul Yu
  • Harry Liu
• Discord handle
  • cornercorn_yuming
  • jingjiewang
  • nooma42
  • harryx1x1

Team's experience

Yu-Ming Hsu

• 2nd author of HeadStart: Efficiently Verifiable and Low-Latency
  Participatory Randomness Generation at Scale

Jing-Jie Wang

• Author of Securing Fair Loot Box Games: An Efficient Approach to Verifying Loot Box Probability Statement Without Source Code Disclosure
• 3nd author of HeadStart: Efficiently Verifiable and Low-Latency
  Participatory Randomness Generation at Scale

Paul Yu

• PSE ZK Summer Open Source Contribution Fellow

Team Code Repos

• https://github.com/NOOMA-42/pylookup

Development Roadmap 🔩

Overview

Terminology

• Total Estimated Duration: 2 months
• Full-time equivalent (FTE): 0.5
• Start date expected to be Nov 15th 2023

Milestone 1: cq, plookup, Caulk+, Baloo (Univariate Commitment)

• Estimated Duration: 1 month
• FTE: 0.5
• Estimated delivery date: Jan 15th 2024
• FTE for us: 8+5+12

Milestone 2 multilinear KZG or Hyrax (Multivariate Commitment)

• Estimated Duration: 0.5 month
• FTE: 0.5
• Estimated delivery date: Feb 1st 2024
• FTE for us: 8+5+12

Milestone 3 Lasso, Logup + GKR

• Estimated Duration: 1 month
• FTE: 0.625
• Estimated delivery date: Mar 1st 2024
• FTE for us: 8+5+12

Deliverables and Specifications

0a. Codebase Specification

We aim to implement baseline protocol according to paper and will not implement extra optimization over it. Take cq for example, our code covers FK algorithm for faster amortized kzg proof but won't implement optimized multiscalar multiplication (msm) because we purely rely on pyecc lib unless key components are needed.

We plan to review these 2 codebase and see which multivariavte commitment scheme is easier to implement in Python

• https://github.com/EspressoSystems/hyperplonk
• https://github.com/hyraxZK/fennel

0b. Documentation

We will provide a markdown file explaining the detail implementation of each protocol and util function, for example, why radix 4 fft.
If there're already good resources out there. We'll reference it in write up and summarize how we utilize them.

0c. Testing Guide

similar to plonkathon, cover unit test for each components, let's say fft, we unit test fft overall rather than subfunction of it. dummy_test, basic testcase

Additional Information ➕

• What work has been done so far?
  part of cq's util function has been done

Open Task RFP for Privacy preserving machine learning inference using MPC

Executive Summary

• Project Overview: In this project, we want to see current state of the privacy preserving machine learning (PPML) especially utilizing MPC by building real-world ML model using existing MPC-ML framework.

Project Details

• Scope of Work:
  • Decide what machine learning model to build
  • Build PPML using MPC-ML framework (use pre-trained model)
• Expected Outcomes: Source code of the software
• Technical Requirements: EzPC

Qualifications

• Skills Required: machine learning
• Preferred Qualifications: MPC

Administrative Details

• Grant Liaison(s): Name, GitHub, email of the person(s) responsible for evaluating and keeping track of this project.
• Estimated Project Duration: 1month
• Project Complexity: Medium

Additional Information

• Relevant Tags: MPC, ML
• Reference Material: Links to any upstream issues, documentation, or other resources that provide more context.

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

Open Task RFP for Improve MSM performance using GPU

Executive Summary

• Project Overview: Improve MSM performance using GPU
• refer to following for detail
  • zkmopro/mopro#22 (an umbrella issue),

Project Details

• Motivation: Speed up mobile proving
• Scope of Work: comparing with ark-msm on mobile phones and integrating other Zprize work
• Expected Outcomes: complete the rough path listed in zkmopro/mopro#22
• Technical Requirements: msm, GPU, iOS, Note this issue has a preliminary stated in mopro 22, which is to at least get it work and micro benchmark

Qualifications

• Skills Required: You know msm, GPU, iOS

Administrative Details

• Grant Liaison(s): TO BE FILLEDOUT
• Estimated Project Duration: TO BE FILLEDOUT
• Project Complexity: Medium

Additional Information

• Relevant Tags: Mobile Proving

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Send out issue in this repo and comment under zkmopro/mopro#21

General Grant Proposal - Mopro-22

• Project: Improve MSM performance using GPU #23

Project Overview 📄

Overview

Enhance the performance on proving speed using GPU on mobile phone.

Refer to following for detail

• Proving with GPU on mobile oskarth/mopro#22

Project Details

• Use ark-msm as baseline and compare benchmarks of other zprize works on real device.
• Reproduce the benchmarking with laptop/server GPU.
• Experiment and understand the details on how to use GPU on mobile proving.
• Enable the msm scheme run on iOS device with GPU acceleration.
• Optimize the MSM execution with mobile specific works such as parallel computation.
• Provide documention and instructions to how to enable GPU acceleration in proving process on mobile.

MileStone Details

For milstone 1 & 2, we will focus on integrating the algorithms into mopro and benchmark the performance using arkwork msm (which is already integrate in the project from previous work) as baseline.

Regarding milstone 3, we will try to optimize the msm algorithm on Apple chip using its GPU API called Metal. And in the fourth milestone, we will benchmark our work in mopro to see if our work has a better performance than the others.

Team 👥

Team members

• Names of team members

  • Fu-Chuan Chung
  • Moven Tsai

• Discord handle

  • foodchain1028
  • moventsai

• Email

  • [email protected]
  • [email protected]

Team's experience

• Fu-Chuan Chung
  • PSE ZK Summer Open-source Contribution Program Fellow
• Moven Tsai
  • PSE ZK Summer Open-source Contribution Program Fellow

Team Code Repos

• mopro

Development Roadmap 🔩

Overview

• Total Estimated Duration: 9 week
• Full-time equivalent (FTE): 1.0666666667
• Estimated start date: Mar 1st 2024
• Total Estimated Working Hours: 384 hours

Milestone 1: Integrate other zprize works with ark_msm as baseline and benchmark them on iOS device.

• Estimated Duration: 2 week
• Estimated delivery date: Mar 15th 2024
• FTE: 1.2
• FTE for us: 24 + 24

Milestone 2: Introduce the laptop/server GPU to accelerate the proving and reproduce the benchmarking.

• Estimated Duration: 1 week
• Estimated delivery date: Mar 24th 2024
• FTE: 0.8
• FTE for us: 16 + 16

Milestone 3: Experiment on how to use GPU on iOS and enable the msm scheme run on iOS device with GPU acceleration.

• Estimated Duration: 4 week
• Estimated delivery date: Apr 24th 2024
• FTE: 1.2
• FTE for us: 24 + 24

Milestone 4: Optimized the MSM performance with mobile specific works

• Estimated Duration: 2 week
• Estimated delivery date: May 8th 2024
• FTE: 0.8
• FTE for us: 16 + 16

Deliverables and Specifications

0a. Codebase

We plan to integrate msm optimizations for mobile built in Zprize (or find other implementations in GPU acceleration like Ingonyama - icicle) in mopro project. Moreover, we tend to conduct an experiment for optimizing an MSM algorithm designed for Apple Chip.

Afterwards, we will benchmark these integration with arkwork-msm to observe the result in both laptops and real IOS devices.

milestone involved: all

0b. Documentation

We commit to ensuring exhaustive documentation of all modifications undertaken. This will involve the provision of detailed operational guidelines within the README.md file for the utilization of the tool. Additionally, we will refine and augment the instructions for incorporating other msm-work into the benchmarks. This enhancement is aimed at bolstering future experimental endeavors and facilitating extensions.

milestone involved: all

0c. Testing Guide

We will try to optimize some algorithms to accelerate the process on msm running on IOS GPU. In addition, we aim to integrate more MSM GPU optimization implementations and benchmark these operations running on IOS GPU.

The test guides would be written in the report in each milestone.

milestone involved: all

0d. MSM Algorithms Integration

MSM optimized algorithm on mobile GPU

• nistath: in Rust
• Trapdoor-Tech: in Rust, Java

milestone involved: all

Reference

0e. iOS Mobile Architecture

We aim to harness Apple's GPU architecture and Metal API, custom-optimizing MSM algorithms to exploit parallel processing and compute shaders. This approach guarantees better performance, energy efficiency, and security in msm computations on iOS devices.

milestone involved: 3 & 4

Additional Information ➕

zprize 2022 msm acceleration on mobiles are mainly conducted on Samsung Galaxy A13 5G (SoC MediaTek Dimensity 700
(MT6833) and the MSM implementation were over BLS12-377 G1 curve.

Milestone Reports

• mopro 22 milestone 1 report
• mopro 22 milestone 2 report
• mopro 22 milestone 3 report
• mopro 22 milestone 4 report

Reference

• zprize 2022 msm on mobile acceleration
• Ingonyama - icicle : as a reference to implement in Metal API.
• Pippenger: in Rust
• Metal Document

General Grant Proposal

• Project: Nova by Hand

Project Overview 📄

Overview

Provide an article that explains the advantages of Nova's Folding Scheme mechanism compared to conventional recursive proofs and explains its primitives in an intuitive and in-depth, using many illustrations.

Project Details

Scope of readers

People who want to know how Nova folding works.

Article

• Outline
  • Introduction to Nova
    • Incremental Verifiable Computation
    • Mechanisms and problems of ordinary Recursion
    • Cycle of Curve in Recursion generally
    • Nova
  • Relaxed R1CS by Hand
    • R1CS
    • Relaxed R1CS
    • Pedersen Commitment Scheme
    • Committed Relaxed R1CS
    • Folding Scheme for committed Relaxed R1CS
    • (link to Python code snippets)
  • Non-interactive Folding Schemes with a hash function
  • Cycle of Curve in Nova

Not scope

• Polynomial Interactive Oracle Proof(Super Spartan), Augmented Circuit

Team 👥

Team members

Yugo

Discord: yugokoral

Github: https://github.com/yugocabrio

Team's experience

PSE ZK Summer Open Source Contribution Program fellow My contribution

Team Code Repos

https://github.com/yugocabrio/Folding_by_Hand

Development Roadmap 🔩

Overview

• Total Estimated Duration: 8 weeks(4 milestones)

• Full-time equivalent (FTE): 0.4-0.5

• Starting Date: December 11th

• Estimated delivery date: February 26th

• Note: I would like to break 3 weeks to focus on the final exam at Univ between Milestones 2 and 3.

Milestone 1

• Estimated Duration: 2 weeks
• FTE: 0.4
• Starting Date: December 11th 2023
• Estimated delivery date: December 25th 2023

Contents

Introduction to Nova

• Incremental Verifiable Computation
• Mechanisms and problems of ordinary Recursion
• Cycle of Curve in Recursion generally
• Nova

1. Incremental Verifiable Computation

Explain Incremental Computation and Incremental Verifiable Computation with simple illustrations.

2. Mechanisms and problems of ordinary Recursion

Explain the mechanism of recursion or accumulation, for example, Halo2 or Plonky, briefly with diagrams. Also, discuss their disadvantages, such as the overhead of pairing in the snark verifier during proving.

3. Cycle of Curve in Recursion generally

Explanation of elliptic curve's subgroups defined on finite fields. Also, an explanation of the mismatch between the base field and the scalar field during recursion. Explain that using two elliptic curves, the scalar field of each curve is the base field of the other curve.

4. Nova

Explain Nova, which introduces a Folding scheme that compresses two R1CS (NP instances) into one. Briefly introduce the differences between Nova, Snagira, SuperNova, and HyperNova.

Milestone 2

• Estimated Duration: 2 weeks
• FTE: 0.4
• Starting Date: December 25th 2023
• Estimated delivery date: January 8th 2024

Contents

Relaxed R1CS by Hand

• R1CS
• Relaxed R1CS
• Pedersen Commitment Scheme
• Committed Relaxed R1CS
• Folding Scheme for committed Relaxed R1CS
• Python code snippets

1. R1CS

Explain how to construct the R1CS(Az◎Bz=Cz) from the equation x^2-5x+9=3, which has roots at x=2 and x=3.
The reason I chose this is that I want to show the folding with different witnesses.
Explain that simple folding with linear combination fails due to cross-term.

2. Relaxed R1CS structure

Explain the Relaxed R1CS(Az◎Bz=uCz+E) structure. Introduce folding the above R1CS by hand calculation while using Python's snippet.

3. Pedersen Commitment Scheme

Explain the additive homomorphism of the Pedersen commitment.

4. Committed Relaxed R1CS

Explain a committed R1CS that allows the Prover to compute computationally expensive error terms, including cross terms, instead of having the Verifier compute them and also realizes zero knowledge.

5. Folding Scheme for committed Relaxed R1CS

Explain the Interactive Folding scheme for Committed Relaxed R1CS. Explain what Prover and Verifier do and in what order they work.

Milestone 3

• Estimated Duration: 2 weeks
• FTE: 0.5
• Starting Date: January 29th 2024
• Estimated delivery date: February 12th 2024

Contents

• Non-interactive Folding Schemes with a hash function
• Cycle of Curve in Nova

1. Non-interactive Folding Schemes with a hash function

Explain the Fiat-Shamir transformation as a general idea and then how to apply it to the Non-Interactive Folding Scheme. In this case, the prover takes in the commitment of cross-term as a parameter of a random oracle.

2. The cycle of Curve in Nova

Explain how the cycle of the curve works in Nova. I will read and study the Revisiting Nova video or paper.

Milestone 4

• Estimated Duration: 2 weeks
• FTE: 0.5
• Starting date: February 12th 2024
• Estimated delivery date: February 26th 2024

Finish the incomplete tasks and review the article. In previous milestones, I will have prepared the initial versions of the handwritten illustrations. During this final milestone, I will refine and finalize these illustrations.

Open Task RFP for Langlands

Executive Summary

• Project Overview: Implement KZG over a polynomial repo and integrate Sppark and Icicle

Project Details

• Motivation:
  • The different high-performance hardware-accelerated versions of the same proof system, developed by various teams, are often proprietary because, for most teams, it is a vital weapon that allows them to survive in commercial competition. This situation is similar to the existence of multiple GPU versions of a game like Halo2, with examples including the Scroll, DelphinusLab, Tachyon, and Ingoyama versions. Each version, developed by different teams, brings unique features or performance enhancements that provide a competitive edge in the market. But I don’t think this is the way to maximize value because developers often do a lot of duplication of work.
  • In the future, there may be more such general acceleration libraries that not only work on GPUs but also on ASICs and FPGAs. So for most teams, it is impossible for them to spend a lot of time integrating so much hardware. acceleration libraries and compare their performance differences one by one. We need to add an intermediate layer to the proof system and the hardware acceleration library so that most teams that develop proof systems only need to integrate this middle layer to run on different hardware flexibly. Switch between acceleration plans. Zpu is a potential solution, but we hope to do this in the upper polynomial layer of ZPU developed by Ingoyama, because for all proof systems, they essentially end up operating on polynomials, so we hope to provide a useful polynomial library and integrate enough common hardware acceleration libraries on this library.
  • We currently lack many ZKP hardware acceleration engineers because there are very few people with the knowledge base of both ZKP and hardware acceleration, and the learning fields in these two fields are also very steep. We need to provide something like https://learn.0xparc.org/ /halo2/’s courses to help more developers enter this area.
• Scope of Work:
  • Choose a polynomial library that is general enough, and we decide to select https://github.com/arkworks-rs/algebra/tree/master/poly as the repo to develop.
  • Implement KZG over this polynomial repo and integrate Sppark and Icicle
  • We plan to output some educational content about developing the MSM algorithm using Cuda and compare it with different MSM-CUDA versions developed by different awesome teams.
• Expected Outcomes:
  • Implement KZG over this polynomial repo and integrate Sppark and Icicle.
  • Support CQ lookup argument
  • Write an article to summarize the similarities and differences between Icicle and Sppark in the implementation of the MSM algorithm and compare the performance data.

Qualifications

• Skills Required:
  • Good rust development capabilities
  • A deep understanding of snark
  • A certain understanding of GPU programming
• Preferred Qualifications:
  • Excellent document writing skills

Administrative Details

• Estimated Project Duration:
  5 weeks
• Project Complexity:
  • Medium Difficulty because doing the job requires some understanding of a variety of technologies. However, you don’t need to have an in-depth understanding of every technical field. More work is to find some better technical solutions on the market and combine them.

Additional Information

• Reference Material:
  • We ultimately hope that this project can integrate more lookup arguments, more commit schemes, and more hardware acceleration libraries so that developers can develop a new proof system easily with better performance by using this polynomial repo.
  • icicle: https://github.com/ingonyama-zk/icicle.git
  • sppark: https://github.com/supranational/sppark.git

Open Task RFP for Halo2 Aggregation Toolbox

Executive Summary

• Project Overview: Create a user-friendly halo2 aggregation toolbox, enabling users to merge proofs, verify them, and produce verifiers

Project Details

• Scope of Work:
  • Designing and implementing a user-friendly aggregation tool for Halo2.
  • Developing the capability to merge Halo2 proofs.
  • Creating a verification component/testcase to ensure the validity of merged proofs.
  • Building a module to generate verifiers based on the aggregated proofs.
• Expected Outcomes: API, API doc, unit/integration test suite, blogpost

Qualifications

• Skills Required: halo2, know how to design API
• Preferred Qualifications:
  • Prior experience in developing aggregation tools for zero-knowledge proofs.
  • Prior experience in open source project using halo2

Administrative Details

• Grant Liaison(s): TO BE FILLED OUT
• Estimated Project Duration: 200 hr
• Project Complexity: Hard

Additional Information

• Relevant Tags: Toolkit
• Reference Material:
  • Maze
  • Lambda - Proof Aggregation Schemes
  • https://twitter.com/Louissongyz/status/1653770344694415362

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

General Grant Proposal

• Project: ZK-friendly ML model explorations

Project Overview 📄

Overview

This task explores different zk-applicable machine learning techniques and compare them.

Project Details

Throughout the project, we explore different zk-applicable machine learning algorithms that can perform the Heart Failure Prediction Dataset.

Specifically, we target to explore

• Neural Network
• Linear Regression
• Decision Tree
• k-Nearest Neighbor

I plan to compare the folloings:

• Number of model parameters (if any)
• Model accuracy
• Train complexity (time/memory)
• Proof generation complexity (time/memory)
• Performance degradation when converted to ZK circuit
• Verification complexity (time/memory)

Team 👥

Team members

• Saeyoon Oh
• email: [email protected]
• telegram handle: greenteaboom
• discord handle: saeyoon_oh

Team Website

• https://https://github.com/saeyoon17

Team's experience

• PSE Summer Contribution Camp
• 2023 Ethcon Seoul
  • torch2circm built upon keras2circm and circomlib

Team Code Repos

• https://github.com/saeyoon17

Development Roadmap 🔩

Overview

• Total Estimated Duration: 8 weeks (160 hours)
• Full-time equivalent (FTE): 0.5 FTE

Milestone 1️⃣: Training/Proof generation using Neural Network

• Estimated Duration: 2 weeks
• FTE: 0.5

Deliverables and Specifications

0a. Source code / Documentation - We plan to provide the source code and the documentations of how one can train a neural network, using the heart failure dataset and make heart failure prediction with it. The code should also contain evaluation pipeline where one can check the model accuracy. Also, it would allow one to prove that the prediction was made using the correct circuit.

1. Functionality: Train/Test/Inference pipeline using neural network. The model architecture is to be determined where I plan to start with simple MLP and expand.
2. Functionality: Converting neural network model to ZK circuits using Circom or EZKL.
3. Functionality: Proof generation/Verification pipeline with utilities to check the time/memory complexity.

Milestone 2️⃣: Training/Proof generation using Linear Regression

• Estimated Duration: 2 weeks
• FTE: 0.5

Deliverables and Specifications

0a. Source code / Documentation - We plan to provide the source code and the documentations of how one can make classification using linear regression using given dataset, and make heart failure prediction with it. The code should also contain evaluation pipeline where one can check the model accuracy. Also, it would allow one to prove that the prediction was made using the correct circuit.

1. Functionality: Train/Test/Inference pipeline using linear regression.
2. Functionality: Converting linear regression model to ZK circuits using Circom or EZKL.
3. Functionality: Proof generation/Verification pipeline with utilities to check the time/memory complexity.

Milestone 3️⃣: Training/Proof generation using Decision Tree

• Estimated Duration: 2 weeks
• FTE: 0.5

Deliverables and Specifications

0a. Source code / Documentation - We plan to provide the source code and the documentations of how one can make classification using decision tree using given dataset, and make heart failure prediction with it. The code should also contain evaluation pipeline where one can check the model accuracy. Also, it would allow one to prove that the prediction was made using the correct circuit.

1. Functionality: Train/Test/Inference pipeline using decision tree.
2. Functionality: Converting decision tree to ZK circuits using Circom/EZKL/zkML.
3. Functionality: Proof generation/Verification pipeline with utilities to check the time/memory complexity.

Milestone 4️⃣: Training/Proof generation using kNN / Final report

• Estimated Duration: 2 weeks
• FTE: 0.5

Deliverables and Specifications

0a. Source code / Documentation - We plan to provide the source code and the documentations of how one can make classification using kNN using given dataset, and make heart failure prediction with it. The code should also contain evaluation pipeline where one can check the model accuracy. Also, it would allow one to prove that the prediction was made using the correct circuit.

0b. Final report - We plan to write down the final reports on observed models, where we compare the followings:

• Number of model parameters (if any)
• Model accuracy
• Train complexity (time/memory)
• Proof generation complexity (time/memory)
• Performance degradation when converted to ZK circuit
• Verification complexity (time/memory)

1. Functionality: Train/Test/Inference pipeline using kNN.
2. Functionality: Converting kNN to ZK circuits using Circom/EZKL/zkML.
3. Functionality: Proof generation/Verification pipeline with utilities to check the time/memory complexity.

Additional Information ➕

Plans on converting models to ZK circuits

I am planning to first construct each model using pytorch and try EZKL. Yet if the operations are unimplemented, I am planning to look for other conversion methods, or construct circom circuit on my own.

Relevant works

• EZKL
• ZKML
• circomlib

General Grant Proposal

• Project: Halo2 Aggregation Toolbox #6

Project Overview 📄

Overview

The Halo2 Aggregation Toolbox aims to provide users with a user-friendly interface for merging proofs, verifying them, and generating verifiers using the Halo2 zero-knowledge proof system.

Project Details

• Develop a user-friendly interface for non-expert users to interact with Halo2 proofs.
• Enable efficient aggregation, verification, and verifier production for Halo2 proofs.
• Ensure the toolbox is extendable for future improvements in zero-knowledge proof technology and Halo2 advancements.
• Design the API, output the API developer documentation and related blogs.

Team 👥

Team members

• Names of team members

  • Shixiang Tang
  • Shixiao Sun (Direct contact)

• Email

  • [email protected]
  • [email protected]

• Telegram handle

  • @Xor0v0
  • @Vap0RSh4wN

Team's experience

• Student in cryptography from BUPT
  Main contributor to the open source zk tutorials z2o-k7e and WTF-zk.

• Student in cryptography from POLYU
  Focus on zk security.

Team Code Repos

• https://github.com/Xor0v0
• https://github.com/Vap0RSh4wN

Development Roadmap 🔩

Overview

• Total Estimated Duration: 8 weeks
• Full-time equivalent (FTE): 0.5
• Expected Start Date: May 1, 2024
• Expected End Date: June 26, 2024

Milestone 1: Preliminary Research and Project Setup

• Estimated Duration: 1 weeks
• FTE: 0.5
• Estimated delivery date: May 8, 2024

1. Research and Feasibility Study:

• Perform an in-depth analysis of the Halo2 protocol, focusing on its use in proof aggregation and the specifics of implementing zero-knowledge proofs in Rust.
• Investigate existing Rust libraries and tools that could support Halo2 proof operations.
• Learn the halo2 aggregators from Poseidon ZKP and Scroll.

2. Project Structure and Initial Setup:

• Establish a clear project structure, including directories for source code, tests, documentation, and examples.
• Define coding standards and guidelines for contributing to the project.
• Begin drafting documentation plans, including API documentation, user guides, and developer guides.

Milestone 2: Core API and Proof Aggregation Development

• Estimated Duration: 4 weeks
• FTE: 0.5
• Estimated delivery date: June 5, 2024

1. API Design:

• Design Rust API for handling and aggregating Halo2 proofs.
• Ensure the API design accommodates future extensions for verification and verifier generation.
• Document the API design, including data structures, function signatures, and error handling, using rustdoc.

2. Proof Aggregation Implementation:

• By Proof Recursion of Halo2, implement the core logic for aggregating proofs, integrating any necessary cryptographic libraries and optimizing for performance and security.

3. Testing Framework:

• Develop tests for the API and aggregation functionality to ensure correctness, stability, and performance.

Milestone 3: Verification and Verifier Generation

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated delivery date: June 19, 2024

1. Verification Functionality Development:

• Implement the functionality for verifying aggregated proofs, ensuring compatibility with the aggregation logic and adherence to cryptographic standards.

2. Verifier Generation:

• Develop the capability to generate verifiers.

3. Documentation and Examples:

• Enhance the project documentation to cover the new functionalities.

Milestone 4: Finalization, Documentation, and Community Launch

• Estimated Duration: 1 weeks
• FTE: 0.5
• Estimated delivery date: June 26, 2024

1. Library Optimization and Final Testing:

• Conduct final optimizations.
• Complete final testing to ensure the toolbox is stable.

2. Output Documentation and Blogpost:

• Finalize all documentation, ensuring it is easy to understand, and accessible to both beginners and experienced developers.
• Publish related blog.

Reference

• https://github.com/zcash/halo2
• https://zcash.github.io/halo2/background/recursion.html#Polynomial-commitment-using-inner-product-argument
• https://github.com/scroll-tech/halo2-snark-aggregator

Open Task RFP for Tooling to enable micro benchmarks for GPU/MSMs

Executive Summary

• Project Overview: implement tooling to enable micro benchmarks for GPU/MSMs
• refer to following for detail
  • zkmopro/mopro#22 (an umbrella issue),
  • zkmopro/mopro#21

Project Details

• Motivation: to speed up msm on mobile
• Scope of Work: doc, tooling
• Expected Outcomes: a basic tolling on real iOS device
• Technical Requirements: Swift, Rust, MSM, Note this issue has a preliminary stated in mopro 22, which is to at least get it work

Qualifications

• Skills Required: You know Swift, Rust, MSM

Administrative Details

• Grant Liaison(s): Oskar
• Estimated Project Duration: TO BE FILLEDOUT
• Project Complexity: Medium

Additional Information

• Relevant Tags: Mobile Proving

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Send out issue in this repo and comment under zkmopro/mopro#21

Open Task RFP for Nova by hand

Executive Summary

• Project Overview: Provide an implementation/tutorial for individuals to self-construct Nova, and related topics.

Project Details

• Scope of Work: Follow similar approach as tutorial work based on Plonkathonto implement Nova and its tutorial
  - Folding Schemes(Relaxed R1CS)
  - Spartan(Sumcheck)
• Expected Outcomes: Clearly state what successful completion of the project looks like.
• Technical Requirements: Python

Qualifications

• Skills Required: Understanding protocol and be able to implement with Python
• Preferred Qualifications: Prior knowledge in cryptography including commitment scheme, IOP, etc.

Administrative Details

• Grant Liaison(s): @NOOMA-42, [email protected]
• Estimated Project Duration: Ideally 1.5 months
• Project Complexity: Easy

Additional Information

• Relevant Tags: ZKP
• Reference Material:
  https://github.com/0xPARC/plonkathon
  https://research.metastate.dev/plonk-by-hand-part-1/
  https://github.com/privacy-scaling-explorations/folding-schemes
  https://github.com/nalinbhardwaj/Nova-Scotia

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

Executive Summary

Project Name: Astra: Accelerating Client-Side ZK with WebGPU

Astra is a cutting-edge library designed to accelerate zero-knowledge proof generation directly within web browsers. By harnessing the power of WebGPU, Astra aims to overcome the computational barriers that have traditionally hindered the performance of privacy-preserving applications. Our project focuses on optimizing critical operations like MSMs and NTTs and aims to establish a comprehensive ecosystem for seamless integration across various proof systems.

Project Overview

Astra leverages the emerging WebGPU standard to tap into the parallel processing capabilities of GPUs directly within the browser. This approach promises to bridge the gap between the computational demands of zero-knowledge proofs and the limitations of traditional browser-based environments. By optimizing key operations such as multi-scalar multiplications (MSMs) and number-theoretic transforms (NTTs), Astra aims to set a new benchmark for performance in the realm of client-side zero-knowledge proofs.

Project Details

Background on WebGPU

WebGPU is a groundbreaking API that provides web applications with access to the computational power of modern GPUs. Unlike its predecessors, WebGPU is designed with both graphics and general-purpose computation in mind, making it an ideal choice for computationally intensive tasks like zero-knowledge proof generation. By utilizing the parallel processing capabilities of GPUs, WebGPU can execute operations much faster than traditional CPU-based approaches, especially when dealing with large datasets or complex calculations.

Motivation

The generation of zero-knowledge proofs is a resource-intensive process that has traditionally been hampered by the constraints of browser environments. With the advent of WebGPU, a new pathway has opened up, allowing direct access to GPU resources within the browser. Astra seeks to exploit this opportunity to accelerate proof generation, making zero-knowledge applications more practical and user-friendly.

Scope of Work

The project is divided into three milestones, each focused on a different aspect of the library's development:

Total Estimated Duration: 8 weeks
Full-time Equivalent (FTE): 2

Milestone 1 - Shader Implementation and Integration

Estimated Duration: 2 weeks
FTE: 2

In this phase, we plan on implementing shaders for field arithmetic and curve operations for BN254.

Milestone 2 - Integration and Benchmarking

Estimated Duration: 3 weeks
FTE: 2

In this phase, we focus on integrating the primitives with the halo2 library and benchmarking it.

Milestone 3 - Expansion and Tooling

Estimated Duration: 3 weeks
FTE: 2

Expected Outcomes

By the end of 8 weeks, we aim to establish the groundwork for a robust ecosystem dedicated to zero-knowledge proof generation utilizing WebGPU. Future work will involve further optimizations and integrations with other proof-generation libraries.

Current Work

We have made considerable strides in advancing the Astra project, effectively mitigating risks associated with key milestones. Our achievements thus far include:

• Successful implementation of WebGPU compute shaders for the BN256 family of curves, encompassing critical field and curve point operations.
• Development of prototype implementations for MSM (multi-scalar multiplication) and NTT (number theoretic transform) primitives, exploring various compute pipeline modalities to optimize performance.
• Conducting preliminary benchmarking to assess the efficiency and effectiveness of our proof of concept (PoC) implementation, laying the groundwork for future optimizations and enhancements.

Project Repo

Team

Team Experience

The team has been deeply involved in the zk space for over a year. We have previously built distributed versions of the primitives required to generate proofs to enable distributed proof generation in Arkworks and halo2.

Administrative Details

Estimated Duration of the project: 8 weeks
Project Complexity: Medium, requiring expertise in Rust, Zero Knowledge Proofs, and WebGPU.

General Grant Proposal

• Project: Halo2 Soundness Bug Examples

Project Overview 📄

Overview

Establish a repository featuring small halo2 circuits, each presenting a unique soundness bug

Project Details

• Halo2, Soundness Bug, Documentation
• Examples would show possible soundness bugs, guiding users to avoid them.
• Reference

Team 👥

Team members

• Names of team members: Jaewon In
• Email: [email protected]
• Telegram handle: jae-cuz
• Discord handle: jae-cuz

Team Website

• https://github.com/jae-cuz

Team's experience

PSE Summer Contribution Program

Team Code Repos

• https://github.com/jae-cuz/unsound-halo2

Development Roadmap 🔩

This section should break out the development roadmap into a number of milestones. Since the milestones will appear in the grant contract, it helps to describe the functionality we should expect, plus how we can check that such functionality exists.

Below we provide an example roadmap. We recommend that the scope of the work can fit within a 3 month period and that teams structure their roadmap as 2 weeks = 1 milestone.

For each milestone:

• Please be sure to include a specification of the software. The level of detail must be enough so that we are able to verify that the software meets the specification.
• Please include total amount of funding requested per milestone.
• Please note that we require documentation (e.g. tutorials, API specifications, architecture details) in each milestone. This ensures that the code can be widely used by the community.
• Please provide a test suite, comprising unit and integration tests, along with a guide on how to run these.
• Please indicate the milestone duration, as well as number of Full-Time Employees working on each milestone, and include the number of days along with their cost per day.

Overview

• Total Estimated Duration: 6 weeks
• Full-time equivalent (FTE): 0.5
• Expected Start Date: Dec 18 2023
• Expected End Date: Jan 28 2024

Milestone 1 Under-constrained Circuits

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated delivery date: Dec 31 2023

Deliverables and Specifications

1. Write vulnerable circuits & exploitation

• Example vulnerable circuit with identifier mistakes
• Example vulnerable circuit with logically missing constraints (ex: factoring circuit without constraing the input to be not one)

2. Write mitigations

• Fix with correctly used identifier
• Fix with sound constraints

3. Documentation

• Explain the vulnerability in detail, showing that malicious prover can pass the verification.
• Suggest mitigation technique using tools for detecting unused identifier, checking constraints, etc.
• Explain about the role of Config, Chip, and Circuit
• Suggest mitigation technique using correct template (avoiding copy and paste)

Milestone 2 Assigned but not Constrained

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated delivery date: Jan 14 2024

Deliverables and Specifications

1. Write vulnerable circuits & exploitation

• Example vulnerable circuit where assigned but not constrained

2. Write mitigations

• Fix with correct constraints

3. Documentation

• Explain required mathematical background.
• Explain the vulnerability in detail, showing that malicious prover can pass the verification.
• Suggest mitigation technique using tools, as well as negative testing.

Milestone 3 Arithmetic Over/Underflow

• Estimated Duration: 1 week
• FTE: 0.5
• Estimated delivery date: Jan 21 2024

Deliverables and Specifications

1. Write vulnerable circuits & exploitation

• Example vulnerable circuit with arithmetic over/underflow

2. Write mitigations

• Fix with constraints for over/underflow

3. Documentation

• Explain the vulnerability in detail, showing that malicious prover can pass the verification.
• Show real-world bugs
• Suggest mitigation technique using tools, as well as negative testing.

Milestone 4 Review & Further

• Estimated Duration: 1 week
• FTE: 0.5
• Estimated delivery date: Jan 28 2024

Deliverables and Specifications

1. Review codes and documents

• Check typos and mistakes
• Rewrite for any misunderstandings

2. Further research

• Search for any other vulnerability categories
• Add documents if a vulnerability was not suited for writing an example

Additional Information ➕

References

• https://github.com/0xPARC/zk-bug-tracker

Open Task RFP for Porting real-world ML model(s) into ZK

Project: Porting real-world ML model(s) into ZK

Executive Summary

• Project Overview: this project aims to integrate advanced machine learning (ML) models, specifically designed for predicting hourly rainfall distribution using polarimetric radar data, with blockchain Oracles through Zero-Knowledge (ZK) proofs. The objective is to securely extend Oracles data on the blockchain by providing verifiable, privacy-preserving proofs of ML inference results. This integration will demonstrate the practical application of ZK proofs in enhancing the trustworthiness and security of ML computations used in critical decision-making processes, such as agricultural planning and resource management.

Project Details

• Motivation: Oracles serve as bridges between blockchain systems and external data sources, playing a pivotal role in smart contracts and decentralized applications. There is often a limit to the amount of authenticated data that can be provided by an Oracle. Also, the data provided by the oracle may not meet the needs of the dApp's usage. For example, dApps are often limited in their use of rainfall data by the distribution of weather stations. Especially in a large number of developing countries, there is a lack of appropriate infrastructure. To address this concern, researcher have proposed the use of radar signals to assess rainfall over large areas and then use a limited number of weather stations to correct the radar estimates. ML has demonstrated extremely high accuracy in this area (Continuous Ranked Probability Score, which represents the evaluation error, is less than 0.01). By porting real-world ML models into a zkML, I aim to establish a novel methodology for verifying the accuracy and integrity of inference results without revealing sensitive data. This project is motivated by the potential to significantly enhance the functionality and security of blockchain Oracles, making them more applicable for sectors like agriculture where decision-making is heavily data-dependent.

• Data Set: the AMS-AI 2015-2016 Contest: Probabilistic estimate of hourly rainfall from radar in 13th Conference on Artificial Intelligence. All the data is stored in CSV format. The training data consists of NEXRAD and MADIS data collected over midwestern corn-growing states the first 8 days of Apr to Nov 2013. Time and location information have been censored, and the data have been shuffled so that they are not ordered by time or place. The test data consists of data from the same radars and gauges over the same months but in 2014. The train set has 1048575 samples. The test set has 630452 samples. We are given polarimetric radar values and derived quantities at a location over the period of one hour. We will need to produce a probabilistic distribution of the hourly rain gauge total.

• Related Work:

  1. Regarding the use of polarized radar values to predict rainfall distributions, Devin Anzelmo proposed in the competition to consider the predictions as a linear combination of CDFs estimated from the training set. Each component CDF is weighted according to the class probability of the label associated with the CDF given by the classification algorithm. This probability is given by the classification algorithm.
  2. The use of radar and rain gauges to predict rainfall has been widely studied. The use of radar and rain gauges to predict rainfall has been widely studied. For example, Yan et al. proposed Short time precipitation estimation using weather radar and surface observations: with rainfall displacement information integrated in a stochastic manner. Ochoa-Rodriguez reviewed this area in A Review of Radar-Rain Gauge Data Merging Methods and Their Potential for Urban Hydrological Applications.
  3. Regarding the use of zero-knowledge proof techniques for proving machine learning inferences, there is some representative work such as circomlib-ml, EZKL, and ZKML by Daniel Kang et al.

• Method: The rainfall will be evaluated by decision tree, random forest or XGBoost, and proved by ZK-DTP/circomlib-ml/EZKL.

• Scope of Work:

  • Model Selection and Development: Identify and develop an ML model capable of generating probabilistic rainfall distributions from polarimetric radar data, suitable for ZK implementation. Using polarimetric radar values and derived quantities to predict the probability distribution of rainfall. Correct this prediction using available meteorological base station data.

  • ZK Proof System Integration: Implement the selected ML model within a ZK proof system, ensuring that inference results can be verified on the blockchain without compromising data privacy.

  • Performance and Security Analysis: Evaluate the system's performance in terms of accuracy, computational efficiency, and security. Compare the ZK-enabled model's inference results with traditional approaches to demonstrate improvements.

  • Documentation and Publication: Document the development process, challenges, solutions, and performance analysis. Prepare comprehensive materials for scientific publication, highlighting the project's contribution to blockchain and ML fields.

• Expected Outcomes:

  • A machine learning model capable of producing probabilistic rainfall estimates from polarimetric radar data.

  • Implementation of the model in a ZK environment, demonstrating the application of privacy-preserving techniques in agricultural data analysis.

  • A comprehensive documentation of the project process, findings, and a scientific article ready for publication.

Preliminary results

I used my vacation time during the preparation of the proposal to conduct preliminary experiments and analysis, pruning the Devin Anzelmo's solution, a multi-class XGBoost model with soft labels, which can estimate rainfall amounts accurately. However, the original model was aggregated from five XGBoost models, each including 10,000 decision trees, for a total of 50,000 decision trees. I tried to use Bonsai's zero knowledge prove hardware acceleration. The proof limit is about 6 million, and the proof time is in the range of 7 to 10 minutes. The complexity of this model makes it extremely difficult to implement the proof on a personal laptop. To address this problem, I pruned the model, reducing the number of decision trees for a single model to 300, for a total of 1500 decision trees. As shown in the figure, the loss of Continuous Ranked Probability Score was only 0.00002, less than 1/300.

Qualifications

• Proposer: Li@only4sim
• Email: [email protected]
• Telegram Handle: @sing4cat
• Discord Handle: li.quan
• GitHub: https://github.com/only4sim
• Skills Required: Python (Experienced), XGBoost, PyTorch, and scikit-learn (Familiar), EZKL (Experienced).
• Preferred Qualifications:
  • Creator of the ZK-DTP and Snarky-ML libraries (First zkML libraries in o1js).
  • Grantee of Mina Protocol Innovation Grant (delivered beyond application expectations).
  • First place in the RISC Zero AI Challenge in ZK Hack Istanbul
  • Fourth Place, Top Prize in the RISC Zero Challenge in ZK Hack Lisbon

Administrative Details

• Estimated Project Duration: 120 hours, accommodating the project's multifaceted nature and the integration of cutting-edge technologies.
• Project Complexity: Medium. This project requires a cross-disciplinary approach, combining ML, ZK proofs, and blockchain technology to achieve its objectives. Since I have zkML related experience, I have a clear grasp of the difficulty and implementation of the project.

Development Roadmap

Overview

• Total Estimated Duration: 120 hours
• Full-time equivalent (FTE): 0.5 FTE

Milestone 1: Data Analysis and Model Selection

• Estimated Duration: 2 weeks (30 hours)
• FTE: 0.5
• Deliverables and Specifications:
  • Source Code / Documentation: Detailed documentation on the analysis of polarimetric radar data and selection of the machine learning model best suited for predicting probabilistic rainfall distributions, taking into account both model performance and its adaptability for ZK implementation.
  • Functionality: Establishment of a data analysis pipeline, criteria for model selection based on accuracy, efficiency, and ZK compatibility.

Milestone 2: ZK Model Implementation

• Estimated Duration: 3 weeks (45 hours)
• FTE: 0.5
• Deliverables and Specifications:
  • Source Code / Documentation: Comprehensive source code and documentation outlining the conversion of the selected ML model into a ZK framework using tools like ZK-DTP, Circom or EZKL, focusing on proof generation efficiency and computational resource optimization.
  • Functionality: A fully functional proof generation and verification pipeline, ensuring the model's efficient operation within ZK constraints.

Milestone 3: Integration with Blockchain Oracles

• Estimated Duration: 2 weeks (30 hours)
• FTE: 0.5
• Deliverables and Specifications:
  • Source Code / Documentation: Clear instructions and codebase for the integration of the ZK-secured ML model with blockchain oracles, including detailed steps for extending oracle data with verified inference results in a privacy-preserving manner.
  • Functionality: Operational demonstration of using the ML model's inference results in smart contracts through oracles, focusing on privacy and data integrity.

Milestone 4: Performance Evaluation and Final Reporting

• Estimated Duration: 1 week (15 hours)
• FTE: 0.5
• Deliverables and Specifications:
  • Final Report: An evaluative report on the project's outcomes, comparing model performance pre and post ZK implementation, its effect on enhancing oracle data reliability, and an assessment of overall system efficiency.
  • Functionality: Comprehensive benchmarks detailing the model's accuracy, proof generation, and verification complexity, with a focus on time and memory efficiency.

Reference

[1] Wendy Kan Alex Kleeman, Lakshmanan V. 2015. How Much Did It Rain? (2015). https://kaggle.com/competitions/how-much-did-it-rain
[2] Devin Anzelmo. 2015. First place code. https://www.kaggle.com/c/how-much-did-it-rain/discussion/16260. (2015). Accessed: 2023-11-20.
[3] Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Eran Tromer, and Madars Virza. 2013. SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge. IACR Cryptol. ePrint Arch. 2013 (2013), 507.
[4] Tianqi Chen and Carlos Guestrin. 2016. XGBoost: A Scalable Tree Boosting System. Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (2016).

ZK-Regex

• Description: The goal of this project is to create a tool that can take a regex and convert it to a circom circuit. ZK Regex is used within the zk email library, but it would be very beneficial as a more general tool.
• https://github.com/zkemail/zk-email-verify/tree/main/libs/regex_to_circom
• Expected outcome:
• Recommended Skills: Regex, Python, Circom
• Grant Liason(s): (Name, github, email)
• Expected project size: (Hours)
• Difficulty: (Easy, Medium, or Hard) Medium
• Tag: Tooling
• Upstream Issue (URL):
• Submission (Update) Date: 2023/09/21

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

Open Task RFP for PIR (constructed using FHE) for hash path retrieval

Executive Summary

• Project Overview: PIR (constructed using FHE) for hash path retrieval in applications like semaphore and privacy preserving protocols like Zcash, Aztec, etc.

Project Details

• Scope of Work: PoC and blog post or spec in hackmd
• Expected Outcomes: Design several testcase and pass test
• Technical Requirements: List any specific technologies, frameworks, or tools that will be needed.

Qualifications

• Skills Required: Detail the skills and experience that would make a candidate well-suited for this project.
• Preferred Qualifications: Any additional skills or experience that would be a plus.

Administrative Details

• Grant Liaison(s): Name, GitHub, email of the person(s) responsible for evaluating and keeping track of this project.
• Estimated Project Duration: Timeframe for project completion, including any key deadlines.
• Project Complexity: Medium to Hard

Additional Information

• Relevant Tags: FHE
• Reference Material:
  • https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=video&cd=&cad=rja&uact=8&ved=2ahUKEwiAh_i6l4eCAxV7mFYBHVpCDT0QtwJ6BAgQEAI&url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DJBVP3_PmbsI&usg=AOvVaw3E1bSOgQxtzWNMdv9vVDiK&opi=89978449

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

Open Task RFP for Porting over many zk-kit circuits from Circom to Noir

Executive Summary

• Project Overview: TO BE FILLED OUT

Project Details

• Scope of Work: TO BE FILLED OUT
• Expected Outcomes: TO BE FILLED OUT
• Technical Requirements: TO BE FILLED OUT

Qualifications

• Skills Required: TO BE FILLED OUT
• Preferred Qualifications: TO BE FILLED OUT

Administrative Details

• Grant Liaison(s): TO BE FILLED OUT
• Estimated Project Duration: TO BE FILLED OUT
• Project Complexity: TO BE FILLED OUT

Additional Information

• Relevant Tags: TO BE FILLED OUT
• Reference Material: TO BE FILLED OUT

Submission Details

• Proposal Deadline: TO BE FILLED OUT
• Submission Instructions: TO BE FILLED OUT

Open Task RFP for implement liam-eagen-msm gadget in halo2

Executive Summary

• Project Overview: implement liam-eagen-msm gadget in halo2
  https://eprint.iacr.org/2022/596

Project Details

• Motivation: being able to prove msm is important to recursive proof
• Scope of Work:
  • halo2 gadget implementation, with well documented comment and a proper API
  • article/blogpost explaining your work and paper
• Technical Requirements: List any specific technologies, frameworks, or tools that will be needed.

Qualifications

• Preferred Qualifications: halo2, understanding msm

Administrative Details

• Grant Liaison(s): @DoHoonKim8
• Estimated Project Duration: 160 hr
• Project Complexity: Hard

Additional Information

• Reference Material:
  • https://eprint.iacr.org/2022/596
  • The state of art is Pippenger
  • Currently we have a not yet finished but pending implementation of this https://github.com/levs57/halo2-liam-eagen-msm

Submission Details

• Proposal Deadline: The deadline for submitting proposals is the end of this round of the Acceleration Program. Refer to current round
• Submission Instructions: Please submit your proposal as an issue and link back to this issue in your proposal. Refer to proposal template for more details.

General Grant Proposal

• Project: implement liam-eagen-msm gadget in halo2 #27

Project Overview 📄

Overview

Liam Eagen's paper suggested a protocol to prove a point on an elliptic curve is the multi-scalar multiplication of some points. We want to implement this on halo2.

Project Details

Applying the protocol on a zk-SNARK will improve performance compared to directly proving the multiplication. The main idea of reducing proof size is to express the information of points on an element in the function field of the elliptic curve. The performance of this will depend on which proof system we use. To optimize, we want to first study about how zk-proof systems work, especially focusing on halo2 using KZG and IPA. We will summarize proof systems and materials in Liam Eagen's paper, and post it.

Next, we will implement the protocol using halo2, and compare the performance. The protocol can make the information of points or scalars zero-knowledge, or both. Every three versions can be optimized using the techniques described in the paper. The final output will be

• Implementation of the protocol using halo2.
• Summary about materials in elliptic curve inner product protocol.

Team 👥

Team members

• Names of team members: Seongsu Jeon
• Email: [email protected]
• Telegram handle: @ssjeonp
• Discord handle: ssjeon

Team Website

• https://github.com/ssjeon-p

Team's experience

PSE summer contribution 2023, learning about zkp and halo2.
Ph.D major in number theory and algebraic geometry (ongoing)

Team Code Repos

• https://github.com/ssjeon-p

Development Roadmap 🔩

Overview

• Total Estimated Duration: 8 weeks
• Full-time equivalent (FTE): 0.5
• Expected Start Date: Dec 18th 2023
• Expected End Date: Feb 11th 2024

Milestone 1

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated delivery date: Dec 31st 2023

Deliverables and Specifications

We want to study carefully about Liam Eagen's paper and some proof systems. We will focus on how the halo2 works and want to explore ways to optimize the ecip protocol if possible. The summary of what we studied will be posted on blog. After milestone 1, we will make concrete milestones such as functions we need or optimizations, for implementing the protocol at milestones 2 and 3.

Milestone 2

• Estimated Duration: 2 weeks
• FTE: 0.5
• Estimated delivery date: Jan 14th 2024

Deliverables and Specifications

We will first implement the simplest version of the ecip protocol. This doesn't require a zero-knowledge setting. But, this needs some general functions and algorithms, for example calculating function field elements of an elliptic curve using incremental construction or Mumford representation. We will deliver test functions to check these.

Milestone 3

• Estimated Duration: 4 weeks
• FTE: 0.5
• Estimated delivery date: Feb 11th 2024

Deliverables and Specifications

Now, we plan to make the protocol zero knowledge in scalars and points, and both. Each version needs some improvements using techniques in the paper. Plus, using elliptic curves with complex multiplication structure will reduce proof size so we want to explore this. After implementing every version of the protocol, we want to compare how this protocol improves performance compared to simply calculating multi-scalar multiplications on a circuit.

General Grant Proposal

• Project: [WIP] Porting over many zk-kit circuits from Circom to Noir #45

Project Overview 📄

Overview

This is a project to port zk-kit circuits from Circom to Noir.

Project Details

• As Noir is improving day-by-day with new features added and bugs fixed, rigorous testing of circuits are required
• Provide detailed documentation on every circuit to be ported.
• Optimize circuits by leveraging unconstrained functions wherever possible.

Team 👥

Team

• Rajesh Kanna
  • [email protected]
  • Telegram: verified_anon
  • Discord: verifiedanon

Team Website

N/A

Team's experience

• Implemented ECDH and KZG Commitment verifiers in Noir.
• Contributor and maintainer of Cryptography library in Noir. Helped with refactoring, optimizing, and fixing bugs.
• Built a Map like data structure which takes $O(1)$ constraint for insertion/removal.
• Contributor of Halo2 Backend for Noir.

Team Code Repos

• https://github.com/RajeshRk18

Development Roadmap 🔩

Overview

• Total Estimated Duration: 1.5 month
• Total Estimated Working Hours: 80 hrs
• Full-time equivalent (FTE): 0.5
• Expected Start Date: May 10th 2024
• Expected End Date: June 25th 2024

Milestone 1: Port circuits

• Estimated Duration: 20 days
• FTE: 0.5
• Estimated delivery date: June 1st 2024

Milestone 2: Optimize constraints

• Estimated Duration: 15 days
• FTE: 0.5
• Estimated delivery date: June 20th 2024

Milestone 3: Add tests

• Estimated Duration: 15 days
• FTE: 0.5
• Estimated delivery date: June 20th 2024

Deliverables and Specifications

0a. Codebase

Will have noir circuits for every circom circuit in zk-kit.

0b. Documentation

I will provide inline documentation of the circuits.

0c. Testing Guide

The circuits will come with lots of unit tests and integration tests(wherever possible).

0d. Benchmarks

I will try to add the number of constraints for every circuit.