Migration to new drand network and scheme

[CluEleSsUK]

Summary

The drand team along with the League of Entropy are launching a new network with some minor changes to the scheme and a higher frequency of beacon generation. 
The higher frequency doesn’t have any immediate benefits for Filecoin, however the scheme changes would:

• enable timelock encryption
• reduce the beacon signature size and verification time

Motivation

With development of a new unchained scheme for drand, we exploit identity-based encryption to enable users to encrypt messages that can only be decrypted once a future round has been reached.

Following a successful testnet launch in Q2 2022, we are launching the unchained scheme into drand mainnet in Q1 2023.

We are targeting a 3 second frequency, i.e. a beacon every 3 seconds instead of the present 30 second frequency to enable use cases that require more frequent randomness without them having to take additional measures (such as seeding a PRNG verifiably).


Filecoin migration to an unchained drand network would enable timelock encryption support and thus simplify its support as a native actor in FVM, which has already had some interest from ecosystem developers at FIL Bangalore.

In addition to this, in Q1 2023 we are releasing a further improvement to our signature generation protocol which would enable smaller signature payloads for faster and cheaper verification on-chain.
Yolan gave a brief presentation on the changes at the LoE summit in Lisbon.
In short, our scheme allows for swapping the generator groups G1 and G2 without any compromise of security. This results in shorter signatures, saving space, creation time and verification time, and will ultimately lead to lower gas fees for FVM users.

A signature on G1 is encoded with 96 bytes instead of the 192 bytes of a signature on G2.
 The trade-off of this change is a larger public key (192 bytes instead of 96 bytes), but given we only store a single group public key per network, this is a negligible difference overall.

Scope of work

• update filecoin clients to consume every 10th round from drand rather than every consecutive one (e.g. in lotus: https://github.com/filecoin-project/lotus/blob/6067968c07c243edb88195e1ce4c05e1a5fd81bf/chain/beacon/drand/drand.go#L181)
• update the drand config of filecoin clients to use the new network ChainInfo (for lotus: https://github.com/filecoin-project/lotus/blob/6067968c07c243edb88195e1ce4c05e1a5fd81bf/build/drand.go)
• update drand client library to the latest version for signature verification (the exact version number TBC)

[CluEleSsUK]

I noted there was some previous discussion loosely around timelock encryption here, but it was not a concrete proposal to migrate the network as this one is.

[AnomalRoil]

The goal of this discussion, as recommended by @Kubuxu, is to help us frame the FIP we'd like to propose soon on this topic, about switching to the new drand mainnet network we'll be launching in Q1'23.

Note that the proposed changes will require a network upgrade on Filecoin side. There's no urgency, however the current drand mainnet might be deprecated at some point in the future, so it would be best to upgrade to the newer, faster, more capable one.

[jsoares]

While there is no technical urgency, this would be quite interesting from a product perspective with FVM landing. I wouldn't think of this FIP with regards to the deprecation of the old network, but really in terms of the value it can bring to the network -- and the sooner the better, though obviously not before the new network is running stable.

[AnomalRoil]

Being able to support timelock at the FVM level will require quite some more fiddling, since currently the drand signatures are in the block headers which cannot be accessed easily right now, if I understand correctly.
But, yes, moving to the new network is a pre-requisite for that anyway.

[jennijuju]

another consideration is that as the new network stabilized, the old network maybe sunset by LOE, right? If so, do we have any projected timeline on when that's gonna happen?

[CluEleSsUK]

That is on the cards, but no timeline for it has been discussed - we will have to scope out what other projects are relying on it and what their migration timelines are like.
Regardless, this won’t be in the first half of 2023 and maybe not even the second half

[jsoares]

Something that came to mind: will we need to re-test the catch-up mechanism, including with a Filecoin testnet?

This was a big concern for the original deployment, and I remember our first Filecoin tests around recovering from a drand halt failing. With the new unchained randomness, we could in theory fully parallelise the generation of the late rounds, though I see the fastnet params still include a catch-up period and so assume the mechanism remains.

Still, it's not something that ever happens, and I'm not sure there are tests on the Filecoin side covering this. It probably wouldn't be a bad idea to try it.

[CluEleSsUK]

Indeed we still have the catch-up period at half of the normal period. As I understand, the rationale was to limit network traffic during the recovery of an outage so as not to bring down any of the nodes (particularly those running on constrained resources).

We run with 0 catch-up period in testnet, and when we had an outage there it didn’t seem to cause a problem, so I’d be up for experimenting with the concurrent catchup.

As of now though, the state of play hasn’t changed for filecoin with the launch of fastnet

[jennijuju]

Should there be an update in the FIP draft w.r.t to the fastnet -> quicknet?

[AnomalRoil]

Yes. We'll update it in ~2 weeks once all the information is finalized.

[jsoares]

There's not much left to say; I'm looking forward to seeing this go live! Great work, folks.