In the demo above, the moment you commit (Roll-Dice) a commit with the hash of a player secret is sent to the server and the server accepts that and sends back the hash of its secret back and the "future" drand round number at which the randomness will resolve. The future used in the demo is 10 secs
When the reveal happens (after drand's particular round) all the secrets are revealed and the random number is generated using "player-seed:server-seed:drand-signature".
All the verification is in Math, so truly trust-less, so:
1. Player-Seed should matches the player-hash committed
2. Server-Seed should matches the server-hash committed
3. Drand-Signature can is publicly not available at the time of commit and is available at the time of reveal. (Time-Locked)
4. Random number generated is deterministic after the event and unknown and unpredictably before the event.
5. No party can influence the final outcome, specially no "last-look" advantange for anyone.
I think this should be used in all games, online lottery/gambling and other systems which want to be fair by design not by trust.
Are you sure? The protocol described in Chuck Norris book Applied Cryptography seems to work fine without a randomness beacon. Once you get the commitments from all parties they reveal the nonces and everyone verifies they match the commitments and extracts the same random bits.
In a standard 2-party commit-reveal, one party always learns the result first. (Mostly servers in current setups).
By adding a Randomness Beacon (Drand) as a third entropy source, we solve two things: No Last-Look: Neither the player nor the server knows the outcome until a specific future timestamp (the Drand round). Forced Resolution: Since the Drand signature is public, once that round passes, the result is 'locked' by math. The server can't hold the result hostage because anyone can pull the Drand signature and verify the result themselves.
I looked at VDFs and custom MPCs, but they felt like overkill for a dice roll. Drand is basically a "pre-computed" MPC that anyone can verify with a simple curl. It hits that pragmatic sweet spot for a trustless audit without the "math homework" for the user...
It turns the server from a "Judge" into a "Timestamped Vault" that can't hold the outcome hostage if it's unfavourable, giving the player a winning ticket they can verify independently.
If a server sees the Drand beacon just a few milliseconds before the user's commit is finalized, they can 'veto' a winning roll by dropping the packet.
Is 10s of UX friction a fair price for a Time-Lock that ensures the result literally doesn't exist anywhere in the world at the moment of commitment?
Error: JSON.parse: unexpected character at line 1 column 1 of the JSON data
Commitment already pending for Round 26020619. Please wait for settlement before starting a new round.The logic of back end api (written in go, commitment stored in firestore), is intact, the 409 will come only if the same user tries to commit again before the reveal, this is by design.
Error: The string did not match the expected pattern.