Skip to content
Blockchain LabTHE VENTURE STUDIO

LibraryConsensus2018Design paperCorpus record

Verifiable Delay Functions

Verifiable delay functions. Dan Boneh, Joseph Bonneau, Benedikt Bünz and Ben Fisch.

A function that forces a wait. Evaluating it takes a set number of sequential steps. Checking the result is quick, and the output is unique. Parallel machines do not make the wait much shorter.

A verifiable delay function takes a fixed amount of sequential time to compute, produces a unique output, and can be checked quickly. Extra processors do not divide the wait the way they divide a hash puzzle.

The five-minute read

Sequential on purpose

Proof of work is parallel. That is why more machines win. A VDF is built so the next step needs the previous step. The wait is wall-clock time for whoever does not have a faster algorithm.

Unique, so it can be a lottery

Two honest evaluators must get the same output. A function with many valid outputs can be ground. Uniqueness is what lets a protocol treat the result as a random beacon or a clock.

The proof is what makes it useful

Without a short proof, everyone would re-run the delay to check it, which defeats the point. The verifier should be much faster than the evaluator.

Hardware is the practical adversary

A tighter implementation or an ASIC that squares faster shrinks the delay for its owner. The assumption is not only algebraic. It is about who has the fastest box.

One action, walked through

  1. A protocol publishes an input. Often that input includes a previous block, so it could not have been known earlier.
  2. Evaluators run the sequential function. Parallelism inside one step may help a little. It does not skip steps.
  3. The first evaluator publishes the output and a proof.
  4. Everyone else checks the proof cheaply and adopts the output.
  5. A leader election or a randomness beacon uses that output. The VDF itself did not choose a leader.

The argument, unpacked

Delay is a weapon against grinding

If tickets for a lottery can be tested instantly, a proposer tests a million of them. If each test takes a real wait, they cannot. The VDF is that wait. Remove it and the space proof or the stake lottery becomes a hash puzzle again.

A faster box is a silent advantage

The paper cannot promise that commodity hardware and specialised hardware take the same time. A deployment has to say what happens if one actor evaluates twice as fast. That gap is time they can use to grind or to withhold.

What has to be true

  • The chosen function really is sequential. A newly found parallel algorithm collapses the delay.
  • Outputs are unique. Otherwise the evaluator shops for a convenient one.
  • The proof is sound and much faster to check than to compute.
  • The input is bound to the round. An input known in advance lets the fastest actor start early.

What happened after the paper

Chia uses a delay alongside proofs of space. Ethereum research discussed VDFs for randomness. Deployments differ in the function, the proof, and the hardware assumptions. The 2018 paper is the definition: sequential, unique, quickly verifiable. It is not a beacon you can cite as already secure in a product.

What to check before you use the idea

  • What function is evaluated, and why is it sequential?
  • Who has the fastest known evaluator?
  • Is the input bound to this round, or knowable in advance?
  • Is the output unique, and is the proof cheap to check?

Terms

Sequential work
Work that cannot be sped up in proportion to the number of parallel machines.
Uniqueness
The property that the function has one accepted output, so the evaluator cannot shop.

The problem the paper names

Lotteries and leader election leak a bias if a proposer can try many tickets quickly. A delay function makes each try cost wall-clock time, so grinding through candidates stops being free.

What the design proposes

  • Sequential work, so extra CPUs do not divide the wait by the same factor.
  • A short proof that the output is the one the function defines.
  • Uniqueness, so two honest evaluators do not disagree.

How the mechanism is specified

  • The security claim is about sequentiality, often from a group where squaring is believed not to parallelise.
  • A faster algorithm, or special hardware, shrinks the delay. The assumption is empirical as much as algebraic.
  • The function does not choose a leader. A protocol uses the output as randomness or as a clock.

What this page does not treat as proven

  • A VDF is not a consensus protocol, a proof of space, or a random beacon by itself.
  • Hardware that evaluates faster than the designers assumed shortens the delay for whoever owns it.
  • Ethereum's and Chia's later uses are deployments. Cite the paper for the definition.

Why a venture studio still reads it

If randomness depends on a delay, ask who has the fastest evaluator, and what they can grind before everyone else finishes.

This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.

Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.