Verifiable Randomness

Randomness is a fundamental primitive in cryptography and decentralized systems. To be effective in trust-minimized environments, it must be verifiable, unbiased, and unpredictable to all observers across all contexts. This section introduces how dcipher achieves these guarantees and how it compares to other approaches.

What is Verifiable Randomness?

Verifiable randomness refers to a cryptographically generated value that is both unpredictable before it is produced and publicly verifiable after publication. This ensures that no party can manipulate the outcome and that anyone can independently confirm its correctness.

A common approach to achieving this is through a Verifiable Random Function (VRF) in combination with Distributed Key Generation (DKG). In this setup, a group of participants jointly generate and hold shares of a private key without ever reconstructing the full key. When randomness is needed, a threshold subset of these participants collaboratively generate a pseudorandom output along with a proof of correctness. Anyone with the corresponding public key can verify the result, ensuring transparency and eliminating the need to trust any single party.

Key Properties

Three key properties define verifiable randomness:

1. Deterministic

• Given the same secret key and input, the VRF will always produce the same output. This ensures consistency across the network.

1. Unpredictable

• To anyone without the secret key, the output appears indistinguishable from true randomness. No one can guess it in advance.

1. Verifiable

• Anyone can verify the authenticity of the output and ensure that it was generated correctly.

More generally, good randomness should be:

• Unbiased: No participant can influence the outcome
• Available: Reliably generated at known intervals

How It Works

dcipher produces verifiable randomness using threshold BLS signatures and a distributed key generation (DKG) process:

1. Committee Setup

• A group of nodes (a committee) runs DKG to create a shared and sharded private key
• Each node receives a private key share, enabling partial signing

2. Randomness Request

• A new randomness round is initiated (e.g., on-chain trigger or scheduled interval)
• Each node signs the round number using its private share

3. Signature Aggregation

• Once a threshold number of partial signatures is gathered, they are combined into one full BLS signature
• This signature is hashed to produce the final random value

4. Verification

• Anyone can verify the BLS signature using the public key
• Anyone can hash the signature and compare its digest to the random number
• The process ensures determinism, uniqueness, and unpredictability

💡 Note: This model supports unbiased randomness generation across chains, and even without the need for a chain, depending on the use case.

Comparing Randomness Sources

Feature	dcipher	On-chain randomness (RANDAO)	Off-chain VRF (ChainLink)	Trusted oracles
Verifiable	✅ (Threshold VRF proof)	❌	✅ (VRF proof on-chain)	❌
Decentralized	✅ (permissionless Roadmap)	✅ (Fully on-chain)	⚠️ (Chainlink node set)	❌
Bias-resistant	✅ (threshold-controlled)	⚠️ Weak	✅	❌
Performance	⚡ Fast	⚠️ High latency	⚡ Fast	⚠️ (Also Centralized)

How is dcipher different from on-chain VRFs?

Decentralization

dcipher is inherently decentralized. It uses a threshold network where multiple independent nodes jointly produce randomness. VRF, by contrast, typically rely on a single operator or small group holding the secret key — even if the output is verifiable, it's not collectively generated.

Trust model

• In an on-chain VRF, you must trust that the entity holding the private key acts honestly
• With dcipher, the DKG process distributes trust across a committee, and slashing penalties promote good behavior of the node operators

Extensibility

dcipher supports programmable conditions and custom workflows (e.g. timelock decryption, re-encryption, conditional signing), making it more flexible for complex applications. VRFs are more rigid and only produce random outputs.

Use cases

• VRFs: Great for simple, high-latency use cases like gaming or lottery selection
• dcipher: Better suited for high-assurance, multi-chain, programmable randomness — such as privacy-preserving systems and validator coordination

How is dcipher different from trusted oracles?

Decentralization

Similar to on-chain VRFs above, trusted oracles mostly have centralized control as opposed to the dcipher distributed trust model.

Transparency and verifiability

• Trusted oracles: Can't verify how the randomness was generated
• dcipher: Publishes a cryptographic proof (BLS signature) that anyone can verify against a known public key

Bias resistance

• Trusted oracles: Can potentially manipulate or delay randomness
• dcipher: can tolerate up to 50% of malicious nodes without delaying randomness, and cannot be manipulated even with 100% malicious nodes.

Programmability and modularity

dcipher supports conditional logic, timelock encryption, and re-encryption, allowing you to build more complex workflows on top of its randomness infrastructure. Trusted oracles are usually black-box services with limited functionality.

Security assumptions

dcipher builds on a robust, multi-phase security model focused specifically on the secure generation of verifiable randomness. These assumptions apply only to randomness generation, not to features like blocklock encryption.

Setup phase (Distributed Key Generation)

• Authenticated channels: All DKG messages are signed with BLS keys to prevent forgery
• Qualified set: Only nodes that successfully complete the DKG are included in signing
• Malicious threshold: Fewer than t-of-n nodes can be adversarial without compromising security

Randomness generation phase

• Partial beacon determinism: Each node can produce exactly one valid partial per round
• Threshold availability: At least $t$ honest, online nodes must respond per round to progress
• Non-reliance on broadcast guarantees: The protocol functions without guaranteed message ordering or delivery

Resilience and failure modes

• Proactive resharing: New keys and shares can be generated across a refreshed or rotated committee, and shares are not reusable across reshares.
• Chain determinism: A DKG defines a unique, deterministic randomness chain. Even if a threshold of key shares is compromised, future randomness can be predicted but not altered, as the output is fixed by the protocol and input history
• Threshold resistance: The system remains live unless $t$ or more nodes are taken down. An attacker must disable at least the threshold number of participants to successfully DoS the network
• DoS recovery: Honest nodes can rejoin or reinitialize if temporarily taken offline

Adversary model

• Passive adversary: May observe traffic but cannot bias outputs or infer secrets
• Active adversary: Must control ≥ $t$ nodes to halt or predict randomness
• Threshold integrity: If fewer than $t$ nodes are compromised, the randomness remains secure and future rounds are unpredictable

Next steps

Try generating your first random number in our Quickstart.