Using SNARKs and VDFs for Secure Ethereum Randomness

Summary

The document assesses ways to provide randomness for Ethereum applications such as lotteries and games. It defines desirable properties as unpredictability, resistance to bias, verifiability, and liveness, with low cost as an additional practical goal. It explains why historical block hashes can be predicted, why future block commitments face proposer bias and limited retrieval windows, and how Chainlink VRF and Beacon Chain RANDAO each have trade-offs involving omission, cost, or timing.

The proposed direction combines future RANDAO values with historical block-header verification, SNARK proofs, and verifiable delay functions (VDFs). The goal is to make previously committed randomness retrievable and verifiable without relying on a single external operator. The text describes proof-of-concept contracts and circuits, but the available document is incomplete and provides no performance benchmarks or security proof. It explicitly characterizes these implementations as experimental, unoptimized, and unaudited; production readiness depends on further components, including VDF support and oracle infrastructure.

Key ideas

• Secure randomness should be unpredictable, difficult to bias, verifiable, and live.
• Historical block hashes are visible in advance, while future block commitments can still face proposer bias or retrieval limits.
• RANDAO reduces reliance on third parties but remains vulnerable to omission-based rerolls.
• The proposed design uses SNARKs to verify historical block data and VDFs to support secure randomness retrieval.
• The described implementations are experimental and unaudited, and the document gives no performance benchmarks.

Tags

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.