drand Explainer for Beginners
drand is software for running a threshold network that generates publicly verifiable random numbers.
Boy, that's a mouthful.
To the uninitiated, a bunch of questions spring to mind: What on earth is a threshold network? How can random numbers be verified?! Surely they're random? Why would I want my random numbers to be public?
Well, this blog post is the right place to uncover all the mysteries of the above statement. Let's work backwards to build up a picture of what drand is and how it works.
🔢 Random Numbers
What constitutes a random number?
There are some fancy mathematical definitions, but stated simply: it's a number that cannot be guessed at a rate better than chance. Suppose we choose a random number in the range 1 and 100 (including 100). If we asked 100 people to guess our number, on average only one of those people would guess the number correctly, even with a fully random selection process.
For cryptographic purposes, it's often important that two people don't select the same random number. For example, if two people used the same random number as their Bitcoin private key, they'd be sharing a wallet (and the wallet's funds)!
While this is impossible to prevent entirely, cryptographic schemes use astronomically large number ranges (on the order of the number of atoms in the universe!) to ensure users get unique random numbers if they use proven selection methods.
🏙️ Public Random Numbers vs. Private Random Numbers
Random numbers are used by everybody daily: connecting to a website over HTTPS, signing into our bank account, creating a user account, or purchasing an item online generates random identifiers. Most of these are private random numbers. If you shared random numbers associated with your bank account publicly, a malicious actor might be able to steal all your money.
Public random numbers are different. These are numbers we want everybody to see: think lottery numbers, the roll of a dice in a board game, selecting a business to be audited at random, or a coin flip for who takes the kick-off in a football match. This is exactly the type of randomness that drand provides—you definitely shouldn't generate your Bitcoin private key using drand!
🔍 Verifiability
In examples of public randomness, humans have created procedures to ensure fairness: lottery numbers are drawn from fancy machines, dice are shared in board games to prevent cheating, and a referee picks the coin and flips it for a fair start in football.
However, these solutions are not truly verifiable and require trusting third parties (e.g., referees, dice & lotto manufacturers, etc.) For generating random numbers fast and at scale, proving fairness is more challenging:
Human intuition can mislead us when it comes to randomness. If you were to look at the following binary numbers, which do you think is the most random?
1111111111111111
0000000000000000
1001011010001001
At first glance, the first two seem far too uniform to be random, but from a random selection of values from 0000000000000000 to 1111111111111111 (inclusive), they are all equally likely to occur!
How can we verify a randomly selected number was really random? It seems impossible. However, in drand, we exploit some cryptographic principles to make this possible. To fully understand it, we need a bit of background.
🔏 Digital Signatures
Digital signatures are similar to human signatures: we take some piece of data (like a contract or a letter) and append a message that uniquely identifies us and binds the signature to the data. Digital signatures differ from human signatures in several ways:
- Human signatures map to a single person; digital signatures map to a single private key (and a person could own multiple private keys).
- Human signatures can be copied to another piece of data and still be valid; digital signatures are bound to a single piece of data, as the data is 'included' in the signature in a mathematical sense.
- Digital signatures are verifiable; we can run mathematical operations to verify that the person who created the signature had access to the data and the private key.
So why are we talking about signatures?! This post is about randomness, and I even said we need randomness to generate a signature! Some properties of digital signatures are particularly interesting for randomness. Given some data, an attacker who has our public key but not our private key cannot predict a valid signature for it better than chance. To create a valid signature, they would have to create all possible signatures and verify them against the public key, which would take more computing power than exists in the world. Additionally, there's exactly one valid signature for a given message and private key combination.
Another way to look at this: for users without access to a private key, a signature is indistinguishable from a random number and can be verified using the associated message and public key. If we had a way to create signatures with a private key that nobody could access, we would have publicly verifiable random numbers!
🕳️ Threshold Cryptography
We're close to explaining drand now. We've identified a way to create publicly verifiable numbers that are random under some assumptions but with a small problem: somebody needs to be a custodian for the private key used to create signatures. That amounts to trusting a third party, which we identified as an issue.
Enter threshold cryptography.
Threshold cryptography is like a business bank account: to reduce risk, transactions over a certain value require multiple parties to sign off. A threshold signature scheme is similar in that multiple parties must work together to create a valid signature.
Each party has their own private key and signs a message with it to create a 'partial signature'. When enough partial signatures are created, they can be aggregated into a final valid signature. There's no hierarchy between signers in a threshold scheme; any group of partial signatures will do. 'Enough' is a parameter of the protocol called 'threshold'. It's also called a t of n signature scheme, where t (threshold) of n (total) parties must sign to create a valid signature.
Threshold signature schemes improve our security model compared to normal signature schemes. Instead of relying on a single trusted third party, we can trust a group of numerous, unrelated parties. The probability that t parties collude against us is lower than that of a single party. Another key piece of intuition is that the group shares a public key and private key, but nobody has access to the private key. This is created during a distributed key generation protocol at the foundation of a network.
The threshold signing scheme exploits mathematical properties of pairing-based cryptography, which is outside the scope of this post, to create signatures without ever needing the private key.
👟 Tying It All Together
We've covered a lot of ground, so let's pull it back into the real world and show how drand works in practice.
At the foundation of a drand network, all parties generate their own private key and initiate a distributed key generation protocol to create a shared pair of private and public keys. Recall that NO single party has access to that private key. Every epoch (30 seconds for our default mainnet network), each party signs the same message (the epoch number) and sends their partial signature to the network. Upon receiving partial signatures from others, each party verifies their validity and, upon reaching a threshold number, aggregates them into a single valid group signature. This single group signature is effectively a random number that can be verified as having been created by the drand network. This randomness is released publicly for others to verify and use. Because drand epochs coincide with times on the clock, consumers can commit to certain future random values for use in their applications (e.g., "I will draw the lottery using the random number generated at 12 PM tomorrow by the drand network, which will be epoch 123456").
This was a whistle-stop tour of how drand works, and some details were omitted for clarity.
If you'd like to dive deeper into the cryptography or operation of the drand network, check out our documentation, join our Slack workspace, or email us at: leagueofentropy@googlegroups.com.