-
Notifications
You must be signed in to change notification settings - Fork 170
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
2 changed files
with
165 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,164 @@ | ||
| --- | ||
| fip: "<to be assigned>" <!--keep the qoutes around the fip number, i.e: `fip: "0001"`--> | ||
| title: Improvements to the FVM randomness syscalls | ||
| author: "Aayush Rajasekaran (@arajasek), Steven Allen (@stebalien)" | ||
| discussions-to: https://github.com/filecoin-project/FIPs/discussions/790, https://github.com/filecoin-project/FIPs/discussions/791 | ||
| status: Draft | ||
| type: Technical (Core) | ||
| category: Core | ||
| created: <2023-28-28> | ||
| --- | ||
|
|
||
| <!--You can leave these HTML comments in your merged FIP and delete the visible duplicate text guides, they will not appear and may be helpful to refer to if you edit it again. This is the suggested template for new FIPs. Note that a FIP number will be assigned by an editor. When opening a pull request to submit your FIP, please use an abbreviated title in the filename, `fip-draft_title_abbrev.md`. The title should be 44 characters or less.--> | ||
|
|
||
| ## Simple Summary | ||
| <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.--> | ||
|
|
||
| This FIP: | ||
|
|
||
| 1. Changes the FVM syscalls that fetch randomness to no longer mix-in user provided "entropy", actors must now do so themselves. | ||
| 2. Changes the gas costs of the FVM syscalls that fetch randomness and tipset CIDs to be proportional to the lookback distance. | ||
|
|
||
| ## Abstract | ||
| <!--A short (~200 word) description of the technical issue being addressed.--> | ||
|
|
||
| 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: | ||
| 1. moving the hashing operation out of the FVM/client, and into the calling actor | ||
| 1. 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. | ||
|
|
||
| ## Change Motivation | ||
| <!--The motivation is critical for FIPs that want to change the Filecoin protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the FIP solves. FIP submissions without sufficient motivation may be rejected outright.--> | ||
|
|
||
| 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. | ||
|
|
||
| ## Specification | ||
| <!--The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Filecoin implementations. --> | ||
|
|
||
| ### Interfaces | ||
|
|
||
| We propose the following changes to the FVM syscalls: | ||
| - change the `get_chain_randomness` syscall from `get_chain_randomness(dst: i64, round: ChainEpoch, entropy: &[u8],)` to `get_chain_randomness(round: ChainEpoch)` | ||
| - change the `get_beacon_randomness` syscall from `get_beacon_randomness(dst: i64, round: ChainEpoch, entropy: &[u8],)` to `get_beacon_randomness(round: ChainEpoch)` | ||
|
|
||
| The same breaking change should also be made to the `Externs` interface, and all client implementations of this interface. | ||
|
|
||
| ### Actor changes | ||
|
|
||
| The implementation of the `Runtime` interface for the FVM has to change to: | ||
| - no longer supply the `dst` and `entropy` 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`, and `entropy` params | ||
|
|
||
| The randomness drawing operation looks like this: | ||
|
|
||
| ``` | ||
| pub fn draw_randomness( | ||
| rbase: &[u8; RANDOMNESS_LENGTH], | ||
| pers: DomainSeparationTag, | ||
| round: ChainEpoch, | ||
| entropy: &[u8], | ||
| ) -> [u8; RANDOMNESS_LENGTH] { | ||
| let mut data = Vec::with_capacity(RANDOMNESS_LENGTH + 8 + 8 + entropy.len()); | ||
| // Append the personalization value | ||
| let i64_bytes = (pers as i64).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) | ||
| } | ||
| ``` | ||
|
|
||
| ### Client changes | ||
|
|
||
| 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. | ||
|
|
||
| ### Gas Pricing | ||
|
|
||
| We change the gas pricing for both `get_randomness` operations, as well as the `get_tipset_cid` operation, to be proportional to the lookback distance. | ||
|
|
||
| We charge `75 * lookback + 5800 * 19` for the lookback cost, where `lookback` is equal to the difference between the current epoch, and the requested epoch. | ||
| We additionally charge `15000` for the offset (the cost of producing the randomness/tipset CID itself), and `21000` for the extern cost. | ||
|
|
||
| The total gas formula is thus: `75 * lookback + 110200 + 15000 + 21000`. | ||
|
|
||
| ## Design Rationale | ||
| <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> | ||
|
|
||
| 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](https://github.com/filecoin-project/FIPs/blob/master/FIPS/fip-0054.md#tipset-cid-gas). | ||
|
|
||
| 1. We apply a cost of 1500/20 = 75 gas per epoch | ||
| 1. We apply an additional cost of 5800*19 = 110200 for tipset traversal after the skipping | ||
| 1. We apply a flat cost of 15000 for the overhead work (serializing, hashing, etc.), and 21000 as the flat extern gas cost | ||
|
|
||
| This yields the specified formula of `75 * lookback + 110200 + 15000 + 21000`. | ||
|
|
||
| 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. | ||
|
|
||
| ## Backwards Compatibility | ||
| <!--All FIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The FIP must explain how the author proposes to deal with these incompatibilities. FIP submissions without a sufficient backwards compatibility treatise may be rejected outright.--> | ||
|
|
||
| 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 | ||
|
|
||
| ## Test Cases | ||
| <!--Test cases for an implementation are mandatory for FIPs that are affecting consensus changes. Other FIPs can choose to include links to test cases if applicable.--> | ||
|
|
||
| TODO | ||
|
|
||
| ## Security Considerations | ||
| <!--All FIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. FIP submissions missing the "Security Considerations" section will be rejected. A FIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.--> | ||
|
|
||
| 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. | ||
|
|
||
| ## Incentive Considerations | ||
| <!--All FIPs must contain a section that discusses the incentive implications/considerations relative to the proposed change. Include information that might be important for incentive discussion. A discussion on how the proposed change will incentivize reliable and useful storage is required. FIP submissions missing the "Incentive Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Incentive Considerations discussion deemed sufficient by the reviewers.--> | ||
|
|
||
| This FIP does not materially impact incentives in any way. | ||
|
|
||
| ## Product Considerations | ||
| <!--All FIPs must contain a section that discusses the product implications/considerations relative to the proposed change. Include information that might be important for product discussion. A discussion on how the proposed change will enable better storage-related goods and services to be developed on Filecoin. FIP submissions missing the "Product Considerations" section will be rejected. An FIP cannot proceed to status "Final" without a Product Considerations discussion deemed sufficient by the reviewers.--> | ||
|
|
||
| This FIP does not materially impact the product in any way. | ||
|
|
||
| ## Implementation | ||
| <!--The implementations must be completed before any core FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> | ||
|
|
||
| TODO | ||
|
|
||
| ## TODO | ||
| <!--A section that lists any unresolved issues or tasks that are part of the FIP proposal. Examples of these include performing benchmarking to know gas fees, validate claims made in the FIP once the final implementation is ready, etc. A FIP can only move to a “Last Call” status once all these items have been resolved.--> | ||
|
|
||
| None. | ||
|
|
||
| ## Copyright | ||
| Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters