towers! • Google? • They are expensive… • We won’t pay them until they deliver • They won’t deliver until we pay… • Solution? Layers, escrows ◦ Nah ◦ Let’s go crazy!
papers, crayons and hats! • Let’s draw a blank cell network graph • We go out • Google enters and makes random assignment of 3 colors and colors papers • In the end Google covers all the vertices with hats!
know that google has done this properly? • Let’s challenge them! • Let’s pick a random edge and Google will remove hats connection them • Result? ◦ We found invalid solution -> Google is lying! ◦ Different colors -> Google might not be lying
say that maybe Google has found a solution • How to be sure? • Let’s try again! • Google shuffles colors • We choose one edge at random • Repeat until? • ~ E^2 iterations - we can be “sure” that Google is not lying • 1 iteration = (E-1)/E
in all of this? • 3 properties: ◦ Completeness: If Google is telling the truth, they will eventually convince me (with high probability) ◦ Soundness: Google can only convince me if they are telling the truth! ◦ Zero-knowledgeness: I don’t learn anything else about Google’s solution
:) • Digital commitment scheme ◦ One party commits to a message while keeping it secret ◦ Later opens the commitment to reveal what’s inside • Prover encodes vertex coloring as a set of digital messages • Commitments are sent to Verifier • Verifier challenges on an edge, Prover reveals opening values • Prover = Google, Verifier = We • Zero knowledge part? Verifier is computer program that gets Provers input and computes it • We start program over and over until we are pretty sure (E^2 times)
Interactive proof • Verifier online and interacting with us! • From Schnorr to Fiat and Shamir • NIZK - Non interactive zero knowledge proof • Let’s replace Verifier with hash function (random oracle) • Not just proof but also signature scheme - based on EdDSA ◦ https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange ◦ https://en.wikipedia.org/wiki/Digital_Signature_Algorithm
More time consuming than SNARKs • Enabling efficient confidential transaction in Bitcoin (UTXO based) • Range proofs • No pairings • Works with elliptic curves • Convertible to R1CS
by certain initial parameters which are later destroyed • We trust the person to actually destroy the parameters -> trusted setup • MPC - multi party computation • Powers of Tau - constructs partial zkSNARK parameteres for all circuits ◦ Takes a step that is performed by all zkSNARK MPCs and does it in just one single ceremony ◦ BLS12-381 elliptic curve - https://github.com/zkcrypto/pairing/tree/master/src/bls12_381
Shielded Transactions ◦ Shielded addresses (use zk-SNARKs) ▪ Transaction address (private) ▪ Amount (private) ▪ Memo field (private) ◦ Transparent addresses ▪ Everything is public ◦ No interoperability between shielded and transparent addresses (only shielded to shielded or transparent to transparent) • Ceremony for the trusted setup per circuit upgrade ◦ Painpoint or feature? :) • Libsnark (C++) -> Bellman (Sapling upgrade)
◦ Adding other user’s funds so that real sender cannot be detected ◦ Mixin level (fee) ◦ Ring CT (Ring confidential Transactions) ▪ Source (private) ▪ Amount (private) ▪ Only sender and receiver know this values
(Bulletproofs) • Beam - private and scalable coin based on MimbleWimble • SNARK based permission database ◦ Rollup by BarryWhitehat • Gnosis dFusion ◦ DEX on SNARKs • Loopring DEX protocol • zkPoD ◦ Practical decentralized system for data exchange • Etc.
operators offchain) - no L1 storage! ◦ Plasma problem -> availability • Rollup contract on the mainchain • Optimistic ◦ New state root published by operator without being checked by Rollup smart contract ◦ We hope state transition is correct! :O ◦ Others can point to malicious transaction and slash malicious operator ◦ ~ 500 TPS ◦ 1-2 weeks fraud proof challenge window!
◦ No efficient technique for succinct recursive proof composition of ZKPs ▪ Different smart contracts in a single block ◦ Groth16 ▪ Cycles of elliptic curves - https://arxiv.org/abs/1803.02067 - inefficient for large computation ▪ Trusted setup - for every smart contract and every update! (Impossible in practice) ▪ FRI-based STARKs (limited in scope) - without trusted setup ◦ EVM support (Istanbul upgrade) ◦ ~ 2000 TPS ◦ For a block of 1000 tx ~ 20 minutes proof generation time ▪ GPU optimization - 10x - ASICs? • Instant transaction confirmation by operators - staking security deposit
programs to constraint systems provable with zkSNARKs • Tools for ◦ Setup phase ◦ Witness computation ◦ Proof generation ◦ Generation of Verification Smart Contract ◦ ... High Level Language PROVER VERIFIER.SOL
Does not expose non-determinism to the programmer // Primitive Types field a = 42 bool b // Composite Types field[256] c = [0; 256] Point p = { x = 0, y = 1 }
knowledge of the preimage for a given hash digest • Preimage = inverse image • Hash digest -> output of the hash • sha256packed - SHA256 optimized for ZoKrates DSL • 4 x 128bit inputs that represent 512 long input of sha256 ◦ Field can only hold 254 bits
A is Verifier • Person B is Prover • Person A computes the hash of the input value ◦ Compile ◦ Compute witness (0,0,0,5) • Person A adds the hash to the code ◦ h[0] == 263561599766550617289250058199814760685 ◦ h[1] == 65303172752238645975888084098459749904 ◦ And checks that hash is compatible with the requested one • Person A then generates the verification and proving key with setup • Person A than calls export verifier which generates solidity contract representation
Person A than deploys smart contract on the network (in this case Rinkeby) • https://github.com/blockchain-it-hr/proof-of-preimage ◦ There are hash and hashspecific folders ◦ Hashspecific contains hash generated by input parameters: 0, 0, 0, 5 which are then checked against
B is Prover • Person B wants to prove that he/she knows a preimage for a digest chosen by Person A • Person B has received proving key from Person A! • Person B provides a correct pre-image as an argument to the compute-witness (0,0,0,5) • Then person B generates proof that it will send to smart contract • Proofs consists of public inputs (without private ones! -> zero knowledge feature), 3 elliptic curve points and output of the computation • Proof generated like this is send to verifyTx function inside deployed smart contract • Person A listens to Verified event which is emitted upon successful verification
edisinovcic
matleenalaakso
signer
o_ob
kaityo256
takuro_nakajima
irocho
asial_edu
denniskardys
paulrobertlloyd
philhawksworth
geoffreycrofte
holman
3n
eitanlees
jlugia
addyosmani
jonyablonski
mraible
![Q&A Edi Sinovčić [email protected] twitter.com/edisinovcic linkedin.com/in/edi-sinovcic/](https://files.speakerdeck.com/presentations/b990e61a1fbf492080e2656765522170/slide_35.jpg){kind=link}