| fip | title | author | discussions-to | status | type | created |
|---|---|---|---|---|---|---|
0095 |
Add FEVM precompile to fetch beacon digest from chain history |
@ZenGround0, @anorth |
Final |
Technical Core |
2024-08-26 |
Adds a precompile to the EVM actor to allow EVM smart contracts to fetch drand beacon digests from the chain history.
The FVM exposes a syscall for fetching the digest of a drand beacon included in some prior Filecoin chain header. The built-in actors use this facility to provide randomness for storage proofs. This proposal introduces an EVM actor precompile exposing this functionality to user-deployed smart contracts so that they can also use random challenges for other types of proofs.
A source of un-biasable randomness is a useful primitive in proofs of service, as evidenced by its use in Filecoin's existing proof of storage protocol. The Filecoin blockchain already embodies all the infrastructure to provide this primitive, but is missing the hook-up to where user-deployed smart contracts can use it. This proposal provides that hook-up.
The EVM does already provide a PREVRANDAO opcode, but this is limited to access randomness from the immediately prior epoch. This primitive is not suited to protocols where the randomness is incorporated into off-chain protocols, since the prover must observe the randomness, use it for computation, and submit a message that must be included in the immediate next epoch in order for a smart contract to be able to verify that the correct randomness source was used. Access to values from prior epochs allows for protocols that commit to a challenge before it is used, take more than one epoch to complete, and/or are robust to short-lived chain instability or forks.
The concrete use case motivating the authors is to make it possible to build a proof-of-data possession in user-deployed smart contracts.
A new precompile is added to the built-in EVM actor, which implements all user-deployed smart contracts.
The precompile is callable at Ethereum address 0xfe00..06.
| Param | Value |
|---|---|
| epoch | u256 - low i64 |
The call errors with PrecompileError::InvalidInput if the epoch is not a valid, prior epoch number.
This calls directly to the FVM's get_beacon_randomness syscall.
This section documents the semantics of the existing get_beacon_randomness syscall.
It is descriptive, not normative.
This FIP does not propose any change to the implemented behaviour, even if it differs from this description.
The get_beacon_randomness syscall returns a Blake2b-256 hash digest of the
randomness value from the drand beacon corresponding to the requested Filecoin epoch.
This syscall has a gas cost function that scales linearly with the number of epochs that have elapsed since
the requested epoch.
Each Filecoin epoch maps to a drand round number.
The drand round number for an epoch is given by (epoch_time - drand_genesis_time) / drand_period + 1.
The drand beacon for this round number is expected to be found in the block header BeaconEntries field
in every block in the tipset at that epoch.
If the epoch number addresses an empty tipset, the beacon is found in the next non-empty tipset,
which BeaconEntries includes a beacon for each preceding null round.
Note that not every drand beacon necessarily appears in a Filecoin tipset. Where the drand network has a faster epoch time than Filecoin, as is the case with Filecoin mainnet and the drand quicknet, only those drand beacons that correspond to a Filecoin tipset are accessible.
Due to changes in protocol specification over time, nodes participating in the Filecoin mainnet do not implement the canonical behaviour for all requested epochs.
When the requested epoch corresponds to a null round and is:
- prior to 892800 (network version 13): selects the last beacon entry from the preceding non-empty tipset;
- between 892800 (v13) and 1231620 (v14): selects the last beacon entry from the next subsequent non-empty tipset;
- between 1231620 (v14) and 1594680 (v15): calculates drand round number as
(epoch_time - drand_genesis_time) / drand_period(off-by-one)
In these cases, the beacon round number will not canonically correspond to the Filecoin epoch number. For requests from epoch 1594680 (v15) onwards, the canonical behaviour is implemented.
The beacon value is provided in as raw a form as possible, given the FVM already hashes the beacon randomness. Including further entropy is left to the caller.
Adding a new syscall to return the un-hashed beacon randomness would add complexity without adding fundamental capability. If a full drand beacon is required (e.g. for time-lock operations), a user-submitted beacon can be validated by hashing it and comparing with the value returned by the new precompile.
This proposal introduces a new precompile available to FEVM smart contracts.
Any existing smart contract which invokes this previously-unbound address will now observe a successful call.
As part of implementation we should have:
- Builtin actors tests that the precompile is accessible and returning the correct randomness as specified by the testing runtime.
- Integration tests on a lotus devent with a simple solidity contract that uses the precompile.
- Integration tests that validate that gas costs are as expected
- Integration tests that validate that very deep lookback has computational cost in proportion to the gas cost (linear).
- Integration tests that validate that requesting future randomness results in an error.
Inspecting early chain history can involve increasing computational cost. Client implementations with a computational cost that exceeds the gas charged for deep look-backs could face a denial-of-service attack.
This proposal has no impact on incentive considerations for the core Filecoin protocol.
Smart contracts using the new precompile will face gas costs that scale linearly with the depth of look-back. This incentive aligns users to query recent randomness stored in cached blocks, with less burden on the system.
Precompiles are a standard feature of the EVM that developers are familiar with.
The proposed precompile is specific to Filecoin.
Smart contracts that make use of it may not be portable to other EVM environments that don't provide historical randomness.
This proposal thus represents an additional capability that the FEVM environment can offer,
and one that is specifically useful for proofs of space and storage.
Draft PR: filecoin-project/builtin-actors#1577
Copyright and related rights waived via CC0.