The drand team has been hard at work the last couple of months to develop and integrate new and extremely valuable features into the drand codebase! We have worked together with Zondax, a research and software development company, and we are extremely excited to announce the completion of a very important project for the future of drand. The project focused on two important features that have the potential to unlock new capabilities for the drand randomness service, enable new application scenarios and make drand able to support many more applications and platforms.

In summary, the new features include:

• Unchained Randomness: Each randomness beacon in drand has so far been linked to the previous one, forming a chain of beacons. With this update, each beacon is now independent of (all) the previous one(s).
• Multi-protocol Support: Drand is now able to support multiple protocols running on the same physical node and the same binary. In other words, a node can now participate in multiple drand networks, each of which having different characteristics. These characteristics can be different frequency of emitting randomness, different thresholds, different participants or having randomness in chained or unchained mode.

We have compiled a comprehensive list of 26 Q&A in this FAQ document. Below we provide a base summary of the new features and we encourage you to refer to the document for further details.

⛓️ Unchained Randomness & Timed Encryption 🔐

What is this?

According to the original drand design and implementation, every new beacon is linked to the previous one, i.e., simplistically, every new beacon includes a link to the previous beacon, used to derive the new randomness. This creates a chain of randomness beacons from the current one to the genesis beacon, when the drand network was launched. With this upgrade, we provide the option of each beacon becoming independent of the previous one, or, in other words, randomness can be “unchained”. A new drand network can still run in “chained” mode, although we recommend using the “unchained” randomness version.

What does it enable?

Although chained randomness provides some nice properties, having each beacon independent of the previous one presents a lot of potential for some applications: drand consumers can now enable timelock encryption in their applications, which means that they can securely encrypt a message for a specific round in the future, which can then be decrypted by anyone with the corresponding randomness. This is a very important feature which can mitigate front-running attacks in Decentralized Exchanges, and oracle platforms, as well as enabling sealed bid auctions.

How does it work?

Both randomness generation and consumption procedures remain the same as previously. All members of a drand network, e.g., the LoE, need to contribute their part in order for Threshold Cryptography to work. As with the Multi-Frequency support feature, no security property of the protocol is compromised.

We will deliver this API in the coming months but we provide a sneak peek at how it can look like:

First, a client encrypts a message towards a round in the future.

ciphertext := client.EncryptToRound(msg, round)

Then, once the associated randomness is created, anybody can decrypt the message:

// get the randomness associated with the round

random := client.Randomness(round)

message := client.Decrypt(ciphertext,random)

With this feature, drand has the potential to solve problems that remain unsolved in the Web3.0 space, such as front-running attacks, and puts drand ahead of the competition!