Zero-knowledge summit - ZK0x03

On March 22nd 2019, I attended the third edition of zero-knowledge summit ZK0x03 held at Berlin. The summit was organized by Anna Rose and Fredrik Harrysson from zero-knowledge podcast, which is made for fellow developers and people looking to educate themselves on the inner workings of the blockchain zero-knowledge tech space. This one-day event focused on zero-knowledge topics, zkSNARK, MPCs, STARKs and blockchain scaling solutions featuring the following speakers:

• Ahivu Levy (StarkWare Industries) discussing scalability with STARKs
• Harry Roberts (Ethsnarks) sharing the history of high-level programming languages for making zk proofs
• John ‘Tux’ Pacific (Nucypher) on fully homomorphic encryption
• Jordi Baylina (Iden3) on Circom and Snarkjs
• Izaak Meckler (CODA Protocol) on the secrets of SNARK programming
• Alex Vlasov (Matter Labs) on scaling & privacy with zkSNARKs in Ethereum
• Aurélien Nicolas (QED-it, zkproofs.org) discussing zk standards
• Zachary Williamson (Aztec Protocol) on ERC-1724 confidential digital assets
• Igor Barinov (POA Network) on scaling with xDai and side chains
• Jonathan Levi (HACERA) on ZKPs for both permissioned and permissionless blockchains

There were also discussions on confidential transaction scheme based on 1-out-of-N proofs, GDPR and privacy of Zcash shielded transactions as well as deep-dive workshops on practical use and implementation of ZKPs, building a STARK with pen and paper and more. The program ran from 9:30 a.m. to 8 p.m. where talks were presented at two different filmed stages while roundtables and circle discussion happened on two other dedicated rooms. The full program can be found here and the playlist of videos here.

---

Since the program was running in parallel, I couldn’t make it to all the presentations so I chose 3 talks and 2 roundtables I was most interested in:

• Talk 1: scalability first with STARK — Ahivu levy (StarkWare industries)

This talk was about scalability using STARKs — It was presented by Ahivu, the head product of StarkWare, a startup that leverages on STARK technology to improve blockchain scalability and privacy. The main takeaway is that they are planning to release their first product mid-april which is a decentralized exchange (DEX) engine on Ethereum. While STARKs can solve privacy on the blockchain as it is widely believed, Ahivu thinks that they are the best candidate to solve scalability thanks to the exponentially small verifier running time.

• Talk 2: fully homomorphic encryption the road to secure computation — John Tux Pacific (NuCypher)

This talk was about secure multiparty computation (SMPC), trusted execution evironments (TEE) and fully homomorphic encryption (FHE) with focus on the latter. It was presented by John who is a cryptography engineer at NuCypher, a startup that works mainly on proxy-reencryption and FHE to build privacy infrastructure for the blockchain. John started by presenting SMPC, TEE and FHE, and and then listed the pros and cons of each approach. Because FHE seems to be the ideal approach, he then exposed how research is aiming to address FHE cons.

• Talk 3: Scaling and privacy with zkSNARKs in Ethereum — Alex Vlasov (Matter Labs)

Although the title of this talk is “scaling and privacy with zkSNARKs in Etherem”, the presentation was mainly about the new zero-knowledge protocol called SONIC and its comparison to the actual Groth16 zkSNARK protocol implemented in ZCash. The talk was presented by Alex who works at Matter Labs, a startup aiming to scale the blockchain using zero-knowledge proofs. SONIC is a new ZK proving system that requires an updatable and universal trusted setup — that means unlike other SNARKs, SONIC does not require a trusted setup for each circuit, but only a single setup for all circuits (up to a given circuit depth) and it never has to end, so it can be continuously secured by accumulating more contributions. To this point, Alex gave a nice comparison between usual SNARKs and SONIC; imagine you are playing a card game and you want some trusted deck of cards, in SNARKs you shuffle the deck and then you pass it to other players who shuffle it again every time you start a new game, but in SONICs you only shuffle the deck once and then “clone” it every time you start a new game (this works for every game that requires the same number of cards or less ~circuit depth). For efficiency comparison, Groth16 is still better (0.6s vs 9s for a single proof and 3s vs 11.5s for a batch of 5 proofs — according to Alex benchmark) but we still need an efficient SONIC implementation as in Bellman to compare apples to apples. The main takeaway is that SONICs are a real breakthrough that solve somewhat the SNARKs trusted setup issue. It is to mention that I discussed SONICs with Ariel Gabizon (former ZCash cryptographer who discovered the trusted setup counterfeiting bug in ZCash) after the talk and he believes that a lot of research is being conducted in this direction and more efficient protocols are likely to be proposed later this year.

• Roundtable 1: GPU implementation of zksnark prover — Konstantin Panarin (Matter Lab)

This roundtable was animated by Konstantin from Matter Labs. He started by describing NVIDIA GPU architecture and code parallelization principles with examples, then he discussed how we can benefit from GPUs to speedup the proving step in Groth16 zkSNARKs. The most important part of the proving step (~60% of the computation time) is the multi-exponentiation and one way to do this efficiently is using Pippenger algorithm (ZCash by the way moved from Bos-Coster algortihm to Pippenger after Sapling activation). We discussed how the algorithm works and how it can be enhanced using NVIDIA GPUs keeping in mind that an enhancement should not only address the computation time but also the memory cost.

• Roundtable 2: Building a STARK with pen and paper — Mathew Stevens and Micro Richter

This one was funny actually— we were 30 people at the beginning but only 10 stayed until the very end because of the heavy maths content. We deep dived into all the dirty details of the mathematical machinery behind zkSTARKS given a toy example (a Fibonacci sequence). The steps are:

• Arithmetic intermediate representation (AIR) to show a computation as an execution trace with algebraic registers and to create polynomial contraints,
• algebraic placement and routing (APR) to transform the AIR into functions that are Reed-Solomon codes if and only if the execution trace is a witness,
• Reed-Solomon proximity testing (RPT) to check that an APR witness is an actual Reed-Solomon code in an efficient way, and
• fast Reed-Solomon Interactive oracle proof of proximity (FRI) to efficiently check the proximity to the Reed-Solomon codes.

---

The summit was closed by a park bench panel animated by Anna and Fredrik in a game form. Anyone from the audience can ask any question but if it turns out to be an opinion/remark then she/he is invited on stage to answer the upcoming questions. Here is a question I asked (which is actually an opinion according to Mrs Justice Anna): “Zero-knowledge proofs (ZKP) like zkSNARKs or zkSTARKs are not proofs but arguments because the soundness is only computational and not statistical, so is it a mistake to call them proofs?”

Besides the talks which were really interesting, this event was an opportunity to meet a lot of people from the broad ZKP/Blockchain community and to discuss technical details with sometimes the authors of some papers I’ve been scouring over the few last months. For this reason, I want to thank the organizers Anna and Fredrik for putting all of this together and especially Xavier De Boissieu and Quentin Drouot from EY for making my attendance possible.