Skip to main content

Real-Time Randomness: Security Model

This document explains the security model behind rng.dev's 1-second beacon and optional entropy sources for self-hosted deployments.

Summary​

DeploymentCadenceSecurity ModelDependencies
rng.dev (hosted)1 secondEconomic + Information-theoreticNone
Self-hosted1 secondEconomic + Information-theoreticNone
Self-hosted + drand~1.5s avg+ BLS threshold signaturesdrand network
Self-hosted + hardware1 second+ Hardware entropyOperator trust

Key insight: The 1-second beacon achieves security through economic infeasibility ($80B+ to compromise) and information-theoretic unpredictability (TXIDs depend on global user behavior). Self-hosted operators can optionally add drand or hardware entropy for specific requirements.

The 1-Second Beacon​

rng.dev generates new randomness every second using 8 fast-finality blockchains:

ChainFinalityFresh Each Round?
Aptos~900ms✓ Yes
Arbitrum~250ms✓ Yes
Base~2s✓ Yes
Solana~400ms✓ Yes
Sui~400ms✓ Yes
Bitcoin~60 minEvery ~60 rounds
Cardano~20sEvery ~20 rounds
Ethereum~13 minEvery ~12 rounds

Why This Is Secure​

TXID unpredictability provides the core security guarantee.

Even if slow chain data (Bitcoin, Ethereum, Cardano) repeats across rounds, the output is unique and unpredictable because:

  1. Fast chain TXIDs change every round — Aptos, Arbitrum, Base, Solana, and Sui each produce new transactions
  2. TXIDs depend on global user behavior — Who submits transactions, when, and with what parameters
  3. This is information-theoretically secure — Predicting TXIDs requires predicting the behavior of millions of users

An attacker who knows "Bitcoin block X will be used for the next 600 rounds" still cannot predict the output — they don't know which transactions will land in the next Sui/Aptos/Solana blocks.

The Front-Running Problem​

Consider a naive "real-time" scheme:

User sends request at T0
Server computes: output = SHA3(public_inputs | T0)
Server returns output

The attack:

  1. Attacker knows all public inputs (blockchain hashes are public)
  2. Attacker estimates arrival time: T0 ≈ now + network_latency (±2ms uncertainty)
  3. Attacker pre-computes all possible outputs (~4 million hashes in ~4ms on a GPU)
  4. Attacker knows all possible outcomes before the server responds

Why VDFs don't help: VDFs delay the response, not the attacker's pre-computation.

Why timestamps don't help: Even nanosecond precision only adds ~4 million possibilities, which GPUs handle in milliseconds.

The Solution: Future Randomness​

The only secure approach is using randomness that doesn't exist when the user commits.

How the 1-Second Beacon Works​

T0: Current blocks finalized (Aptos, Solana, Sui at ~400-900ms)
T0 + 1s: NEW blocks finalized with NEW transactions
T0 + 1s: Beacon computes output using NEW TXIDs

The TXIDs used in the output didn't exist when the previous round was published. Predicting them requires predicting which users will submit transactions in the next second — information-theoretically impossible.

Self-Hosted: Optional Entropy Sources​

drand Integration (~1.5s average latency)​

For operators with specific regulatory requirements for threshold BLS signatures:

optional_sources:
  drand:
    enabled: true
    network: "quicknet"
    wait_for_next: true

How it works:

T0: User sends request
T1: Request arrives at server
T1 + (0 to 3s): Next drand round is published
T1 + delay: Server computes output using blockchain data + NEW drand value

Properties:

  • Adds ~1.5 seconds average latency (0-3s range)
  • Provides BLS threshold signatures from 20+ operators
  • Useful for regulations specifically requiring threshold cryptography

Note: Most use cases don't require threshold BLS signatures. The 1-second beacon provides fully verifiable randomness without external dependencies.

Hardware Entropy​

For air-gapped or high-security deployments:

optional_sources:
  hardware:
    enabled: true
    device: "/dev/hwrng"

Properties:

  • Truly random (quantum/thermal noise)
  • Not publicly verifiable (must trust operator)
  • Defense-in-depth entropy layer

Why Not Online QRNGs?​

Online QRNG services (like ANU QRNG) seem promising but have critical issues:

IssueProblem
No signed outputValues are not cryptographically signed
No historical recordPast outputs are not stored or published
No audit trailCannot verify what value was returned at time T

drand works because every round is publicly signed and permanently recorded:

Round #12345679:
  value: 0x8a3f2e9b1c4d...
  signature: BLS_signature(value, round)

Anyone can verify and fetch forever.

QRNG APIs are ephemeral — no way to audit past outputs or prove what value was returned.

Self-Verification vs Threshold Signatures​

Some systems use threshold BLS signatures (like drand) to provide "cryptographic proofs." rng.dev takes a different approach — trustless self-verification:

PropertyThreshold BLS (drand)rng.dev Self-Verification
Who validates?20+ anonymous operatorsYou (or anyone)
What do you verify?BLS signature mathBlock explorer data
DependenciesMust trust drand operatorsNone — all data is public
AccessibilityRequires BLS expertiseAnyone can check

Verifiability should be accessible to everyone, not just cryptographers. Anyone can verify rng.dev by checking public block explorers.

When to Use Each Option​

RequirementRecommendation
General purposerng.dev 1-second beacon
Real-time gamingrng.dev 1-second beacon
Threshold BLS signatures (regulatory)Self-hosted + drand
Air-gapped deploymentSelf-hosted + hardware entropy
US government complianceSelf-hosted + NIST beacon

Summary​

The 1-second beacon achieves security through:

  1. Economic infeasibility — $80B+ to control all 8 chains
  2. Information-theoretic unpredictability — TXIDs depend on global user behavior
  3. Trustless verification — Anyone can verify using public blockchain data

Self-hosted operators can optionally add drand (for threshold BLS) or hardware entropy (for defense-in-depth), but these are not required for most use cases.

Further Reading​