fip | title | author | discussions-to | status | type | category | created |
---|---|---|---|---|---|---|---|
0075 |
Improvements to the FVM randomness syscalls |
Aayush Rajasekaran (@arajasek), Steven Allen (@stebalien) |
Final |
Technical (Core) |
Core |
2023-08-28 |
This FIP:
- Changes the FVM syscalls that fetch randomness to no longer mix-in user provided "entropy", actors must now do so themselves.
- Changes the gas costs of the FVM syscalls that fetch randomness and tipset CIDs to be proportional to the lookback distance.
Contracts can today request randomness from the FVM, which forwards the request to the client. The client looks up the randomness from the chain (with no lookback limit), hashes it to "draw" the requested value, and returns it.
This FIP proposes:
- moving the hashing operation out of the FVM/client, and into the calling actor
- formalizing that no lookback limit is enforced on randomness and tipset CID fetching, and modifying the gas pricing to be linear with the lookback range.
The fact that fetching randomness and tipset CID today isn't priced proportional to the lookback is a security risk. This isn't a major issue today since only trusted code (the builtin actors) can request unbounded lookbacks. However, we still want to fix this in order to more accurately charge for costs, and future-proof this operation against both changes to the builtin actors and user-deployed "native" actors.
The motivation to push the hashing operation into user-space is that the FVM already has a syscall that supports hashing. As a result, the FVM doesn't need to be performing this hashing for the client, and we can allow users (actors) to "draw" their randomness as they please.
We propose the following changes to the FVM syscalls:
- change the
get_chain_randomness
syscall fromget_chain_randomness(dst: i64, round: ChainEpoch, entropy: &[u8],)
toget_chain_randomness(round: ChainEpoch)
- change the
get_beacon_randomness
syscall fromget_beacon_randomness(dst: i64, round: ChainEpoch, entropy: &[u8],)
toget_beacon_randomness(round: ChainEpoch)
The same breaking change should also be made to the Externs
interface, and all client implementations of this interface.
The implementation of the Runtime
interface for the FVM has to change to:
- no longer supply the
dst
andentropy
params when calling into the FVM SDK - "draw" randomness for the calling actor, by hashing the randomness returned by the FVM with the
dst
,round
, andentropy
params
The randomness drawing operation looks like this:
pub fn draw_randomness(
rbase: &[u8; 32],
pers: i64,
round: i64,
entropy: &[u8],
) -> [u8; 32] {
let mut data = Vec::with_capacity(32 + 8 + 8 + entropy.len());
// Append the personalization value
let i64_bytes = pers.to_be_bytes();
data.extend_from_slice(&i64_bytes);
// Append the randomness
data.extend_from_slice(rbase);
// Append the round
let i64_bytes = round.to_be_bytes();
data.extend_from_slice(&i64_bytes);
// Append the entropy
data.extend_from_slice(entropy);
// Ask the FVM to now hash this data
fvm::crypto::hash_blake2b(&data)
}
Clients no longer receive the dst
and entropy
parameters for the randomness Extern methods, and should skip the final step of "drawing" randomness in which this DST and entropy is mixed into the hash.
We also seek consensus amongst Core Devs that Filecoin clients are expected to be able to support chain walkbacks all the way to genesis, with a performance no worse than that based on a skiplist of length 20. Clients are free to be more performant (eg. constant-time). Clients can also be less performant, but the gas pricing would not be accurate for such clients.
The gas pricing for both get_randomness
operations, as well as the get_tipset_cid
operation, is set proportional to lookback
(the difference between the current epoch, and the requested epoch).
These operations cost 75 * lookback + 146200
.
The hashing change is designed to follow the principle of "anything that doesn't have to be done in the FVM shouldn't be done in the FVM". Following this principle makes it easier to version changes, avoids explicit specialized gas charges, and reduces the risk of critical security issues.
The gas changes for the lookback are designed to correctly price operations based on clients as they exist today, which is important for security. We change the randomness gas pricing to be similar to the Tipset CID gas pricing in in line with prior work in FIP-0054.
- We apply a cost of 1500/20 = 75 gas per epoch
- We apply an additional cost of 5800*19 = 110200 for tipset traversal after the skipping
- We apply a flat cost of 15000 for the overhead work (serializing, hashing, etc.), and 21000 as the flat extern gas cost
Adding this up yields the specified formula of 75 * lookback + 146200
.
While we could simplify and reduce the cost to be a single constant, doing so requires all Filecoin client implementations to support constant-time lookback, which is not currently a priority.
We are also simplifying the gas pricing for fetching Tipset CIDs in this FIP. While FIP-0054 special-cased fetching the tipset CID at the current epoch, we are dropping that special-casing. This makes fetching the tipset CID at the current epoch slightly more expensive, but simplifies the logic, and allows us to unify the gas pricing for fetching randomness and fetching tipset CIDs.
These changes are backwards incompatible, and require a network upgrade. Further, clients must:
- modify their support of the FVM extern to no longer receive Domain Separation Tags and entropy as inputs
- no longer hash the returned value
TODO
This FIP is an overall improvement to security:
- it accurately charges for chain walkback operations. This ensures that contracts that force large chain walkbacks (whether due to bugs or malicious intent) cannot slow down state computation for free.
- by pushing the randomness hashing into userspace, it reduces the risky critical path. Any bugs in that logic will now be a problem for the contract, not the system itself.
These changes are especially important if we plan to support native WASM actors.
This FIP does not materially impact incentives in any way.
This FIP does not materially impact the product in any way.
TODO
None.
Copyright and related rights waived via CC0.