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 . John starts by presenting SMPC, TEE and FHE and by listing the pros and cons of each approach. Because FHE seems to be the ideal approach, he then exposed how research on is aiming at addressing FHE cons.
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 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 that 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 are 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 solves someway 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 protocol is likely to be proposed later this year.
- Roundtable 1: GPU implementation of zksnark prover — Konstantin Panarin (Matter Lab)
This roundtable was animated by Konstantin Panarin from Matter Labs. Konstantin 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 . 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 — 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 (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 a APR witness is an actual Reed-Solomon code, in an efficient way.
- Fast Reed-Solomon Interactive oracle proof of proximity (FRI) to efficiently check the proximity to the Reed-Solomon codes.
Published at Sat, 23 Mar 2019 23:00:26 +0000
