0xparc project proposal: zk-identity

Members

Jeff, Veronica, Lakshman

Description

A set of Ethereum contracts+webapp that allows a user to prove that they were a previous DarkForest winner without revealing their Eth address. If they do so successfully, an NFT is minted saying as much.

All verification logic should happen on-chain.

Architecture

Flow:

Contracts:

Alternately, if the cost of verifying a merkle root on-chain is prohibitive in terms of gas cost, we could assume that the user needs to provide the merkle root of winners themselves and trust 3rd parties to attest to this off-chain.

ZK-Circuit

template VerifyDFWinner {
    signal input sig;
    signal input msg;
    signal input pubkey;
    signal input df_winner_branch;
    signal input df_winner_root;
    
    signal output verified_bool;
}

verified_bool is true if sig (private) is an ECDSA sig of msg (private) by the private key corresponding to pubkey (private) and pubkey corresponds to an Eth address that is in df_winner_root (public).

sig takes the role of private key here as we don't want users to have to stick their private keys into a web browser.

Open Questions

  • is ECDSA sig verification viable within a circuit?
  • is accumulator verification feasible from a gas perspective?
    • if so, we can just move root generation off-chain and assume that there's an off-chain provider network for these
  • how do we generate signature, etc. for an account that doesn't interact with the contract?
    • could do full proof generation from one account and then ask user to use a different account to submit

Misc Notes

  • generate merkle tree online vs. offline? online vs. offline?
    • on-chain is nice, but likely to be very expensive and bottleneck us, perhaps it's worth making this extra credit
  • df winners is a static dataset, so simplest thing is to just store root and all branches locally
    • store merkle root + address -> branch
  • future stuff
    • is there a fraud-proof mechanism for keeping a 'correct' merkle root on-chain? i.e. a way for someone to prove that a merkle root is wrong at some point in time?
    • define the 'canonical' mechanism of constructing a root given some addresses in the 'fraud proof' mechanism
      • could do this for a changing membership set even!

Scoping

  1. verifier circuit in circom
  2. script for generating merkle root, merkle paths
  3. verifier contract that mints NFTs
    • use a nullifier to prevent replay. basically, nullifierHashes mapping in contract nullifier = hash(hash(sig)) for some none ECDSA hash function (i.e. MiMc)
    • stub out ECDSA circuits as defined here
  4. frontend that allows one to generate proof + submit from a different account

Data

https://drive.google.com/drive/folders/1GntE1LmV9rq6_eICt-EXjZvYtgthbhIf?usp=sharing

TODO

  • finish unit testing circuits
  • generate merkle roots + branches
  • 'middleware' code using snarkjs for generating proofs + sending to contract
  • web frontend
Select a repo