Timelock Encryption and Threshold VRFs

Timelock encryption allows a message to be encrypted to a future point in time such that it cannot be decrypted until that time arrives — without a trusted custodian. Combined with threshold Verifiable Random Functions (VRFs) running at consensus latency, this enables sealed-bid auctions, front-running-resistant transaction ordering, and commit-reveal games without TEEs. (→ NoConsensus.wtf 2025 — Overview)

Threshold VRF in Consensus (Patrick O’Grady / Commonware)

A Verifiable Random Function (VRF) produces a deterministic, pseudorandom output plus a proof that the output is correct. A threshold VRF requires a quorum of participants (e.g., 2-of-3 or 2f+1-of-3f+1) to collaboratively generate the VRF output — no single party knows the output in advance.

Commonware’s Alto: a consensus cluster benchmark running a threshold variant of the Simplex consensus protocol. The system continuously produces threshold VRF outputs as a byproduct of consensus, at the current consensus view latency:

  • US-only cluster: ~80 ms per VRF output.
  • Global topology: ~200 ms per VRF output.

This means verifiable randomness is available at near-network-speed — fast enough to use in per-round protocol logic.

Timelock Encryption

Timelock encryption (TLE): encrypt a message to a future VRF output. The message is decryptable only after the corresponding consensus round, when the VRF output is revealed by the quorum.

Based on BLS threshold signatures: encrypt to the threshold BLS public key corresponding to view V. No one can decrypt until round V’s threshold signature is produced.

Key property: decryption is non-interactive and trustless once the consensus round produces the VRF output. No custodian or key management ceremony needed per message.

Relationship to League of Entropy / drand: League of Entropy provides distributed randomness via a rotating committee of organizations. Commonware integrates VRF production natively into consensus, making it available at consensus frequency (sub-second) rather than at a slower external beacon frequency.

Applications in Crypto

Sealed-bid auctions: bidders encrypt bids to the round in which auction closes. No bid is readable until all bids are submitted. Eliminates last-second bid sniping and front-running of auction outcomes.

Front-running-resistant transaction ordering: users encrypt transactions to the next block’s VRF output. Builder cannot read transactions before commitment, eliminating sandwiching without requiring a TEE. Weaker assumption than TEE (cryptographic assumption vs. hardware assumption).

Commit-reveal schemes: standard commit-reveal requires a second transaction (the reveal). With TLE, the “reveal” happens automatically when the consensus round concludes — reducing it to a one-transaction flow.

Random trait generation: Commonware’s Battleware demo game uses per-round VRF to:

  1. Generate character traits (health, attacks) deterministically from a 32-byte VRF digest.
  2. Select battle pairings randomly.
  3. Determine attack strength randomly (50–100% of nominal damage) — preventing degenerate “always use strongest attack” strategies.
  4. Bind player moves via timelock encryption — moves are committed but not revealed until both players lock, enabling trustless P2P gameplay.

This demo illustrates the UX value: timelock encryption makes “commit first, reveal later” visceral and intuitive in a game context, building mental model for more serious applications.

Trade-offs vs. TEE-Based Approaches

Timelock EncryptionTEE (e.g., BuilderNET)
Trust assumptionThreshold cryptographic (1-of-n dishonest)Hardware (TEE not compromised)
LatencyOne consensus round before decryptionImmediate inside TEE
ComposabilityDecryption is protocol-native, no special infrastructureRequires TEE-capable hardware
Failure modeThreshold key compromise (catastrophic)TEE breach (detectable via fail-stop)

For many applications, the cryptographic assumption of threshold BLS is preferable to a hardware trust assumption — especially for user-facing applications where TEE availability isn’t guaranteed.

Connections

Open Questions

  • Can timelock encryption operate fast enough (80–200 ms per round) for latency-sensitive DeFi applications?
  • Does threshold BLS key compromise (from colluding validators) represent an acceptable attack surface relative to TEE compromise?
  • Could timelock encryption replace TEEs entirely for encrypted mempools, or are TEEs still required for the ordering logic itself?