Don't Trust Randomness APIs: Verify Drand Beacons
Learn how to independently verify drand randomness beacons from any HTTP relay in just 30 lines of code.
Stock photo for illustration only, not from the actual event
- Agents constantly require verifiable random numbers to prevent manipulation.
- Drand by League of Entropy provides a reliable public randomness beacon.
- Relying blindly on third-party HTTP relays poses hidden verification risks.
- Developers can implement client-side BLS signature checks in 30 lines.
Autonomous agents frequently need to generate random numbers for tasks such as selecting reviewers, breaking ties, or running small raffles. Standard methods like Math.random() fall short the moment someone demands absolute proof that the roll wasn't intentionally repeated until a favorable outcome appeared.
Drand directly resolves this challenge as a public randomness beacon operated by a collective of independent organizations known as the League of Entropy. Every 3 seconds, its quicknet chain publishes a new round containing a BLS signature over the round number alongside a randomness value derived from SHA-256(signature). Anyone possessing the chain's public key can perform an offline verification.
The catch is that most agents refrain from calling drand directly, opting instead to query intermediate HTTP relays. This setup immediately raises trust concerns regarding whether the relay's output has been compromised.
Client-side verification serves as a critical defense mechanism in distributed systems and automation workflows. Delegating trust entirely to an intermediary relay exposes applications to potential man-in-the-middle tampering. Pinning cryptographic keys directly within the client environment ensures end-to-end integrity.
Using a free utility service like Proof Random API returns the latest quicknet round in a flat JSON format through a straightforward HTTP request:
curl -sS 'https://proof-random-api.pn-26f.workers.dev/v1/random?nonce=my-request-1'
The response explicitly displays "verified": false, indicating that the relay does not validate signatures on behalf of the client. All verification logic must execute locally against cryptographically pinned keys.
To establish a secure verification pipeline, follow these core guidelines:
- Never fetch public keys dynamically from the same source you are attempting to verify.
- Hard-code the official quicknet chain hash and public key published by drand.
- Install the official client package using
npm i drand-client. - Fetch the target round from the relay, cross-verify it against drand's native endpoint using BLS verification, and compare the results.
It is important to note that cryptographic verification only proves the number originated from drand; it does not prevent round shopping. If an actor repeatedly queries the latest endpoint until a desired number appears, additional coordination protocols are required.
For absolute fairness in high-stakes draws, all participants must mutually agree on a future round number and nonce prior to publication. Complete implementation details including timeout controls and input validations are available in the verified-client.mjs repository.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment