Cornell Format

Date:

Reviewed:

Topic / Chapter:

summary

❓Questions

Notes

Topic 1

Date:

Reviewed:

Topic / Chapter:

❓Questions

Notes

  • Introduction to Modern SNARKs
    • SNARKs
      • SNARK: a succinct proof that a certain statement is true
        • i.e. β€œshort” and β€œfast” to verify
        • e.g. solution itself: might not be short nor fast to verify
      • zk-SNARK: revealing nothing about
      • potentially: a single reliable PC can monitor supercomputers’ operation
        • or: slow computer monitoring GPUs
        • slow computer: like layer-1s
    • Blockchain applications 1
      • outsourcing computation (not zk)
        • L1: quickly verifies work of off-chain service
      • e.g. scalability: proof-based rollups (zkRollup)
        • off-chain service processes a batch of Tx
        • L1 chain: verifies a succinct proof of correct processing
      • e.g. bridging blockchains: Po-Consensus (zkBridge)
        • enables transfer of assets from one chain to another
        • proving to target chain that asset was locked in source chain
    • Blockchain applications 2
      • (requiring zk)
      • private Tx on a public blockchain
        • zk proof that a private Tx is valid
      • compliance
        • proof that a private Tx is compliant w/ banking laws
        • proof that an exchange is solvent in zk
      • also: non-blockchain applications exist
        • e.g. fighting disinformation: C2PA
        • camera: w/ embedded secret key
          • and signs picture w/ location & timestamp
          • metadata: can be confirmed
        • problem: image post-processing
          • disable further C2PA verification
        • zk-SNARK solution
          • laptop: w/ (Photo, Ops)
          • : proves that β€œI know a pair (Orig, Sig) s.t.”
            • Sig a valid C2PA signature on Orig
            • Photo is result of applying Ops to Orig
            • metadata(Photo)==metadata(Orig)
          • laptop verifies and shows metadata
          • size: ≀ 1 KB, takes ≀ 10 ms in browser
            • proof generation: takes a few minutes w/ sufficient HW
              • parallelizable
          • proof: must be not interactable
  • What is SNARK
    • Arithmetic circuits
      • computation model: must be fixed to build SNARK
      • let for
        • finite field
        • closed w/ addition & multiplication
      • arithmetic circuits
        • (n input w/ 1 output)
        • directed acyclic graph, where
          • internal nodes:
          • inputs:
        • defines: n-variate polynomial w/ evaluation recipe
        • : no. of gates in
      • interesting cases
        • :
          • gates (”small”)
        • : output 0 if a valid ECDSA sig of
      • structured vs. unstructured circuits
        • unstructured: w/ arbitrary wires

        • structured: build in layers, one circuit being repeated

          01_structured_circuits

          • layer: aka VM
    • NARK: Non-interactive ARgument of Knowledge
      • applied arithmetic circuit
          • : oublic statement in
          • : secret witness in
        • preprocessing: public params ()
          • public param for prover / verifier
      • prover:
        • generate proof that
      • verifier:
      • preprocessing NARK: triple
        • : description of circuit
        • : accept / reject
        • all alg. and adversary: w/ access to random oracle
      • informal requirements
        • complete: β‡’
          • i.e. always accept if valid
        • or: β€œknowledge sound”
          • if accepts β‡’ β€œknows” s.t.
          • and extractor can extract a valid
        • optional: ZK: reveals β€œnothing new” about
      • trivial NARK:
    • SNARK
      • succinct preprocessing NARK
      • same for
      • : short
        • len($\pi$) = sublinear($|w|$)
      • : fast to verify
        • time(V)= $O_{\lambda}(|x|$, sublinear($|C|$))
      • i.e. anything better than NARK: technically SNARK
      • however, strongly succinct NARK is:
        • len($\pi$) = $O_{\lambda}(\log |C|)$
        • time(V)= $O_{\lambda}(|x|,\log(|C|))$
          • i.e. no time to even read circuit
          • thus: preprocessing needed
            • : summary of
      • most SNARKs to be discussed: in constant time
      • trivial SNARK: not SNARK
        • long proof
        • might be hard (and slow)
        • : might be secret
    • Preprocessing (setup)
      • setup types

        • trusted setup per circuit
          • run fresh for each circuit
          • and must be kept secret
            • if is learned: false statements can be proven
            • generator: destroyed after task
        • trusted but universal (updatable) setup
          • secret : independent of
          • (global param)
            • one-time setup, secret
            • deterministic
            • can be repeated
        • transparent setup
          • : doesn’t use secret data
      • significant progress

        size of verifier timesetuppost-quantum
        Groth’16 200 Bytes 1.5 mstrusted per circuitno
        Plonk / Marlin 400 Bytes 3 msuniversal trusted setupno
        Bulletproofs 1.5 KB 3 sectransparentno
        STARK 100 KB 10 mstransparentyes
        • prover time: almost
    • Knowledge
      • if accepts β‡’ knows s.t.
      • if knows : we can β€œtorture” to get
      • formal knowledge
        • is knowledge sound for if
        • eff. adversary s.t.
        • ,
          • i.e. non-negl
        • then eff. extractor s.t.
      • i.e. if there is an efficient prover, then we can extract the knowledge
  • Building an eff. SNARK
    • Building SNARK
      • general paradigm: two steps
        • a functional commitment scheme
          • cryptographic obj
        • a compatible interactive oracle proof (IOP)
          • info. theoretic obj
        • result: SNARK for general circuits
      • commitments scheme
        • made of commit & verify
        • must satisfy: binding & hiding property
      • standard commitment
        • : com:=H(m,r)
        • : accepts if com=H(m,r)
    • Functional commitment scheme
      • given a family of functions
        • sent to verifier
      • verifier: sends
      • prover: sends and
        • proving that and
      • a functional commitment scheme for
        • : outputs public param
          • binding & optional hiding (for zk-SNARK)
          • accept / reject
          • a SNARK for relation
            • , , and
      • four important functional commitments
        • polynomial commitments
          • commit to a univariate in
        • multilinear commitments
          • commit to multilinear in
          • e.g.
        • vector commitments (e.g. Merkle tree)
          • commit to
          • open cells:
            • prove that th index is
        • inner product commitments
          • aka inner product arguments (IPA)
          • commit to
          • open an inner product
    • Polynomial commitments
      • commit to a univariate in
      • eval: for public , prover can convince
        • and
        • for verifier w/
      • eval proof size & verifier time:
      • few examples
        • w/ bilinear groups: KZG’10 (trusted setup), Dory’20
        • w/ hash functions only: based on FRI (long eval proofs)
        • w/ elliptic curves: Bulletproofs (short proof, but verifier time being )
        • w/ groups of unknown order: Dark’20 (slow)
        • KZG’10: most widely used
      • trivial commitment scheme: not a polynomial commitment
        • let
          • output
        • eval: prover sends to verifier
          • verifier accepts if and
          • proof size & verification time: linear in
    • Useful observation
      • for a non-zero
        • for :
          • aka SZDL lemma
          • also holds for multivariate polynomials
            • : total degree of
        • has at most roots in finite field
          • and possibilities for
      • thus, suppose and
        • then is negligible
      • and if , for high probability
      • suppose and
        • let
        • for : if
          • β‡’ w.h.p.
        • as
          • β‡’ w.h.p.
      • β‡’ simple equality test for two committed polynomials
    • Equality test protocol
      • interactive protocol
        • prover:
        • verifier: gives
        • prover: computes ,
          • and attaches proof for
          • along w/
        • verifier: accepts if
          • valid proof
      • can be made non-interactive (Fiat-Shamir)
        • for all public-coin IP
        • prover: generates by its own w/
          • ,
          • sends
          • compute itself as well
        • not a zk-SNARK as , is revealed
    • F-IOP
      • goal: boost functional commitment
        • β‡’ SNARK for general circuits
      • let be arith. circuit and
      • F-IOP: proof system that proves as follows
          • oracles for functions in
            • can be replaced into commitments
        • proof
          • prover: sends
            • verifier: sends
          • prover: sends
            • verifier: sends
          • … repeated t times
            • and verifier: runs
      • properties
        • complete: then
        • knowledge sound: unable to fake knowledge
    • Example poly-IOP
      • ↔
      • prover
          • as , is a polynomial
        • sends:
      • verifier
        • (public)
        1. query
        2. query
        3. compute
        4. accept if
      • V accepts β‡’ w.h.p. β‡’
        • kind of reversed logic
      • Extractor:
        • output by computing all roots of
    • IOP Zoo
      • β‡’ SNARKs for general circuits
      • Poly-IOP (w/ Poly-Commit)
        • Sonic
        • Marlin
        • Plonk
      • Multilinear-IOP (w/ Multilinear-Commit)
        • Spartan
        • Clover
        • Hyperplonk
      • Vector-IOP (w/ Merkle)
        • STARK
        • Breakdown
        • Orion
      • β‡’ SNARK (non-interactive via Fiat-Shamir)
    • SNARKs in practice
      • programs: written in Domain-Specific Language
        • Circom, ZoKrates, Leo, Cairo, Noir..
      • compiles to SNARK friendly format
        • circuit, R1CS, …, EVM byte code
      • β†’ SNARK backend prover (heavy computation)
        • outputs