recursive snarks - cs251.stanford.edu
TRANSCRIPT
Recursive SNARKs
CS251 Fall 2021(cs251.stanford.edu)
Benedikt Bรผnz
Recap: Non-interactive Proof SystemsA non-interactive proof system is a triple (S, P, V):
โข S(๐ถ) โพ public parameters (Sp, Sv) for prover and verifier
(Sp, Sv) is called a reference string
โข P(Sp, ๐,๐) โพ proof ๐
โข V(Sv, ๐, ๐ ) โพ accept or reject
Recap: zkRollupToday: every miner must verify every posted Tx verify
all Tx
verifyall Tx
verifyall Tx
verify all Tx โ short proof ฯ
summary, ฯ
verifyฯ
verifying proof is much easier than verifying 10K Tx
verifyฯ
Rollup Server
Recap: zkRollupToday: every miner must verify every posted Tx verify
all Tx
verifyall Tx
verifyall Tx
verify all Tx โ short proof ฯ
summary, ฯ
verifyฯ
verifying proof is much easier than verifying 10K Tx
verifyฯ
Rollup Server
Rollup with many coordinators
summary2,
ฯ2
verifyฯ
verifyฯ
Server 2
Server 1
summary1, ฯ1
summary, ฯ
verifyฯ
Zk-zk-Rollupโข Multiple serversโข Each responsible for subset of users (no overlaps)โข Rollup aggregator (can be one of the servers)โข Rollup aggregator combines summaries (balance table) and
creates one proof thatโข How can we combine proofs?โข Trivial solution: โข All servers forward all Txโข Rollup aggregator creates one SNARKโข Does not save work
Recap: Non-interactive Proof SystemsA non-interactive proof system is a triple (S, P, V):
โข S(๐ถ) โพ public parameters (Sp, Sv) for prover and verifier
(Sp, Sv) is called a reference string
โข P(Sp, ๐,๐) โพ proof ๐
โข V(Sv, ๐, ๐ ) โพ accept or reject
SNARK of a SNARK ProofA non-interactive proof system is a triple (S, P, V):
โข S(๐ถ) โพ public parameters (Sp, Sv) for prover and verifier
(Sp, Sv) is called a reference string
โข P(Sp, ๐,๐) โพ proof ๐
โข V(Sv, ๐, ๐ ) โพ accept or reject
SNARK of SNARK
๐ ๐ถ โ ๐!, ๐"๐ โ ๐(๐!, ๐ฅ, ๐ค)
Now write a circuit ๐ถโฒ that verifies ๐: โข Input ๐ฅโฒ is xโข Witness ๐คโฒ is ๐โข ๐ถโฒ(๐ฅโฒ, wโ) = 0 iff V(๐", ๐, ๐ฅ)=Accept Finally:
๐ ๐ถโฒ โ ๐โฒ!, ๐โฒ"๐โฒ โ ๐(๐โฒ!, ๐ฅโฒ, ๐คโฒ) 9
How can we aggregate proofs?
SNARK of SNARKs
๐ ๐ถ โ ๐!, ๐"๐# โ ๐(๐!, ๐ฅ#, ๐ค#) ๐$ โ ๐(๐!, ๐ฅ$, ๐ค$)
Now write a circuit ๐ถโฒ that verifies ๐: โข Input ๐ฅโฒ is x1||x2
โข Witness ๐คโฒ is ๐#||๐$โข ๐ถโฒ(๐ฅโฒ, wโ) = 0 iff V(๐" , ๐ฅ#, ๐#)=Accept and V(๐" , ๐ฅ$, ๐$)=Accept Finally:
๐ ๐ถโฒ โ ๐โฒ!, ๐โฒ"๐โฒ โ ๐(๐โฒ!, ๐ฅโฒ, ๐คโฒ) 10
How can we aggregate proofs?
SNARK of SNARKs
โข Note that Cโ depends only on V and Sv (not on C1,C2)โข We can express V as a circuit:
๐! ๐ฅโฒ ๐โฒ
+ โ
ร
0 = โ๐ด๐๐๐๐๐กโ ๐ค2 = ๐โฒ is independent of ๐ค3, ๐ค4|Cโ|=2*|V| < |2* C|
Building SNARK of SNARKs
โข How big is Cโ?โข Comparison |SHA256 circuit| = 20k gatesโข First SNARK of SNARK ~1 million gates with trusted
setup (BCTV14)โข Today less than 50k gates (Halo, BCLMS20, Nova) โข no trusted setup
โข Independent of inner SNARK circuits!
Rollup with many coordinators
summary2,
ฯ1
verifyฯ
verifyฯ
Server 2
Server 1
summary1, ฯ2
summary, ฯ
verifyฯ
Zk-zk-Rollupโข Let rooti be the Merkle Tree Root of summary i
โข S!, ๐" โ ๐บ(๐ถ#) // ๐ถ# rollup circuit
Merkle tree๐๐๐๐ก1 ๐๐๐๐ก2 ๐๐๐๐ก3 ๐๐๐๐ก5
root
Build one root from summaries
๐ถ67!(x = S8, ๐ซ๐จ๐จ๐ญ; w = ๐๐๐๐ก3, ๐๐๐๐ก4โฆ , ๐3, ๐4, โฆ ):V(S8, ๐ฅ = ๐๐๐๐ก9, ๐9) for all i and ๐ซ๐จ๐จ๐ญ=MT(๐๐๐๐ก9s)
Tornado cash
nf1
nullifiers
coinsMerkle
root
Treasury: 300 DAI100 DAI pool:each coin = 100 DAI
nf2(32 bytes)
C1 C2 C3 C4 0 โฆ 0
tree ofheight 20
(220 leaves)
public list of coins
nf, proof ๐ , A(over Tor)
nf
nf and ๐ reveal nothing about which coin was spent.
But, coin #3 cannot be spent again, because nf = H2(kโ) is now nullified.
โฆ but observer does not know which are spent
100 DAIto address A
Merkleroot
H1, H2: R โพ {0,1}256
next = 5
contract state
Withdraw coin #3to addr A:
zk3-Rollup (tornado cash rollup)
summary2,
ฯ2
verifyฯ
verifyฯ
Rollup Server 2
Rollup Server 1
summary1, ฯ1
summary, ฯ
๐:;
๐:;
๐:;
๐:;
verifyฯ
zk3-Rollupโข Users create SNARK for TC Circuit ๐ถ"#
โข S$, ๐% โ ๐บ(๐ถ"#)โข ๐"# โ ๐(๐% , ๐ก๐ฅ, ๐ค)
โข Rollups create SNARKs for ๐ถ& = โ' ๐ ๐( , ๐ก๐ฅ' , ๐' = โ๐๐๐๐๐๐กโโข ๐ก๐ฅ ๐๐๐๐ก = ๐๐ ๐ก๐ฅ), โฆ , ๐ก๐ฅ*โข ๐+ = ๐"#,)|| โฆ ||๐"#,*โข S$โฒ, ๐%โฒ โ ๐บ(๐ถ&)โข ๐& = ๐(๐%+ , ๐ก๐ฅ ๐๐๐๐ก, ๐+)
โข Rollup Aggregator creates SNARK for ๐ถ- = โ' ๐(๐(โฒ, ๐๐๐๐ก' , ๐&,')โข S$++, ๐%++ โ ๐บ(๐ถ-)โข ๐๐๐๐ก = ๐๐(๐๐๐๐ก), โฆ , ๐๐๐๐ก.)โข ๐&โฒ = ๐&,)|| โฆ ||๐&,.โข ๐- = ๐(๐%++, ๐๐๐๐ก, ๐&+ )
Enhancing transactions with SNARKsโข Weโve seen that private transactions require zero-
knowledge proofsโข Add ZK-SNARKs to every transactionโข Level 1 coordinators verify transaction by verifying
transaction ZK-SNARKsโข Additionally, we can have more complicated transactions
(Smart Contracts) โข Transaction verification is constant time regardless of
proof complexityโข Can we also hide the smart contract?
ZEXE private execution
โข ZEXE is a model of computation (like UTXOs/Scripts or Accounts/EVM)
โข The basic unit is a record (similar to a UTXO)โข Every transaction consumes records and creates
recordsโข Universal predicate: Prevents double spendsโข Birth predicate: Says how a record can be createdโข Death predicate: Says how a record can be consumed
ZEXE private executionRecord 1:Birth predicate 1Death predicate 1Payload 1
Record 2:Birth predicate 1Death predicate 1 Payload 1
Record 3:Birth predicate 3Death predicate 3Payload 3
TX checks that Record 1 and Record 2 have not been spentBirth3(R1, R2,R3) and Death1(R1, R2,R3) and Death2(R1,R2,R3)
ZEXE private executionโข Universal predicate (similar to tornado cash)โข Uses nullifiersโข Checks that nullifier=H(sk,records) is properly
createdโข Checks that nullifier only appears onceโข Prevents double spends
Merkleroot
tree ofheight 20
(220 leaves)
R1 R2 R3 โฆ 0 0 0
Implementing assets with ZEXE
โข Record payload has a value v and an asset id โข Birth predicateโข Defines the tokenโข New record id needs to match consumed predicate idsโข New record value is sum of inputs
โข Death predicateโข Defines the SCRIPTโข E.g. spendable by signatureโข E.g. Spendable by multisigature + preimage of hash
Implementing smart contracts with ZEXE
โข Record payload is state of smart contract, smart contract instance id
โข Birth predicateโข Either creates smart contract orโข One of the inputs needs to be the old smart
contract recordโข Death predicateโข Defines the smart contract logic
ZEXE game of Chessโข Record payload is state of smart contract, smart contract
instance idโข Birth predicate
โข Starts new game (and assigns pks to black/white) orโข One of the inputs needs to be the old chess game
โข Death predicateโข If game finished then pay money to the winnerโข Otherwise input records must be game record + one move
recordโข Move record must be signed by the right player โข Move record must contain a valid move
Making ZEXE privateโข ๐%!, ๐(! โ ๐(๐ถ/) (Universal predicate)โข ๐%" , ๐(" โ ๐(๐ถ0) (Birth predicate)โข ๐%# , ๐(# โ ๐(๐ถ1) (Death predicate)โข ๐%$% , ๐($% โ ๐(๐ถ"2) (TX circuit)โข ๐ถ"2 = ๐ ๐(!, . , . =0 and ๐ ๐(" , . , . =0 and ๐ ๐(# , . , . =0 And Record=๐ป(๐๐๐ฆ๐๐๐๐, ๐(" , ๐(# , ๐) // ๐ random
โข TX: Input records || Output records โข Compute nullifiers ๐๐!, โฆ , ๐๐" from input records โข To create a TX, create three ZK-SNARKS (now ZK is important)
โข x=TX,๐ค = ๐๐๐ฆ๐๐๐๐๐ , ๐#!, ๐#"โข ๐$ โ ๐ ๐%#, x ๐๐!, โฆ , ๐๐", ๐ค | | ๐๐ ๐๐๐๐๐๐ โข ๐& โ ๐ ๐%!, x, ๐คโข ๐' โ ๐ ๐%", x, ๐ค
โข Create ๐() โ ๐ ๐%$%, x, ๐ค||๐$, ๐&, ๐'
R1 R2 R3 โฆ 0 0 0
Merkleroot
tree ofheight 20
(220 leaves)
MT of all records
Birth and death predicate as well as records are private!
Hitchhikers guide to the galaxy
Input Output (42)
Long Computation
What if we want to verify that computation?
SNARKs for long computations
Input Output (42)P(Sp, ๐,๐) โพ ๐V(Sv, ๐, ๐) โพ acceptLong Computation, Transcript
C โ Circuit for long computationS(๐ถ) โพ (Sp, Sv) ๐ = ๐๐๐๐๐, ๐๐๐๐๐๐๐ = ๐๐๐๐๐๐๐๐๐๐
Issues:-P takes very long-Starts after proving aftercomputation finished-Canโt hand off computation-S also runs at least linear in |C| (ok if many proofs)
Handing off computation
Input Output (42), ๐S
๐ถTโ Circuit for long intermediate computation
S(๐ถT) โพ (Sp, Sv) ๐๐ = ๐๐๐๐๐, ๐๐๐๐ , ๐๐ = ๐๐๐๐๐๐๐๐๐๐๐๐๐ = ๐๐๐๐, ๐๐๐๐ , ๐๐ = ๐๐๐๐๐๐๐๐๐๐๐๐๐ = ๐๐๐๐, ๐๐๐๐๐๐ , ๐๐ = ๐๐๐๐๐๐๐๐๐๐๐P(Sp, ๐๐, ๐๐) โพ๐9
Int1,๐3 Int2,๐4transcript1 transcript2 transcript3
V(Sv, ๐๐, ๐ ๐)V(Sv, ๐๐, ๐ ๐)V(Sv, ๐๐, ๐ ๐)|๐|/ V linear in #handoffs
Incremental Proofs
โข We need updatable/incremental proofs
S(๐ถT) โพ (Sp, Sv)
๐ถTโ Circuit per computation step, ๐ก number of steps/handoffs
P(Sp, ๐๐, ๐๐, ๐9Y3) โพ updated proof ๐9 // ๐Z =โฅ
V(Sv, ๐๐, ๐๐, ๐:, t) โพ accept/reject
|๐9| = |๐9Y3| // proofs donโt grow
PhotoProof
Allow valid updates of photo and provide proof
Viewer can still verify authenticity
PhotoProof
Proof allows valid edits only, Incrementally updated
Constant size blockchains
โข Rollup reduces the verification costโข Still linear in the number of state updatesโข When a node joins the network they need to verify
one rollup proof per block!โข In general starting a full node requires verification of
all blocksโข Can take days!
Constant size Blockchain
๐$State-MT1
TX-MT1
Merkle tree
Transactions
๐%State-MT2
TX-MT2
๐&State-MT3
TX-MT3
๐'State-MT4
TX-MT4
๐9 prooves that transactions are valid with respect to the stateAND๐9Y3 was valid for the previous block
Constant size Blockchain
๐$State-MT1
TX-MT1
Merkle tree
Transactions
๐%State-MT2
TX-MT2
๐&State-MT3
TX-MT3
๐'State-MT4
TX-MT4
Old miner New minerHead and State 4
Verifies State-MT4 and ๐5
Constant size Blockchain
โข Light clients can verify every block! โข Low memory, low computation โข Independent of length of chain or #transactions
โข Relies on data serving nodes for synching
โข Practical today!
Next lecture: Crypto tricks and open discussionPlease attend last two lectures if you can
END OF LECTURE