ZK7 summit review
In April of this year, I attended Devconnect Amsterdam as part of the Onther team. One of the events at the conference was the Zero Knowledge Summit 7 which I will review in this post. All of the talks at ZK7 are available on their youtube channel, here I will give a short summary of some of the talks that I attended.
Spice up your ZK with some kimchi — Joseph Spadavecchia & David Wong — O(1) Labs / Mina
In this talk they introduced Kimchi which is a version of Plonk with various customisations and improvements. Instead of the usual rank-one-constraint-system (R1CS) used by zk-SNARKS such as Groth16, Sonic and Marlin; Plonk uses a different constraint system. One drawback of the constraint system used in Plonk is that, while R1CS doesn’t have any limit on the number of input wires into each gate, in Plonk each gate can only have two input wires. This makes certain computations require more gates(constraints). Kimchi defines more general gates which allow up to 15 input wires. This allows certain things such as the Poseidon hash function and elliptic curve operations be writted much more efficiently. Another improvement introduced by Kimchi is that instead of using Kate commitments it uses a Bulletproof polynomial commitment scheme, which means there is no need for a trusted setup.
Verifying STARKs with SNARKs — Jordi Baylina — Polygon Hermez
In this talk Jordi Baylina discussed how to verify a STARK with a SNARK. This research is coming from the team working on Polygon Hermez 2.0. Firstly you may be asking why would we want to do this? Why not make the proof using either just a STARK or just a SNARK? The reason is that proof generation time is quicker for STARKS, but SNARKS have a quicker verification time and smaller proof size. Hence by doing it this way, our prover just needs to create a STARK proof for the computation we want to proof and a SNARK proof for the verification of this proof (which is smaller compared to the original computation) and the verifier still only needs to verify a SNARK proof. The work that needs to be done is translating the STARK verification algorithm into a circuit. (In polygon Hermez, the circom language is used for this). Where as usually when choosing the design for your STARK you need to focus on making the proof size as small as possible, here we don’t need to worry about that since the verifier wont have to check the STARK proof directly. Instead we can optimize the design to minimize the prover time.
Efficient Private Delegation of zkSNARK Provers — Pratyush Mishra — Aleo
One of the weaknesses of zkSNARKS is their prover time, in other words it takes a long time to create the proof. One solution to this is outsource the prover work to a group of ‘workers’. But outsourcing the proving means that you need to send your witness to the workers. In this talk Pratyush Mishra described how to delegate the creating of a zkSNARK proof to a group of workers in such a way to preserve privacy, more accuratley threshold privacy — if at least one worker is honest, then your witness remains a secret. This is done using a ‘homomorphic secret sharing scheme’ which is a way of taking a message m and dividing into n parts
such that if all n parts are known then the message can be recovered, but if even one part is missing then no information about the message can be deduced. Furthermore, this function is homomorphic so we can add the iᵗʰ secret share of a and the iᵗʰ secret share of b to get the iᵗʰ secret share of a+b.
The way this is used is that the delegator divides the witness into secret shares and sends one secret share to each worker. Since the majority of the prover algorithm involves linear operations, the workers can use their secret share to compute the secret share of the proof [[π]_i. The non-linear parts of the algorithm are cheap so can be done by the delegator as a helper. Finally the delegator can combine the secret shares of the proof together to get the full proof π.
VampIR: universal representation for arithmetic circuits — Joshua Fitzgerald — Anoma
In this talk Joshua Fitzgerald introduced VampIR (Aliased Multivariable Polynomial Intermediate Representation). When writing an arithmetic circuit, the way it needs to be written depends on the proof system that is going to be used to make a proof for the circuit. This is because different proof systems use different constraint systems, for example R1CS or Plonk style contraints. This means that circuit written in different contraint systems can look very different, which makes benchmarking performance as well as reconfiguring circuits difficult. VampIR is a language which gives a canonical way to write a circuit, which can then be compiled to use with any proof system backend.
Overall the event brought to light how many different people and teams are working on zk related projects and the atmosphere had a buzz of excitment about the potential of this technology in the blockchain space. Onther is planning to send team members to similar such events in the future, and I will write summary articles for those when they happen. Stay tuned.
