FVM: Change to randomness syscall behaviour

[arajasek]

Background

The FVM today has two syscalls involving randomness: get_beacon_randomness, which fetches randomness from Drand (today), and get_chain_randomness, which fetches randomness from the blockchain itself (ticket randomness). These syscalls receive the following inputs:

• the round to fetch randomness from
• the Domain Separation Tag (DST) used when drawing randomness
• some "entropy" bytes used when drawing randomness

The FVM and client fetch the randomness source, hash it to create a "digest", and then incorporate the round, DST, and entropy and hash a second time, to draw the final randomness. This value is returned to the caller.

Motivation

While the current approach works well, it is somewhat restrictive. Callers do not get to customize how the randomness is drawn (for example, if a caller didn't want to include the round when drawing randomness, they cannot do this today).

Proposal

The proposal is to simply return the hashed digest to the caller, allowing them to use that as they please. Callers that want to maintain existing behaviour, can mix in the round, DST, and entropy, and then use the FVM's hashing syscalls to draw the same randomness as they would today.

Draft: #817

[anorth]

Can you expand on how this is restrictive? Are there any concrete use case? Why would a client specifically not want, say, a the round number to be incorporated into an unpredictable value?

[arajasek]

I don't think we have a concrete use case in mind. From my perspective, the motivation is primarily around reducing the amount that the FVM does sitting in the middle between a caller and a source of randomness (chain, beacon, etc.). For this syscall, the FVM is really just serving as a "fetcher", and can leave things like entropy, DSTs, hash function to use when drawing, etc. to the caller.

[Stebalien]

For some additional history: the original motivation for changing anything here was to avoid copying an arbitrary string from the actor, to the FVM, then into the client. We've already fixed that by moving the hashing (drawing of randomness) from the client and into the FVM, which isn't a consensus critical change (although the planned adjustment to the gas price list would be).

However, while doing that, we noted that there really wasn't a reason to couple looking up randomness with this hashing operation, and that the FVM already provides a hashing operation. So we're proposing to move the responsibility of drawing randomness from the FVM and into the actors themselves on the principle that anything that doesn't have to be done in the FVM shouldn't be done in the FVM: harder to version/change, requires explicit gas charges, and crashes are more likely to lead to critical security issues.

However, there are a few downsides that have to be mentioned:

1. Because we're removing the round number, we're no longer guaranteeing that chain randomness will be unique for every epoch (e.g., due to null epochs).
2. There will be a slightly higher gas cost by requiring an extra syscall (although we need to adjust the gas fees here anyways as we're significantly undercharging already).