Why Verifiable Delay Functions Make On-Chain Randomness Harder to Rig
You are a miner. You've just found the block. In the half-second before you broadcast it, you run the lottery contract's hash function against your block number and timestamp, and the output does not land in your favor. So you discard the block. You try again. Nobody sees this. Nobody can prove it happened. This is grinding, and it has been quietly eating on-chain randomness since the first smart contract lottery went live.
Verifiable Delay Functions are the most rigorous answer cryptographers have produced. Not the easiest. The most rigorous.
The Grinding Problem, Precisely Stated
Any randomness beacon that a block producer can observe before committing to it is a beacon they can manipulate. The threat model is simple: if the output is bad for you and you can cheaply recompute a new one, you will. The cost of grinding is electricity and a few milliseconds. The reward can be millions of dollars in a whale-sized NFT mint or a DeFi liquidation cascade.
The classic patch is a commit-reveal scheme. Participants submit a hash of their secret, then reveal the secret later, and the XOR of all secrets becomes the random seed. Ethereum's RANDAO mechanism works roughly this way. Genuinely better than raw block hashes. But it has a last-revealer problem: the final participant to reveal can see exactly what the beacon will produce if they reveal, and can choose to withhold their secret, accepting a small penalty, if the outcome harms them. With enough at stake, that penalty is noise.
A VDF doesn't add another commitment round. It changes the physics of the problem.
What a VDF Actually Does
A Verifiable Delay Function takes an input and produces an output that requires a fixed, sequential number of computational steps. Sequential is the operative word. You cannot parallelize it. Throw ten thousand GPUs at the computation and you finish in the same time as one, because each step depends on the last, as tightly chained as links in a physical lock.
The output also comes with a short proof that any node can verify in milliseconds, even though producing the output took, say, 30 seconds of wall-clock time on specialized hardware.
The canonical construction, proposed by Krzysztof Pietrzak and independently by Benjamin Wesolowski in papers published around 2018, relies on repeated squaring in a group of unknown order. Each squaring is one sequential step. No shortcut exists unless you can factor a number that was deliberately chosen to resist factoring.
Here is the worked scenario. A blockchain's randomness beacon committee finalizes a RANDAO output at slot N. That value is public immediately. A VDF evaluator, running dedicated hardware, begins the sequential computation. Thirty seconds later, the output is produced and the proof is posted on-chain. Any node verifies the proof in under a millisecond.
Can the last RANDAO revealer grind? They see the RANDAO seed before the VDF runs. But they cannot know the VDF output without completing the full 30-second computation themselves, and by the time they finish, the slot has closed. Withholding their reveal substitutes a different seed, which they would also need 30 seconds to evaluate. The attack becomes a race they are structurally incapable of winning.
The Honest Caveat on Deployment
VDFs are not a free lunch. Three things make them genuinely hard to deploy.
First, the delay parameter must be calibrated carefully. Too short, and a well-resourced adversary with faster-than-expected hardware finishes before the window closes. The Ethereum Foundation's VDF research explicitly flagged the risk of ASIC-accelerated evaluators breaking the delay assumptions, a concern that deserves ongoing attention, not footnote status. Real-world deployment requires continuous hardware benchmarking, and any protocol that sets the delay parameter once and walks away is making a bet on hardware stagnation that history does not support.
Second, the evaluator is a single point of operational failure in naive designs. If nobody runs the VDF computation, no randomness is produced. Robust designs need multiple independent evaluators with fallback logic, which adds protocol complexity.
Third, proof systems like Wesolowski's require a trusted setup or a group of unknown order, which introduces its own cryptographic assumptions. This is not a dealbreaker. Anyone who tells you VDFs are assumption-free is selling something.
Projects like the drand network, used by Filecoin and others, combine threshold BLS signatures with periodic VDF-style delay to distribute trust across multiple parties. It is not a pure VDF beacon, but it illustrates the same core intuition: make the output unavailable to any single actor until the manipulation window has passed.
Found a lottery contract that uses only `block.timestamp`? If you are auditing it, that is a critical finding. If you are playing it, you are trusting the miner more than the math, and the miner knows it.
The deeper point, and I think it is one that gets lost in debates over which beacon design is most elegant, is that randomness security in on-chain systems is not a cryptography problem that was solved once and filed away. It is an adversarial game where the stakes set the attack budget. VDFs raise the cost of manipulation from milliseconds of compute to a fixed wall-clock delay that no amount of capital can compress. That is not a complete solution. It is the right shape of one, which in adversarial protocol design is usually the best you can honestly claim.