Enable use of current drand randomness via native actor

[CluEleSsUK]

Situation

Developers of smart contracts use randomness for a variety of use cases: generation of NFTs, drawing winners of lotteries, and in future timelock encryption (and decryption). As the generation of Filecoin block headers requires consumption of the latest round of drand randomness, users can rely on this as a source of unbiasable, verifiable randomness for these uses cases.

Presently, the last block's randomness can be retrieved via prevrandao, but given the time between blocks, this could allow an adversary to choose to transact or not transact based on its value, making it impractical for the aforementioned use cases.

There exists a precompile get_randomness (I could only find its implementation in Forest - is that the correct one?) which can be used to fetch drand randomness from a given epoch, but it's currently disabled in fvm and unclear whether it can be used to use the (unpredictable) randomness of the current block.

Additionally, right now the drand randomness (a SHA256 digest of the network's signed message) can be consumed, but signature itself cannot. While an invalid drand beacon cannot enter the filecoin block headers, the signature (and the capability to verify the signature) is useful for consuming randomness from other networks and is also essential to enabling timelock encryption.

Mission

• enable the precompile for pulling in historical randomness
• enable users to 'slot in' the latest randomness to their smart contracts using the drand value in the final block.
• enable users to retrieve the public key of the drand network being used on-chain, to enable encryption of messages toward that network.

Out there idea

Could users schedule evaluation of certain commitments, e.g. automating timelock decryption or paying out a lottery winner, by paying for a transaction up-front? e.g. at epoch 1 a user commits to paying out a lottery at epoch 20, when epoch 20 is mined the randomness from that block is automatically consumed by their actor and the winner of the lottery gets paid out.

I'm not sure if that's possible from my limited understanding of fvm - but worth throwing it out!

Slack

A link to the slack thread where this discussion started

[mriise]

The native get_randomness precompile referred to here was removed in this PR: https://github.com/filecoin-project/builtin-actors/pull/1082

[Stebalien]

The goal is to ship something like this (access to drand randomness) in a future upgrade.

Could users schedule evaluation of certain commitments, e.g. automating timelock decryption or paying out a lottery winner, by paying for a transaction up-front?

Yes, this is generally called "userspace cron".

---

I recommend starting a discussion in https://github.com/filecoin-project/FIPs/discussions. The wider FIP community will be interested in this and could use input on potential designs.

[Stebalien]

Components:

1. Some form of get_drand(epoch) syscall.
2. Support for BLS12-381 pairing. We can likely do this in wasm without FVM support, but we'd need to benchmark that.
3. Some form of timelock_decrypt fevm precompile.

The main decision we'll have to make concerns randomness lookback. IMO, we should just index all drand beacons (reorgs aren't possible, anyways), and support looking up randomness at any epoch.

[Stebalien]

While an invalid drand beacon cannot enter the filecoin block headers, the signature (and the capability to verify the signature) is useful for consuming randomness from other networks and is also essential to enabling timelock encryption.

NOTE: the signature is included on-chain, it's just that the current randomness syscalls don't expose it directly.