vacp2p / research

Thinking in code
MIT License
62 stars 4 forks source link

Evaluate different code bases for ZKPs #93

Closed oskarth closed 2 years ago

oskarth commented 2 years ago

Problem

As we are moving towards more ZK based constructions, it is desirable to have some unity in terms of what we using as a building block. This is especially true for something as exotic as ZK, where we ideally want something that there's a community around and we don't have to build everything from scratch.

Details

There are many libraries out there. Non-exhaustive list:

In general, a lot of these are written in Rust. Things like Circom was initially written in NodeJS (and the complementary SnarkJS still is). Recently, Circom 2.0 came out which ports the compiler to Rust.

Currently, RLN was originally written in Circom/Node but had performance issues so was ported to Rust (based on Sapling/Bellman). However, things like Unirep are based on Circom and with JS tooling. Now that perf is better with Circom (Rust based, WASM, perf optimizations) this rationale might no longer make sense (unclear).

Circom is a nice high-level DSL for writing ZK. A lot of people are writing stuff in it, which means it acts as a form of Schelling point. However, in general the ecosystem there is currently quite JS focused.

From a Vac POV, we want something that works well both in browsers and Nim/systems environment.

It should be to use Circom 2.0 from C-based languages, but it has to be investigated further. There are also efforts like https://github.com/gakonst/ark-circom.

In general, to make a reasonable choice here requires quite a bit of understanding on underlying tech, what we need (e.g. open door to things like Halo2, plonk, etc), as well as how we can consume it an ergonomic and expressive way.

There might also be instances were we can use different setups, but making cross-platform will always be a consideration (Nim/JS/Solidity).

Acceptance criteria

Better understanding of what a sane choice here would be that meet our requirements in terms of cross-platform, having a community, being ergonomic, performant and expressive.

oskarth commented 2 years ago

I'd like to experiment a bit with different common options here to get a better feel for this. This will likely be an ongoing investigation for a bit. I'm taking inspiration form ZK Hack workshops that are currently running.

oskarth commented 2 years ago

I'm currently experimenting with using ark-circom. While Circom 2.0 is written in Rust, snarkjs isn't. Assuming this will work, we should be able to (1) write/use Circom DSLs (2) Interface with Arkworks world (3) Create thin Rust libraries and consume from Nim.

Started working on a minimal PoC/spike. Probably going to discovery more as we go, e.g. how Circom/Ark interacts etc and see how rough edges are etc.

oskarth commented 2 years ago

Update on ark-circom: currently it doesn't seem to support Circom 2.0. Upstream issue with notes here: https://github.com/gakonst/ark-circom/issues/8

oskarth commented 2 years ago

Brief update: Learned a bit of wasmer and found out why my wasm module was hanging for Circom 1 - there was a problem with public input variable name and the VM halted. Added error handling PR to ark-circom https://github.com/gakonst/ark-circom/pull/9

oskarth commented 2 years ago

Update: More stuff has been added here https://github.com/gakonst/ark-circom and Circom 2 support seems to work with https://github.com/gakonst/ark-circom/pull/18

Future work happening in new Zerokit repo https://github.com/vacp2p/zerokit

We need a more fully integration Circom 2 example to ensure there are no unknowns, but I don't see any major obstacles at this point. We have a reasonable path here, so can close this one. Once we've gotten further with full integration on both Nim/JS side we'll have further confidence in our choice, and if there are any major roadblocks we can revisit this.