Goals
- Proof of Correct RetroPGF Result Calculations: The primary goal is to establish the correctness of the RetroPGF results, particularly confirming that these results are accurately computed based on the inputs provided by badgeholders. This involves detailed validation of the computational processes and ensuring the integrity of the input data.
Work so far
We have leveraged ezkl to build a ZK equivalent circuit of the RetroPGF calculation. The notebook has associated markdown cells that explain the circuit and the steps to build it.
-
We first build a pytorch equivalent of the original allocator function, originally in pandas.
-
We then export the pytorch function to an onnx file and use the ezkl compiler to convert it into a zk-circuit.
-
We generate a proof for a given input and verify.
-
We add sanity checks for numerical accuracy and compare the results with the original pandas function outputs.
https://github.com/zkonduit/zk-rpgf
Scope of next work
- Signature verification - add the verification of signatures. Note that a proof must take as input all the JSON ballots and signatures, show that each hash of each JSON ballot matches the hash in the signature, parse and extract the data from the JSON, combine to an output data frame, check the signatures, and show the signers are exactly the badgeholders and that each ballot was counted exactly once, all inside the proof.
- Output option a: hash of DataFrame (with voter data removed as well).
- Output option b: DataFrame with voter information removed and solely leave relevant data: (project, amount).
Note: this is only the checked ballots at this stage NOT the final allocation yet.
- Combining the work so far (ZK of computations) with the signature verification step.
Note: this is now the final allocation.
- Run proof generation - generate the proof
- Ease of verifying the proof - allow users to easily verify the generated proof in their browser (or on-chain perhaps: TBD).
Required steps to complete this scope:
- Design the most efficient schema for signature verification. Notably this should not require further involvement from badgeholders (they should be passive in the process) OR impose undue burden on the browser (or on-chain) verifiers. Estimated time: 2 weeks.
- Implementation of the schema designed in 1 (may require small extensions to the ezkl library and custom ZK circuits). Estimated time: 2 weeks. (requires step 1.)
- Generate proof and host verifier files (this can be left to us if you so wish!). Estimated time: 4 days + additional infrastructure. (requires step 2. but can start alongside step 2 to shorten)
- Generate JS code / web page (with OP branding and a fun interesting UX) and host on vercel. Estimated time: 1 week. (can start with step 2. once we’ve picked a schema in step 1.)