feat: proof verification page

[lsankar4033]

Although heyanoun proofs are shared publicly and accessible on IPFS, we don't make it easy for users to verify their veracity.

One solution here is a single page for verifying any proof (via copy/paste). Presumably, this page should also check that the given proof corresponds to a specified prop/message.

[DanTehrani]

I was just thinking about this yesterday @lsankar4033 !

Firstly will heyanoun be interested in using Spartan-ecdsa? I believe the current proofs w/ eff-zk-ecdsa are too large (over a megabyte), and will have a pretty slow verification.

Spartan-ecdsa will have much smaller proofs (~30 kb) and a decent interface for both proving and verification, so I recommend working on this after switching to spartan-ecdsa if you are going to!

[lsankar4033]

@DanTehrani when you say current proofs are too large, you mean b/c of the inputs right?

I suppose you mean spartan-ecdsa w/o 'efficient_ecdsa' then, right? I think this makes sense!

Moving the entire input over for the groth16 eff-ecdsa version may be too cumbersome for this feature, so waiting on spartan-ecdsa w/o efficient-ecdsa could make sense (realizing in writing this out we might need better names haha)

[DanTehrani]

@lsankar4033 Yep the inputs are the bulk of the proof in efficient-zk-ecdsa, but the large proofs are not necessarily the feature of efficinet-ecdsa. Spartna-ecdsa uses the same technique of rearranging the ecdsa verification, but doesn’t use the precomputation technique, so inputs are small.

Another consideration is the proving time; I heard from Vivek that Heyanoun currently uses the ecdsa_verify_pubkey_to_addr circuit? (i.e. uses an address group not a public key group?) Using address group means doing keccak in proving, so not much improvement in proving time from eff-zk-ecdsa even after switching to spartan-ecdsa. Wdyt about the proving cost aspect?

[lsankar4033]

@DanTehrani Hmm yes, we use the 'addr' circuit, so proving time still limited by keccak.

I think the right approach here is to keep track of whcih anonymity sets for which we have all pubkeys (i.e. b/c they made a tx on Ethereum) using a more robust version of https://github.com/personaelabs/20byte and have a separate (shorter) proving path for those groups relative to others. Invisible to the users overall, but some proofs will just take longer b/c we won't have pubkeys.

This adds some additional backend work ofc (to essentially 're-merkleize' an address group when it's detected that we have access via txes to all pubkeys).

[DanTehrani]

@lsankar4033 Switching between w/ keccak and w/o keccak will be really nice! But only using the keccak ver for simplicity also makes sense.

I’ll leave the decision to switch to spartan-ecdsa or not to you, but lmk if you have suggestions/questions!