Add FEVM precompile to fetch drand beacons from chain history

[ZenGround0]

We (@ZenGround0 @anorth) propose adding a precompile to the EVM actor to allow FEVM smart contracts to fetch a drand beacon included in the Filecoin blockchain header at a specified epoch.

The FVM already exposes a syscall for fetching drand beacons at a specified Filecoin epoch. The Filecoin protocol and built-in actors use this to provide randomness for proofs. This proposal introduces a precompile exposing this FVM functionality to the EVM builtin actor, allowing user contracts to make use of the same functionality.

As a historical note, during early development the FEVM team included a similar precompile, but removed it for simplicity for the first launch, lacking a concrete use case.

The motivation behind this proposal is a concrete use case: developing a proof of data possession (PDP) protocol in user-space. The basic form of such a protocol needs an unbiasable source of randomness with lookback to prior epochs. The PREVRANDAO precompile does not provide lookback, but since the Filecoin chain already supports randomness with lookback, we can provide this additional precompile as an extension to raw EVM capabilities.

FIP draft in progress: #1048

[anorth]

An alternative approach to sourcing randomness for a user-space PDP protocol would be for drand beacons, in unchained mode, to be submitted directly to smart contracts from off-chain. drand beacons are independently verifiable so there is no fundamental need to consult the host blockchain.

However, verifying drand beacons requires BLS12-381 operations which are not yet available in the FEVM (or in Ethereum). Adding such precompiles, following EIP-2357 would be a great step in the future and is proposed in #846, but this is a much more complicated change: it will require specifying and implementing a set of new FVM syscalls behind those EVM precompiles. But for fetching drand beacons from the host chain, Filecoin already provides a syscall and all that's missing is exposing it to user contracts.

[anorth]

Since the alternative of submitting drand beacons externally would be a fine basis for a PDP protocol (if verifying those beacons were feasible), this raises a design question about what functionality the precompile should have beyond simply fetching the beacon from chain headers.

Where these beacons are used in the built-in actors for proof verification, the beacon values are mixed with entropy and domain separation tags deep in the built-in actor code. It might be natural to suggest similar mixing for the EVM precompile, but I think we should go with zero additional processing being forced upon the caller unless we can give strong motivations for why they should not be allowed to simply fetch the raw DRAND beacon value.

[Stebalien]

I agree, we should just hand them over directly. That's one of the reasons we changed the underlying FVM randomness sycall to return the randomness directly without mixing in any caller data and/or the domain separation tag.

However note: The FVM (well, the client) will hash the beacon with blake2b before returning it, so we can't quite hand over the raw beacon with no processing whatsoever without making additional low-level changes. However, that hash should be sufficient to efficiently validate a beacon provided from off-chain if the full beacon is desired (e.g., for time-lock operations).

https://github.com/filecoin-project/lotus/blob/475139ff95407ed9d55d3a2ef87e28da66512937/chain/rand/rand.go#L167

[rvagg]

Related discussion about using the chain beacon records for StateGetBeaconEntry here: filecoin-project/lotus#12414

Raises a couple of questions for this FIP - across network versions there's slight variations in how to extract the randomness from the block headers and also variation in how to handle null epochs. Should the FIP outline either or both of those things? I think at least some mention of null epochs would be worthwhile since it may result in unexpected behaviour for the user where two different calls result in the same randomness.

[anorth]

That issue was very scary until I realized it was talking about Lotus API rather than what is made available to the FVM syscall.

This proposal is not aiming to change anything about how that syscall works. To the extent that it was specified previously, that spec should stand. And where the spec is lacking (like any semantics), I guess the existing code is the spec.

I would love a contribution from someone who knows how this works to explain some of the semantics here. @Stebalien or @raulk ?

[anorth]

The first draft of the FIP is ready for review here: #1048

[jennijuju]

Please include more details around #1048 (comment) before last call

[rvagg]

filecoin-project/lotus#12414 (comment) is my summary of behaviour of this syscall (at least from my read of the code, which could be off in subtle ways so caveat emptor).

A few things stand out to me as possibly being worth calling out in the FIP text because it's not mentioned anywhere else:

1. Getting beacon randomness prior to mainnet epoch 1231620 is not going to necessarily get you a 1:1 correspondence with the drand round, in the case of Filecoin having a null round it'll skip either forward or backward and give you some other drand round. (I don't have the means to test this at hand, but I believe that calling this for epoch 892765, a null round will get you drand round 988608 instead of 988609 [the tipset-backward rule], while epoch 1231599 will get you drand round 1327444 instead of 1327443 [the tipset-forward rule]).
2. If you're relying on this syscall to get a specific drand round, then you need to be aware that since quicknet (epoch 3855480) only the rounds that line up with Filecoin epochs will be available to you (1 in 10). If, for example, you were using timelock encryption, then it's only going to work if you project forward to one of the drand rounds that will line up with a Filecoin epoch.
3. In the unlikely case of >20 consecutive null rounds, you're going to get an error. One might imagine up an attack or just an error condition in a smart contract that was caused to look up such an epoch if any ever existed (what's the longest break we have in the chain? there was a halt not long after mainnet launch that went on for a few hours, did that result in a long string of null rounds?). Edit: This is not how the 20 tipset walkback works. tbh I'm not sure what purpose 20 serves, if you hit a null round then you should find a next tipset with your round in it, walking back to find one doesn't make much sense, if it's not there, then you're going to get an error after looking for 20 anyway. I'll comment more in StateGetBeaconEntry uses drand client to look up round instead of using tipset data lotus#12414.