Verifiable Delay Functions: How to Slow Things Down (Verifiably) - PowerPoint PPT Presentation

NutMiC’19, June, 2019 Verifiable Delay Functions: How to Slow Things Down (Verifiably) Dan Boneh Stanford University

What is a VDF? (verifiable delay function) Intuition: a function X ⟶ Y that (1) takes time T to evaluate, even with polynomial parallelism, (2) the output can be verified efficiently • Setup( λ , T ) ⟶ public parameters pp • Eval( pp , x ) ⟶ output y , proof π (parallel time T ) • Verify( pp , x , y , π ) ⟶ { yes, no } (time poly( λ, log T ) )

Security Properties (simplified) [B-Bonneau-B ü nz-Fisch’18] • Setup( λ , T ) ⟶ public parameters pp • Eval( pp , x ) ⟶ output y , proof π (parallel time T ) • Verify( pp , x , y , π ) ⟶ { yes, no } (time poly( λ, log T ) ) if Verify( pp , x , y , π ) = Verify( pp , x , y’ , π’ ) = yes “ Uniqueness ”: then y = y’ “ε- Sequentiality ”: for all parallel algs. A , time( A ) < (1-ε) ⋅ time(Eval), for random x ∈ X, A cannot distinguish Eval( pp , x ) from a random y ∈ Y

Application: lotteries Problem : generating verifiable randomness in the real world? Standard solutions are unsatisfactory

Broken method: distributed generation Alice Bob Claire Zoe r a r b r c r z ∈ {0,1} 256 Public Bulletin Board (blockchain) output rand = r a ⊕ r b ⊕ ⋯ ⊕ r z ∈ {0,1} 256 Problem: Zoe controls value of rand !!

Solution: slow things down with a VDF [LW’15] Alice Bob Claire Zoe r a r b r c r z Public Bulletin Board (blockchain) hash(r a , r b , ⋯ , r z ) ∈ {0,1} 256 VDF output ( rand , π)

Solution: slow things down with a VDF • Submissions: start at 12:00pm, end at 12:10pm • VDF delay: about one hour ( ≫ 10 minutes) Sequentiality : ensures Zoe cannot bias output Uniqueness : ensures no ambiguity about output Public Bulletin Board (blockchain) VDF ( rand , π) hash(r a , r b , ⋯ , r z ) ∈ {0,1} 256

Being implemented and deployed …

Construction 1: from hash functions Hash function H: {0,1} 256 ⟶ {0,1} 256 (e.g. SHA256) • pp = (public parameters for a SNARK) H (T) (x) = H(H(H(H(H( … (H(H(x))) … ))))) T times (sequential work) • Eval(pp, x): output y = H (T) (x) , proof π = (SNARK) • Verify(pp, x, y , π ): accept if SNARK proof is valid

Construction 1: from hash functions Problem : computing SNARK proof π takes longer than computing y = H (T) ( x ) ⇒ adversary can compute y long before Eval( pp , x ) finishes Simple solution using log 2 (T)-way parallelism [B-Bonneau-Bünz-Fisch’18]

<latexit sha1_base64="a6pE2PQd1/gMxQhgh6Hjwt+k/8=">ACBnicbVC7SgNBFL0bXzG+Vi1FGBKEBCHsptFGCFqYMkJekI1hdjLRIbOz68ysGJZUNn6GrY2FIrZ+g51/4+RqPHAhcM593LvPX7EmdKO82WlFhaXlfSq5m19Y3NLXt7p6HCWBJaJyEPZcvHinImaF0zWkrkhQHPqdNf3A29pu3VCoWipoeRrQT4CvB+oxgbaSuvT9EJ6iSvytcJvnSZa0wQsi7iXEPeUyg86dc4rOBGieuDOSK2e9w0cAqHbtT68XkjigQhOlWq7TqQ7CZaEU5HGS9WNMJkgK9o21CBA6o6yeSNETowSg/1Q2lKaDRf04kOFBqGPimM8D6Wv31xuJ/XjvW/eNOwkQUayrIdFE/5kiHaJwJ6jFJieZDQzCRzNyKyDWmGiTXMaE4P59eZ40SkXKboXJo1TmCINe5CFPLhwBGWoQBXqQOAenuAFXq0H69l6s96nrSlrNrMLv2B9fAM6DZfl</latexit> <latexit sha1_base64="07BIbQP7jDhUcHVWGZykj4T6EG4=">ACBnicbVDLSsNAFJ34rPUVdSnC0CK0CXpRjdC0YVdVugLmrRMptN26GQSZyZiCF258QP8CTcuFHrN7jr3zh9LT1wIXDOfdy7z1eyKhUljU2VlbX1jc2U1vp7Z3dvX3z4LAug0hgUsMBC0TQ5IwyklNUcVIMxQE+R4jDW94PfEb90RIGvCqikPi+qjPaY9ipLTUMU9ieAnLuYd8O8kV29X8CELnLkJd6FAObzpm1ipYU8BlYs9JtpRxzp7HpbjSMb+dboAjn3CFGZKyZVuhchMkFMWMjNJOJEmI8BD1SUtTjnwi3WT6xgieaqULe4HQxRWcqr8nEuRLGfue7vSRGshFbyL+57Ui1btwE8rDSBGOZ4t6EYMqgJNMYJcKghWLNUFYUH0rxAMkEFY6ubQOwV58eZnUiwXbKti3Oo0rMEMKHIMyAEbnIMSKIMKqAEMHsELeAPvxpPxanwYn7PWFWM+cwT+wPj6AUN3mWs=</latexit> <latexit sha1_base64="07BIbQP7jDhUcHVWGZykj4T6EG4=">ACBnicbVDLSsNAFJ34rPUVdSnC0CK0CXpRjdC0YVdVugLmrRMptN26GQSZyZiCF258QP8CTcuFHrN7jr3zh9LT1wIXDOfdy7z1eyKhUljU2VlbX1jc2U1vp7Z3dvX3z4LAug0hgUsMBC0TQ5IwyklNUcVIMxQE+R4jDW94PfEb90RIGvCqikPi+qjPaY9ipLTUMU9ieAnLuYd8O8kV29X8CELnLkJd6FAObzpm1ipYU8BlYs9JtpRxzp7HpbjSMb+dboAjn3CFGZKyZVuhchMkFMWMjNJOJEmI8BD1SUtTjnwi3WT6xgieaqULe4HQxRWcqr8nEuRLGfue7vSRGshFbyL+57Ui1btwE8rDSBGOZ4t6EYMqgJNMYJcKghWLNUFYUH0rxAMkEFY6ubQOwV58eZnUiwXbKti3Oo0rMEMKHIMyAEbnIMSKIMKqAEMHsELeAPvxpPxanwYn7PWFWM+cwT+wPj6AUN3mWs=</latexit> <latexit sha1_base64="mYjLOkFntbLtDLpEzmMgZpXDosk=">ACBnicbVDLSsNAFJ34rPUVdSnCYBHaTUm60Y1QdGXFfqCNi2TyaQdOpnEmYkYQldu/BU3LhRx6ze482+ctlo64ELh3Pu5d573IhRqSzr21hZXVvf2Mxt5bd3dvf2zYPDlgxjgUkThywUHRdJwignTUVI51IEBS4jLTd8fXUb98TIWnIGyqJiBOgIac+xUhpaWCeJPAS1oPpX5arPQbpQmEvbsYebBHObwZmAWrbM0Al4mdkQLIUB+YXz0vxHFAuMIMSdm1rUg5KRKYkYm+V4sSYTwGA1JV1OAiKdPbGBJ5pxYN+KHRxBWfq74kUBVImgas7A6RGctGbiv953Vj5F05KeRQrwvF8kR8zqEI4zQR6VBCsWKIJwoLqWyEeIYGw0snldQj24svLpFUp21bZvrUK1asjhw4BqegCGxwDqgBuqgCTB4BM/gFbwZT8aL8W58zFtXjGzmCPyB8fkDJ46WXA=</latexit> Construction 2: exponentiation Why? G : finite abelian group • Assumption 1 : the order of G cannot be efficiently computed T squarings, e.g. T = 10 9 pp = ( G, H: X ⟶ G ) y = H ( x ) (2 T ) ∈ G • Eval(pp, x): output need proof π = (proof of correct exponentiation) [Pietrzak’18, W esolowski ’18]

Proof of correct exponentiation (T=power of 2) Method 1 : [Pietrzak’18] 𝑕, ℎ ∈ 𝐻 , claim: ℎ = 𝑕 (. / ) implies Prover Verifier 𝑣 = 𝑕 (. //3 ) need to check: 𝑕 (. //3 ) = 𝑣 𝑣 (. //3 ) = ℎ 𝑠 ∈ {1, … , 2 9.: } random verify both at once! (. //3 ) 𝑕 9 = 𝑕 < 𝑣 , ℎ 9 = 𝑣 < ℎ . Recursively prove ℎ 9 = 𝑕 9 Set

Proof of correct exponentiation [P’18] Prover ( 𝑕, ℎ ) Verifier ( 𝑕, ℎ ) 𝑣 = 𝑕 (. //3 ) 𝑕 9 = 𝑕 < 𝑣 , ℎ 9 = 𝑣 < ℎ 𝑠 (. //3 ) claim: ℎ 9 = 𝑕 9 (. //= ) 𝑣 9 = 𝑕 9 𝑕 . = 𝑕 < > 𝑣 , ℎ . = 𝑣 < > ℎ 𝑠 9 ⋮ (log 𝑈 rounds) compute: ℎ ?@A B , 𝑕 ?@A B . claim: ℎ ?@A B = 𝑕 ?@A B . accept if ℎ ?@A B = 𝑕 ?@A B Proof π = (𝑣, 𝑣 9 , … , 𝑣 ?@A B )

Proof of correct exponentiation [P’18] As a non-interactive proof: • Proof π = 𝑣, 𝑣 9 , … , 𝑣 ?@A B via the Fiat-Shamir heuristic 𝑠 H = hash( 𝑕, ℎ, 𝑣, 𝑠, … , 𝑣 HI9 , 𝑠 HI9 , 𝑣 H ), 𝑗 = 1, … , log 𝑈 Computing the proof π: fast, only O( 𝑈) steps • By storing 𝑈 values while computing 𝑕 (. / )

Soundness Theorem [BBF’18] (informal) : suppose ℎ ≠ 𝑕 (. / ) , but prover P convinces verifier (with non-negligible probability 𝜗 ) . Then there is an algorithm, whose run time is twice that of P , that outputs (with prob. 𝜗 2 ) (𝒙, 𝒆) where 𝟐 ≠ 𝒙 ∈ 𝑯 and d < 2 128 such that 𝒙 𝒆 = 𝟐 assumption 2 so: hard to find 1 ≠ 𝑥 ∈ 𝐻 of known order ⇒ protocol is secure

Assumption 2 is necessary for security Suppose some (𝑥, 𝑒) is known where 1 ≠ 𝑥 ∈ 𝐻 and 𝑥 T = 1 . ⇒ Prover can cheat with probability 1/𝑒 How? set ℎ = 𝒙 ⋅ 𝑕 (. / ) ≠ 𝑕 (. / ) , 𝑣 = 𝒙 ⋅ 𝑕 (. //3 ) Now, verifier falsely accepts whenever 𝑠 + 1 ≡ 2 B/. (𝑛𝑝𝑒 𝑒) (. //3 ) why? in this case: ℎ 9 = 𝑕 9 holds with prob. 1/d = = (𝑕 < ℎ) (. //3 ) 𝑣 < ℎ

More generally … nothing special about squaring 𝐻 : finite abelian group. 𝜚: 𝐻 → 𝐻 an endomorphism 𝒉, 𝒊 ∈ 𝑯 , claim: 𝒊 = 𝝔 𝐔 (𝐡) Prover ( 𝑕, ℎ ) Verifier ( 𝑕, ℎ ) 𝑣 = 𝜚 a/. (g) 𝑕 9 = 𝑕 < 𝑣 , ℎ 9 = 𝑣 < ℎ 𝑠 claim: ℎ 9 = 𝜚 B/. (g 9 ) ⋮ Proof π = (𝑣, 𝑣 9 , … , 𝑣 ?@A B )

Proof of correct exponentiation: method 2 Method 2 : [Wesolowski’18] 𝑕, ℎ ∈ 𝐻 , claim: ℎ = 𝑕 (. / ) Prover Verifier ℓ ← 𝑄𝑠𝑗𝑛𝑓𝑡(2 9.: ) let q = ⌊ 2 B /ℓ ⌋ compute 𝑠 = 2 B 𝑛𝑝𝑒 ℓ 𝑣 = 𝑕 g accept if: 𝑣 ℓ ⋅ 𝑕 < = ℎ single element! Proof π = (𝑣)

Soundness Need assumption 2: hard to find 1 ≠ 𝑥 ∈ 𝐻 of known order … but is not sufficient Security relies on a stronger assumption called the adaptive root assumption .

Candidate abelian groups Goal : group G with no elements ≠1 of known order • n ∈ ℤ , unknown factorization. 𝐻 l = ℤ/𝑜 ∗ /{±1} Con: trusted setup to generate n (or a large random n) • 𝑞 ≡ 3 (𝑛𝑝𝑒 4) prime. 𝐻 s = class group of ℚ −𝑞 . Con: no setup, but complex operation (slow verify) Pro: can switch group every few minutes ⇒ smaller params

Candidate abelian groups Goal : group G with no elements ≠1 of known order Note DJB parallelism for exponentiation in 𝐻 l • n ∈ ℤ , unknown factorization. 𝐻 l = ℤ/𝑜 ∗ /{±1} Con: trusted setup to generate n (or a large random n) • 𝑞 ≡ 3 (𝑛𝑝𝑒 4) prime. 𝐻 s = class group of ℚ −𝑞 . Con: no setup, but complex operation (slow verify) Pro: can switch group every few minutes ⇒ smaller params

Assumption 2 in class groups? hard to find 1 ≠ 𝑥 ∈ 𝐻 s of known small order Cohen-Lenstra : frequency d divides |𝐻 s | : d=3: 44%, d = 5: 24%, d = 7: 16% Open : When 3 divides |𝐻 s | , can we efficiently find an element of order 3 in 𝐻 s ?

The Chia class group challenge Recent class number record: 512-bit discriminant • Beullens, Kleinjung, Vercauteren 2019: The Chia challenge : computing larger class numbers • Are there interesting discriminants to include in challenge? https://github.com/Chia-Network/vdf-competition