Pietrzak Verifiable Delay Functions
By: Joe Netti
Tags: Pow, Cryptography, Crypto, Vdf, Blockchain

Verifiable delay functions (VDF) create efficiently verifiable and unique proofs of work. Verifiable Delay Functions are first formally defined by Boneh et. al in the paper “Verifiable Delay Functions.” In this paper they formally define the characteristics of VDFs to have three properties. A VDF computation takes a certain amount of time to compute (“delay”) and there are no efficiency gains from parallelizing the computation. This amount of time is easily parameterizable based on the use case. VDFs must create proofs of work that are efficiently verifiable (“verifiable”). Lastly, each puzzle must have a single deterministic solution (“function”). [1, 2].

These three features are essential for distinguishing VDFs from prior cryptographic constructions. Bitcoin delay can be seen as a Verifiable Delay (except that can be parallelized). Proofs of Sequential Work (POSW) first introduced in 2013 is a Verifiable Delay that cannot be parallelized [3]. Hash functions are one example of a Verifiable Function (albeit one-way). Time lock puzzles proposed by Shamir in 1996 are Delay functions. Therefore, there is a rich history of constructions that have some features of verifiable functions but not all three features.

Randomness beacons are one of the most important use cases of VDFs. Alice and Bob can agree on a source and a difficulty for the VDF and agree to use the result of the VDF as randomness in the future. Imagine a lottery in a blockchain system. Participants put money into a pot and one of their stake-weighted identities is chosen at a specified date. Traditionally the way to do this is to choose the block hash as a source of randomness at a specified height. However, these allow for grinding and block withholding attacks where blocks can be chosen or withheld if they have a hash that would result in a desired outcome for the block-producer in a game that relies on its randomness. This is impossible to do with a VDF if a recent block is chosen as the starting data.

Before diving into the Pietrzak construction [4], we give here a brief outline of the rest of the paper. First, we describe the timelock puzzle [5] because it is foundational to the Pietrzak construction. Next, we split the Pietrzak construction into two parts: interactive and non-interactive. The construction is easier to understand because it doesn’t require “compressing” the proof and it doesn’t require understanding Fiat-Shamir transforming for turning non-interactive proofs into interactive proofs. Lastly we briefly mention other constructions.

Timelock puzzles

Timelock puzzles were proposed in 1996 and their purpose is to “encrypt messages to the future” [5]. Alice can encrypt a message M and broadcast it publically along with some public parameters. Anyone can perform a series of sequential computations on the public parameters to retrieve the decryption key. The primitives for this construction are Blum-Blum-Shub generator and RSA factoring (large composite n=pq).

Alice wants to create a timelock puzzle to encrypt a message M. She chooses the amount of time to encrypt the message, two random primes p and q, and a random key K. Alice also needs an accurate expectation for the number of squares-per-second of a decrypter — she should probably overestimate this to be safe. She encrypts the message using K and then encrypts the K using the following method:

Here is where the magic happens. Bob must do t square operations to get the second term while Alice only has to raise x^e. e is much smaller than 2^T. He simply subtracts the second term from Ck and finds the key K. With the key he can decrypt the message! Note that Alice selects T =time*squares_per_second and x is random.

Pietzak Construction

Timelock puzzles require all decrypters to run the entire computation because there is no proof of computation. Note also that Timelock puzzles are deterministic because they are squared in a field and the output is unpredictable based on the Blum-Blum-Shub randomness generator. These properties cover the “delay”, “function”, and “unpredictable” aspects of VDFs. The Pietrzak construction extends timelock puzzles and adds the last missing component: “verifiability” [5].

Consider two parties P (prover) and V (verifier). The prover is running the computation and proving it interactively to the verifier. Note that this construction requires a trusted setup where p,q are not known otherwise the prover does not have to do the full computation because the group size is known (like how encrypter in time-lock puzzles mod by ϕ(n)).

First the prover calculates y = x^(2T)by doing T sequential squares. The Verifier saves some information for making the proof calculation more efficient, this is discussed in a later section. This protocol works if the initial x is generated randomly.

After y is calculated, then the prover and verifier interact as follows [4]:

pg. 8

This algorithm repeats with new x, y, and T values until T=1. There are a few key points that will help you understand this protocol. First, notice how we are proving the squares between “halvings” of T. For example, in the first iteration, we prove the result at T/2 squares, which is the first half of the computation. Afterwards, we prove at ¾ of the computation, then ⅞ and so on. We keep halving until there is only one square left. When there is one square left, the algorithm is actually at T=1 and the verifier computes that last square. Therefore we will have log2(T) rounds in the algorithm.

Next, notice that x` updates each round. Since x` != x (except for the first round), the prover cannot simply set μ to the values that the Prover saved while computing y. The prover has to use many saved values and do additional computations. Computing μi = {μ1 , … μs} requires 2^s values and requires 2^s exponentiations. Here is an example of how to calculate μ3:

pg. 18

Notice, x` and y` share the same relationship that x and y except T` =T/2:

Essentially the halving protocol is growing x` faster than y` until

Non-interactive Protocol

Any interactive public-coin protocol can be turned into a non-interactive trusted setup protocol using the Fiat Shamir Heuristic. To make the Pietrzak VDF non-interactive, simply each random number as follows:

pg. 16

References

[1] Boneh, D., Bonneau, J., Bünz, B., & Fisch, B. (2018, August). Verifiable delay functions. In Annual international cryptology conference (pp. 757–788). Springer, Cham. https://eprint.iacr.org/2018/601.pdf.

[2] Bonneau. (2019, November). Exploring VDFs with Joseph Bonneau. Zero Knowledge Podcast https://www.zeroknowledge.fm/103.

[3] Mahmoody, M., Moran, T., & Vadhan, S. (2013, January). Publicly verifiable proofs of sequential work. In Proceedings of the 4th conference on Innovations in Theoretical Computer Science (pp. 373–388). https://eprint.iacr.org/2011/553.pdf.

[4] Pietrzak, K. (2018). Simple verifiable delay functions. In 10th innovations in theoretical computer science conference (itcs 2019). Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik. https://eprint.iacr.org/2018/627.pdf.

[5] Rivest, R. L., Shamir, A., & Wagner, D. A. (1996). Time-lock puzzles and timed-release crypto. https://people.csail.mit.edu/rivest/pubs/RSW96.pdf.