Leveraging zero-knowledge proofs to improve privacy on Ethereum

1. Privacy Preserving State Transitins in
Ethereum
Antoine Rondelet
Thursday 30th
May 2019
ZKP Meetup, Binary District – London, UK
@antoineRnd (Telegram)
@itranneo (Twiter)
htps:/p/pkpeybase.sio/pantoinerondelet

2. Ethereum: Distributed state machine

3. Smart cintract: Specify state transitins
Set() can be called with 2^256 values (2^256 possible
state transitons)

4. What abiut “ZK State transitins”?

5. Quick reminder: ZKPs
• Proof ~ “Something that convinces someone that a statement is true”
• Here, we’ll be interested to prove that x belongs to L, or equivalently, that there exists
w such that (x, w) belongs to the bin.s rel.s R
• Proof system ~ “Procedure that decides which proof are convincing and which are not
(acc/prej)”
• Traditonal mathematcal proofs (checkped line by line) =/p= Probabilistc proofs (use
randomness, a false proof is accepted with negligible probability)
• “Zero-kpnowledgeness” ~ “You kpnow nothing except that x is in L” (Simulator)
• Diferent types of setngs of interest:
– Interactvity (Prover and Verifer engage in sequence of messages, and Verifer
decides if acc or rej)
– Non-Interactvity (Prover sends proof to Verifer (1 msg), and Verifer decides)
– Zero kpnowledge
– Public/pDesignated verifability …

6. (zk)SNARKs: Blickchain friendly
• Argument ~ Computatonally sound proof (the prover is assumed to be computatonally biunded)
• Proof of Knowledge (PoK) ~ “It’s not enough to prove to me that there exist a pair (x, w) IN R, I
want to have the proof that you kpnow such pair!” This idea is captured by the noton of an
Extractor.s
• Succinctness ~ We want to makpe sure that the proof is small compared to the size of (x, w), and
that it is quickp to verify => Perfect for us! We can do on-chain verifcatons + we can limit the
impact of storing proofs on-chain.s
+
• Very fast verif
• Small proofs
-
• “Trapdoored”
• CRS/prelaton

7. Using zkSNARKs
• Defne the NP-statement: “What do you want to prove?”
• Represent your propositon as an arithmetc circuit C (defied over a f. feld F)
• We denote the 2 operatons of F by + and * (additon and multplicaton)
• The prover shows kpnowledge of a satsfable assignment to C (ie: valid soluton to
circuit-SAT for C)
– Here the idea is that only x in (x, w) is used as input of the circuit.s
– The witness w, however is used “inside C”, in the intermediate wires/pgates (“ioi-
determiiism”)*
– The goal here for P is to show to V that on input x, the output of the circuit is 1,
WITHOUT leakping any informaton about the intermediate/pinner state of C
*Note: If there is no witness w, then there is not point in using zero-kpnowledge since the internal state of the circuit C
can be recomputed by the verifer on input x (no source of “non-determinism”).s

8. Representng the relatin R: R1CS prigramming
• The arithmetc circuit is a compositon of multplicatve sub-circuits (a single * gate
and as many + gates as we want)
• Each multplicatve sub-circuit C_i can be expressed in the form of a constraint:
(A)(X) * (B)(X) = (C)(X)
<=> [A] * [B] = [C]
Where [A], [B], and [C] are linear combinatons, the vectors (A), (B) and (C) contain the
coefcients of the linear combinaton, and (X) is the vector of variables.s
• The set of constraints represents an arithmetc circuit, and now the challenge is to
prove that we kpnow a valid assignment of the input gates of the circuit (circuit-SAT)

9. Representng the relatin R: R1CS prigramming (Example)
(= 0)

10. Frim R1CS ti SNARK (Apprix!)
• R1CS → QAP (“compact representaton of a R1CS using sets of polynomials instead of matrices” → set of points to
interpolate → preprocessing phase)
• QAP → (k-)LPCP
– π → vector of feld elements
– V computes a set of queries (using Query algorithm Q) that are sent to P
– P applies the queries to the proof and send the answers to V (a_i = <π, q_i>)
– V runs the Decision algorithm D on the answers to accept or reject
– Assumptons:
●
The priver P is assumed ti be linear + hinest (use π with all queries)
●
V is assumed to be honest (send truly random queries ~ “doesn’t try to cheat” → non-adaptve) – HVZK
• (k-)LPCP → LIP (2 move)
– V sends all the queries at once to P (q = (q_1 || … || q_k))
– P applies a linear functon to q to compute all answers at once and send them to V.s (P is “forced” to use the
same π with all queries → done by adding an extra query which is a linear combinaton of the others))
– V stll assumed to be honest (HVZK) and P stll assumed to be linear
• LIP → SNARK
– P is enforced to be linear by using a linear encoding scheme (linear operatons are done “in the exponent” but
leveraging homomorphic propertes of the scheme)
– V cannot get the “plaintext” values of the answers a_i (encoding scheme), but can do the verifcaton
Careful with the selecton
of your feld now that
you’re manipulatng
polynomials! (ie: FFTs)
R1CS
(Circuit-SAT)
zkpSNARK

11. Private payment priticil: Intuitin

12. Zericash
• Ben-Sasson et al.s presented the Zerocash protocol [BCG+14] as a Decentralized
Anonymous Payment (DAP) scheme workping on top of Bitcoin.s
• Deposit public funds in a “shielded pool” and miit the equivalent value of
“obfuscated funds” represented by notes.s These notes are maintained in a Merkple
tree in an obfuscated form.s Consensus is reached over obfuscated data.s
• “Buri/Destroy/Pour” notes to create new ones (of potentally new owner!) such that
the sum of the burnt notes = sum of the value of the new ones.s
• A new address scheme is introduced to makpe the system workp
• Uses zkpSNARKs to generate proofs that payments are valid (namely, no double spent
occurs in the transacton and no value is created “out of thin air”)
• New payment semantcs added to be able to workp on top of a Bitcoin-likpe system
which require a hard-forkp!
See this great talkp at CESC2017 by A.s Chiesa: htps:/p/pwww.syoutube.scom/pwatch?v=84Vbj7-i9CI

13. ZETH: Zericash in Ethereum (intuitin)
• Follows the Zerocash construct and adapts the protocol to workp on Ethereum
• “Oily obfuscated data is kept oi-chaii, aid the partcipaits prove that they behave
correctly” (ie: The system remains sound, no value is created and so forth.s)
• We use ZKPs to makpe sure that we have an overwhelming confdence that the rules of
the system are followed, while ensuring that no informaton about payments can be
extracted from the proofs (let’s put the recipieit and value of a note in the witness =>
Remember this is the source of “ioi-determiiism” of our circuit)
• Implement the shielded pool on a smart contract, and leverage Ethereum events to
implement an encrypted broadcast mechanism that breakps the linkp between sender
and recipient.s
• Turing completeness of the EVM allows to encode any type of payment semantcs.s Ni
midifcatins needed in the priticil (ie: No need to forkp the same way Zcash did
from Bitcoin!)

14. ZETH: Zericash in Ethereum (fiw)
• Sender (S) and recipient (R) never talkp
to each other.s S encrypts the note
with R’s public kpey and adds the
ciphertext as argument to the “Mix
call” of the mixer contract
(assumpton: IK-CCA Enc.s Scheme)
• Pros: Resistance against HD failure
• Cons: Ciphertext stored on-chain
• The Zeth mixer contract provides a
layer of abstracton/pobfuscaton
seatng on top of Ethereum

15. ZETH =/> Aninymity
Stll need to pay for the gas of the “Mix” functon => Yiu can distnguish between
networkp users using Zeth and those who don’t.s Can be a real problem in some
circumstances!

16. ZETH: Zericash in Ethereum (sifware)

17. Giing further / Zeth is WIP
• MPC for the CRS generaton
• Optmizatons
• Prety much in the PoC stage
• Checkp out our online resources:
- Zeth white-paper: htps:/p/parxiv.sorg/pabs/p1904.s00905
- Implementaton: htps:/p/pgithub.scom/pclearmatcs/pzeth
Happy to get any feedbackp/pcontributon !

18. References
• [BCGGMTV14] E.s Ben-Sasson, A.s Chiesa, C.s Garman, M.s Green, I.s Miers, E.s Tromer, M.s
Virza, “Zerocash: Decentralized Anonymous Payments from Bitcoin”
• [BCGTV13] E.s Ben-Sasson, A.s Chiesa, D.s Genkpin, E.s Tromer, and M.s Virza.s “Snarkps for C:
Verifying program executons succinctly and in zero kpnowledge”
• [BCIOP13] N.s Bitanskpy, A.s Chiesa, Y.s Ishai, R.s Ostrovskpy, and O.s Paneth.s “Succinct non-
interactve arguments via linear interactve proofs”
• [GGPR13] R.s Gennaro, C.s Gentry, B.s Parno, and M.s Raykpova, “Quadratc span programs
and succinct NIZKs without PCPs”
• [GMR88] S.s Goldwasser, S.s Micali and C.s Rackpof, “The Knowledge Complexity of Proof
Systems”
• [PV10] R.s Pass, M.s Venkpitasubramaniam, “Private Coins versus Public Coins in Zero-
Knowledge Proof Systems”
• [RZ19] A.s Rondelet, M.s Zajac, “ZETH: On Integratng Zerocash on Ethereum”

19. Q&A
Thankps for your atenton!
Any queston?
PS: If you feel excited by peer-to-peer networkps, cryptography and all the challenges
raised by blockpchain tech, we’re hiring! ;)
@antoineRnd (Telegram)
@itranneo (Twiter)
htps:/p/pkpeybase.sio/pantoinerondelet