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.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 5
Code
Source, repository, and what is actually hosted
- ePrint 2018/601https://eprint.iacr.org/2018/601
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
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.
Claim 02 · Paper model
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.
Claim 03 · Paper model
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.
Claim 04 · Paper model
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.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 Sequential on purpose
Observation
What the study says
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.
Model
What has to hold
The chosen function really is sequential. A newly found parallel algorithm collapses the delay.
Falsifier
What would retire it
What function is evaluated, and why is it sequential?
02 Unique, so it can be a lottery
Observation
What the study says
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.
Model
What has to hold
Outputs are unique. Otherwise the evaluator shops for a convenient one.
Falsifier
What would retire it
Is the output unique, and is the proof cheap to check?
03 The proof is what makes it useful
Observation
What the study says
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.
Model
What has to hold
The proof is sound and much faster to check than to compute.
Falsifier
What would retire it
Is the output unique, and is the proof cheap to check?
04 Hardware is the practical adversary
Observation
What the study says
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.
Model
What has to hold
The chosen function really is sequential. A newly found parallel algorithm collapses the delay.
Falsifier
What would retire it
Who has the fastest known evaluator?
03 Sequence
One action, as an operating tape
- 01A protocol publishes an input. Often that input includes a previous block, so it could not have been known earlier.
- 02Evaluators run the sequential function. Parallelism inside one step may help a little. It does not skip steps.
- 03The first evaluator publishes the output and a proof.
- 04Everyone else checks the proof cheaply and adopts the output.
- 05A leader election or a randomness beacon uses that output. The VDF itself did not choose a leader.
04 Load-bearing
The argument, and where a pitch drops it
Delay is a weapon against grinding
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
A VDF is not a consensus protocol, a proof of space, or a random beacon by itself.
A faster box is a silent advantage
The cut
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.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Hardware that evaluates faster than the designers assumed shortens the delay for whoever owns it.
05 Register
What has to be true
Network · Not re-measured
The chosen function really is sequential. A newly found parallel algorithm collapses the delay.
Model · Not re-measured
Outputs are unique. Otherwise the evaluator shops for a convenient one.
Cryptography · Not re-measured
The proof is sound and much faster to check than to compute.
Model · Not re-measured
The input is bound to the round. An input known in advance lets the fastest actor start early.
06 Divergence
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.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it 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
Why the desk still reads it
If randomness depends on a delay, ask who has the fastest evaluator, and what they can grind before everyone else finishes.
09 Lexicon
Terms, opened into the record
- 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.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
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.