Icy DVRF

Distributed VRF · FROST · eprint 2026/969

Runs an Icy-DVRF-inspired t-of-n verifiable random function over ristretto255, live — you deal shares, publish FROST-style nonce commitments offline, then step the two online rounds that fold into one constant-size, publicly checkable random output.

What is this?

A verifiable random function (VRF) is a dice roll with a receipt: a secret key turns a message into a random-looking output, plus a proof that anyone can check with only the public key. A distributed VRF splits that secret key across n parties so that any t of them can roll the dice together — and no smaller group can roll, predict, or bias the outcome. This page runs the real elliptic-curve math for every step, in your browser.

New to this? Four terms carry the whole page

Share: One party's fragment of the secret key. Any t shares act as the key; t−1 reveal nothing about it (Shamir secret sharing).
Partial evaluation: One party's contribution Γ_i = x_i·P: its share applied to the hashed message. Combine t of them and the full answer appears.
DLEQ proof: A Chaum–Pedersen zero-knowledge proof that a party used its registered share — the same secret behind its public key — rather than an invented value.
Preprocessing (the FROST idea): Parties publish one-time nonce commitments before any message exists. When a request arrives, the commit round is already done, so fewer online round-trips remain — and nobody can pick a nonce after seeing the message.

Exhibit 1 Key ceremony — one secret, n shares

A dealer splits a fresh secret key sk into n Shamir shares with threshold t, and publishes the group public key PK = sk·B plus each party's verification share PK_i.

Demo simplification: a trusted dealer briefly holds the whole secret. Real deployments run a distributed key generation ceremony so no one ever does — DKG internals are out of scope here (see the VSS demo linked in the footer).

Parties n 5 Threshold t 3

Exhibit 2 Offline preprocessing — commit before the question exists

Each party samples one-time nonces (d_i, e_i) and publishes only the commitments (D_i, E_i) = (d_i·B, e_i·B). No message is involved — this round can run overnight, in bulk, long before anyone asks for randomness. It is the round that naive protocols must run per evaluation, online.

Exhibit 3 Two online rounds — step the protocol

Pick a message and a set of participants, then step through the evaluation — every value you see is computed live by this page's instantiation (mapped step-by-step in the construction map linked in the honesty card below). Watch the round ladder: because the commit round already happened offline, the online phase is just broadcast partials → respond to one shared challenge. While a walk is on screen, the controls above it lock — nothing you see can contradict the transcript being explained.

Message

Participants

The round ladder — where the “aha” lives

Online broadcast rounds per evaluation, for three ways to build a DVRF, counted under a synchronous broadcast model (comparison basis and sources: the construction map in the honesty card). Fewer rungs = lower latency when randomness is requested.

Pairing DVRF GLOW / DDH-style

Broadcast partial + proof

1 round · t proofs to check or pairings to compute

Interactive CP-DVRF no preprocessing

Commit to nonces
Broadcast partials, derive challenge
Broadcast responses

3 rounds · constant-size proof

Icy-DVRF FROST preprocessing

Commit to nonces — already done, offline
Broadcast partials, derive shared challenge
Broadcast responses

2 rounds · constant-size proof

Exhibit 4 Anyone can check it — and the proof never grows

The aggregated proof is four values — (Γ, R_B, R_P, z), 128 bytes serialized — whether 3 parties contributed or 300 (the growing part, the round-1 broadcasts, deliberately never enters the final proof). Verification needs only the group public key: two Chaum–Pedersen equations, checked independently, plus β = H(Γ). The demo also compares the threshold result byte-for-byte against the dealer's direct evaluation sk·P (possible here only because the demo dealer kept sk for teaching).

Export the transcript

Verifier workbench — trust nothing from this tab

"Anyone can check it" should be literal, so this verifier shares no state with the exhibits above: it strictly parses a pasted envelope (exact fields, exact lengths, canonical ristretto255 encodings, canonical scalar) and only then runs the two equations. Paste the export from above, an envelope from another tab or machine — or tamper with one character and watch it fail with the field named.

Proof envelope (JSON)

Exhibit 5 Break it yourself — cheat, and get caught by the math

Make a party misbehave, run the evaluation again, and watch the real verifier react. Four different properties get probed here, and they are not the same thing: unpredictability (before round 1, nobody knows β), fixed-input uniqueness (for this key and message, no other β can ever verify), public verifiability (Exhibit 4), and liveness — the one cheaters can attack. A corrupted partial fails the DLEQ input equation; a substituted nonce fails the key equation (a party can still try a post-message swap — it just cannot produce a proof that verifies against the slot it committed before the message existed); a withholder can learn β and then censor it (though when someone also corrupts a partial, the aggregate it saw is one verification rejects — so the run reports what the verified partials determine, or that nothing publishable was determined at all); and absences either don't matter (≥ t remain) or force a fail-closed refusal.

What's real here — and what this page does not prove

Real: every group operation (ristretto255 via @noble/curves, pinned to RFC 9496 known-answer tests), the Shamir sharing, the binding factors, the DLEQ proofs, the aggregation, and every verification shown — all execute live in your browser.
Simulated: the network. All "parties" are objects in one browser tab, and the key ceremony uses a trusted dealer instead of a DKG. Keys and nonces are per-session, in memory only.
Simplified: the protocol follows the structure of Icy-DVRF (eprint 2026/969) — FROST-style preprocessing, shared-challenge DLEQ, constant-size aggregated proof — but is this demo's own instantiation over ristretto255, not the paper's EVM-targeted parameterization, and equivalence to the paper has not been established. Every hashed byte, encoding, and deliberate deviation is documented in the construction map, and frozen transcript vectors pin the instantiation in CI. None of it is constant-time.
Scope of "no bias": what the exhibits prove is fixed-input uniqueness — for one key and one message, no alternative β can ever verify. They also show what uniqueness does not give you: a coalition that withholds round 2 can learn β and censor it (selective abort). A real beacon preserves the no-steering claim only with a retry rule that keeps the message fixed and replaces the withholder — never by rolling a fresh candidate output.
Not proven: security against a real adversary. A cheater in this tab is scripted; a real one is not. This is a teaching demo, not production crypto — do not reuse any of it in a system that matters.