【Filecoin】Drand: The source of randomness for Filecoin

Similar to the Beacon Chain implemented by Ethereum 2.0, Filecoin currently uses Drand as its Beacon source and enables the originally designed Ticket Chain. We know that the Ticket Chain is actually a logical chain that is parasitic on the Filecoin chain. Although the Ticket Chain is well designed, it still has its unsatisfactory aspects, such as: 1) Its Ticket is available for each block, but only one is required for each height, so there is a selection problem here, but this problem is not big; in addition, 2Ticket itself is not unpredictable to everyone, because the Ticket is generated by the miner, so the block miner knows what the random number is earlier than others; further, 3) when the chain is forked and reorganized, the Ticket will change, which will invalidate many calculations that rely on the Ticket.

Therefore, Ticket Chain is not an ideal solution. The Filecoin team is good at adopting new technologies. After weighing the pros and cons, the current processing method is to completely separate the generation of random numbers from the Filecoin network and enable a public, unpredictable, non-biased, and publicly verifiable random source. This random source is Drand.

In short, a good random source should have the following characteristics:

• Unpredictable: Any individual or group at any point in time cannot predict the random number released

• No bias: The final output distribution is completely random and cannot have any tendency

• Publicly verifiable: After the random number is generated, anyone can verify it

• Decentralization: Random numbers should be generated by a group of independent and active individuals

• Availability: The system must keep running, always (according to the rhythm) continuously outputting random results

Drand (pronounced "dee-rand") is a program that runs as distributed nodes. Written in Golang, Drand uses bilinear pairing and threshold cryptography to link servers running drand to each other to generate common, publicly verifiable, unbiased, and unpredictable random values ​​at fixed intervals. Drand nodes can also provide locally generated private randomness to clients.

drand was originally developed within the DEDIS (Decentralized Distributed Organization) organization, and in December 2019, it became an independent drand organization.

The demand for public verifiable random numbers is very widespread. For example, in gambling, blockchain systems, and embedded devices; similarly, it is also crucial in some statistical sampling: such as autonomous organizations, elections, jury composition, random financial audits, etc. However, building a secure source of randomness is by no means easy. In our real life, there are various failed attacks, such as cheating in welfare lotteries, favoritism in elections, etc. There are many reasons that affect the generation of randomness, such as: static keys, non-uniform distribution, output bias, etc.

Well, Drand aims to achieve that breakthrough by providing a randomness-as-a-service network (similar to an NTP server for time or a certificate authority server for CA validation), providing a continuous source of randomness.

The Drand mechanism has the following characteristics, or goals:

• Decentralization: Drand is software run by various reputable entities on the Internet, requiring a threshold to generate randomness, with no central point of failure.

• Publicly verifiable and unbiased: drand provides publicly verifiable and unbiased randomness on a regular basis. Any third party can obtain and verify the authenticity of the randomness and ensure that it has not been tampered with.

• Also provides "private" local services: Drand nodes can also provide cryptographic randomness for use by local applications, such as injecting seeds for the operating system's PRNG.

Currently, the Drand Network is operated by organizations around the world including Cloudflare, EPFL, Kudelski Security, Protocol Labs, Celo, UCL, and UIUC.

If you want to learn more, you can visit the League of Entropy website, where you can also view the random values ​​generated by the network in real time.

The main function of Drand is to generate public random numbers. This is achieved by the collaboration of Drand nodes.

The main challenge in generating good randomness is that no party involved in the randomness generation process can predict or bias the final output. In addition, the final result must be verifiable by a third party so that it can be used in various applications, such as lottery, parameter generation in sharding or security protocols, etc. In the Filecoin network, this kind of random number is used in many occasions, such as block generation rights, various stages of replication proof, time-space proof, etc.

The Drand random beacon consists of a set of distributed nodes and is divided into two phases:

1. Setup: Each node first generates a fixed public-private key pair for long-term use. Then, all public keys are written to a group file together with some other metadata required to operate the beacon. After distributing this group file, the node executes the distributed key generation (DKG) protocol to create a public public key and a private key factor for each server. In other words, this private key is a distributed private key that is jointly owned by a group of nodes. Each participant will not explicitly see or use the entire distributed private key, but use their own private key factor to calculate the public key pair to generate public randomness. The setup process only needs to be run once.

2. Generation: After setup, nodes switch to continuous randomness generation mode. Any node can initiate a randomness generation round by broadcasting a message, which all other participants sign with n threshold versions of the Boneh-Lynn-Shacham (BLS) signature scheme and their respective private key factors. Once any node (or third-party observer) has collected t partial signatures, it can reconstruct the full BLS signature (using Lagrange interpolation). The signatures are then hashed using SHA-512 to ensure that there is no bias in the byte representation of the final output. This hash corresponds to the collective random value and can be verified against the collective public key.

Private randomness, that is, randomness that serves the local node.

Private randomness generation is a secondary feature of Drand. Clients can request private randomness from some or all Drand nodes, which extract it locally from their entropy pools and send it back in encrypted form. This can be useful for gathering randomness from different entropy sources, such as in embedded devices.

In this mode, we assume that the client has a private/public key pair and encapsulates its public key into the server's public key using the ECIES ( Elliptic Curve Integrated Encryption Scheme ) encryption scheme. Upon receiving the request, the Drand node generates 32 random bytes locally, encrypts them using the received public key, and sends them back to the client.

In some devices, since there is no good local noise source, it is difficult to guarantee randomness. In this way, good random numbers can be obtained. For example, many embedded devices or devices that are not designed with special noise sources. However, it must be noted that the initial client key pair must be issued by a trusted source (such as the device manufacturer). When the security of the key pair is affected, the reception of random numbers will be greatly reduced.

Looking back at the five goals of random sources mentioned at the beginning of the article, has Drand achieved them? My conclusion is that it is basically, but not an ideal solution.

Currently, the system is run by different companies, which has achieved a certain degree of decentralization, but it is not completely decentralized, and it is not a very self-contained network. This may be the reason why Drand has not been widely accepted in the blockchain world.

But theoretically speaking, as long as these nodes do not collude with each other and can ensure continuous operation and stable output of random numbers, they are relatively safe.