quicknet is live on the League of Entropy mainnet

By: Yolan Romailler News Tweet It

We are thrilled to announce the General Availability of our brand new quicknet drand network running on the mainnet nodes. This significant upgrade harnesses the capabilities of the new unchained randomness mode, enables timelock encryption in production and delivers outputs at a much faster frequency of 3 seconds!

The network has now been running without hiccups for a month and a half, since its launch on August 23rd, and we’ve seen our first early adopters start transitioning to it successfully.

# Key Features of quicknet drand Network 🌟

Keep reading to learn more details about the new features this network launch enables:

  • Unchained randomness mode: This allows for faster and simpler beacon verification. Furthermore, unchained mode allows one to predict the message that will be signed in a future round (but nothing else), thus enabling “timelock encryption”!
  • Runs on the League of Entropy’s mainnet nodes: Offers robustness, scalability, and reliability to our users, it runs on the same nodes that have been flawlessly delivering beacons every 30s for the past 3 years without missing a single beat.
  • 3s frequency: Quicker generation compared to the legacy frequency, enabling faster applications, better UX and higher throughput.
  • Shorter beacons: Thanks to the G1-G2 swap that we’re detailing below, we’ve been able to cut our signatures’ size by 50%!

# The quicknet details

We have successfully launched the quicknet-t Testnet beacon chain on the 13th of July and more recently the quicknet one on our Mainnet on the 23rd of August.

They are both available on our HTTPs relays, just like the previous default network. All available chains on a given relay can be queried using the /chains endpoint, e.g. https://api.drand.sh/chains (opens new window) returns:


which are the chain-hashes of the fastnet, quicknet and default chains respectively!

The same holds for our testnet relays, e.g. https://pl-us.testnet.drand.sh/chains (opens new window) returns the following chains:

  • 84b2234fb34e835dccd048255d7ad3194b81af7d978c3bf157e3469592ae4e02 our initial, default testnet launched in May 2020 and running in chained mode.
  • 7672797f548f3f4748ac4bf3352fc6c6b6468c9ad40ad456a397545c6e2df5bf our G2 based unchained testnet, launched in May 2022 and compatible with timelock on G2.
  • f3827d772c155f95a9fda8901ddd59591a082df5ac6efe3a479ddb1f5eeb202c our testnet-g unchained beacon chain, featuring our non-RFC compliant G1 signature scheme.
  • cc9c398442737cbd141526600919edd69f1d6f9b4adb67e4d912fbc64341a9a5 which is our latest quicknet-t network, featuring RFC compliant BLS12-381 G1 based BLS signatures!

Don’t hesitate to check our developer documentation (opens new window) for more information about our public endpoints!

# quicknet-t

You can always get more details about a given chain by querying its {chainhash}/info endpoint, e.g. https://testnet-api.drand.cloudflare.com/cc9c398442737cbd141526600919edd69f1d6f9b4adb67e4d912fbc64341a9a5/info (opens new window) returns the quicknet-t details:


# quicknet

The same holds for our mainnet relays, any given beacon chain information can be queried from our HTTP relays, e.g. https://api.drand.sh/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/info (opens new window) returns the quicknet details:


# Sun-setting of fastnet

If you've been following our blog, you'll remember our previous post about timelock being supported on mainnet (opens new window) where we announced the launch of our new fastnet network that supported our timelock scheme. The League of Entropy launched this new drand network on March 1st, 2023, however we quickly identified an issue with our BLS signatures on G1 that made them non-spec compliant with the Hash To Curve RFC 9380 (opens new window) as well as most BLS signatures implementations on G1 apart from ours. Therefore we had to double down and launch the quicknet network in order to fix this issue.

We’ll be sun-setting fastnet in the coming months as announced previously (opens new window). We are currently going to scale down fastnet by another 3 nodes in November, and we’ll be shutting it down completely in Q1’24 most likely. Please reach out to us if this is a concern for you or your team.

Note: The default chained beacon network remains available with its legacy frequency of 30s for those who require it. We might consider deprecating it at some point in the next 18 months, but nothing is set in stone yet.

# Shoutout to the League of Entropy 🤝

Our decentralisation journey wouldn't be possible without the League of Entropy. We are delighted to share that all members in the League of Entropy are running the quicknet drand network alongside the default chained beacon network on the League’s network of currently 23 nodes.

A big shoutout to the League of Entropy for their invaluable contributions, running drand nodes for free for anyone to use whenever one needs public, verifiable randomness. Together, we're pioneering a faster, more decentralised future for randomness generation, with this new unchained network enabling a host of new possibilities for our users!

# Get Started 🚀

For developers and users eager to dive into the new quicknet drand network, our official documentation (opens new window) provides detailed resources about using drand relays and beacons.

We also have a blog post about “drand for beginners (opens new window)” that’s packed with useful information and another one about using drand on-chain (opens new window) with a demo lottery use-case running on the Filecoin Virtual Machine.

# G1 - G2 Swap

Let us see what the G1-G2 swap really means!

The BLS signature schemes operates on “pairing-friendly” elliptic curves. These curves typically define 3 groups that are of interest to the cryptographer: the group G1 and G2 and the so-called “target group” GT onto which a pairing operation (opens new window) will allow to project points from the groups G1 and G2 in a bilinear manner.

In the current instantiations of drand networks, we’re relying on the pairing-friendly curve BLS12-381, whose groups G1 and G2 have points that can be encoded in 48 bytes and 96 bytes, respectively.

Therefore, it usually makes sense for BLS signatures to be instantiated with the public key over G1 and the signatures over G2, meaning shorter public keys but longer signatures. This is so because the BLS signature scheme allows for signature aggregation, which means we can aggregate multiple signatures for different public keys into a single aggregated signature that verifies against the many public keys. Using short public keys but long signatures hence minimizes the overall size of the data required for verification.

However, this does not apply to drand’s beacons since new ones are generated at a fixed frequency, each with its own signature. Therefore, it makes more sense for drand’s beacons to have shorter signatures and a longer group public key, since we cannot benefit from the aggregation capabilities of BLS signatures and the public key for a given group never changes, and can thus be stored only once unlike the signatures which need to be stored for each single beacon.

This is the reason why it makes more sense given the way drand beacons work to have the public key of the group on G2 (i.e. be of size 96 bytes) and have the signatures of the beacons on the group G1 of BLS12-381 (i.e. be encoded into only 48 bytes).

This swap allowed us to reduce the size of the drand beacons emitted by the new quicknet network by 50%, as well as to increase the performance and reduce the gas cost of any on-chain operations pertaining to drand beacons produced by quicknet.

# Unchained mode

We’ve introduced the notion of unchained beacons (opens new window) last year on the blog already. But in essence, the new drand network brings a host of improvements aimed at enhancing the overall UX for drand users and developers. The 'unchained mode' means that new random beacons are entirely independent from previous ones, meaning that you can now perform stateless verification of a beacon, without having to keep a record of past beacons!

These enhancements are designed to make the drand network more robust, efficient, and user-friendly. They help in reducing the computational and storage load of our users, making drand more cost-effective and faster. The unchained nature of the beacons also means you can now decide to sample only one every 5 beacons to have a frequency of 15s or one every 20 beacons to have a frequency of 1 minute! This significantly improves flexibility and scalability for everyone.

We’re looking forward your projects and ideas, don’t hesitate to join our Slack workspace (opens new window) to discuss these.

# Security considerations

Finally, you might be wondering what these changes might means from a security point of view. On that front, the guarantees of the League of Entropy (LoE) network remain the same:

  • a random beacon cannot be predicted unless a threshold number of LoE nodes collude (current threshold is 12 out of 22 nodes, it should increase as the League of Entropy onboards new members).
  • a random beacon cannot be biased by anybody unless the attacker is able to change the public key of the group, which should be hard-coded in your code.

The fact that the drand beacons are now unchained might give the false impression that they are less secure than the previous chained ones, however this is not the case:

  • predictability: an attacker controlling a threshold number of shares is able to predict any arbitrary round in the unchained setting, whereas they would need to compute all intermediary rounds in order to predict a given future round with the chained setting. However controlling a threshold amount of shares at any point in time allows computation of the shared secret of the group and nothing can prevent such an attacker having obtained the group secret from then computing all future chained rounds offline much faster than the existing network would have, leading to the same result as in the unchained case: a complete predictability of all future rounds in case of a compromise of either schemes.
  • bias: all future beacons are entirely determined by two things: the initial Distributed Key Generation and their round number. This was already the case for the chained network and hasn’t changed with the unchained schemes. For a given distributed group public key, future rounds cannot be biased in any way after the initial Distributed Key Generation ceremony has been run.

We’ve also made sure our new Timelock Encryption service relying on our new quicknet network was properly audited (opens new window). We’ve got you covered!

# Extra liveness!

From a liveness point of view, the way the drand nodes operate hasn’t changed and we are very happy to announce the availability of a new official HTTP relay run by StorSwift (opens new window), a dear member of the League of Entropy. Their relay is reachable at https://api.drand.secureweb3.com:6875 (opens new window) and as you can see by querying https://api.drand.secureweb3.com:6875/chains (opens new window) provides access to both our mainnet default and mainnet quicknet beacons. It is also located in Asia.

As you can see, the League of Entropy’s and drand’s security, liveness and availability are not impacted in any way by these changes - on the contrary.

# Onward!

That’s it, we’ve launched everything we need to allow you to start using Timelock Encryption or drand random beacons right now in your services! And actually people do!

If you are already doing so, or plan on doing so, don’t hesitate to join our drand Slack (opens new window), since we love hearing about what people are doing with what we’ve built!

Until next time! 😄