FIP-0057: Update gas charging schedule and system limits for FEVM #573
Conversation
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
Co-authored-by: Steven Allen <[email protected]>
|
@Stebalien has been working extensively in this area and he's the best person to take this FIP to completion. |
FIPS/fip-nnnn-fevm-gas.md
Outdated
| 4. Sequences of predefined Wasm instructions backing FEVM opcode handlers. | ||
| 5. Memory allocation. | ||
|
|
||
| We propose gas charges and system limits to Currently, there is a fixed fee but no per-byte charge for hashing, memory copies, fills, etc. Furthermore, all Wasm instructions are priced through execution gas at a flat rate of 4 gas/op with the exception of some control flow instructions. However, recent observations suggest that some incur in no CPU cost, so we propose new gas exemptions for higher accuracy. |
There was a problem hiding this comment.
Part of the sequence after "system limits to" is missing.
FIPS/fip-nnnn-fevm-gas.md
Outdated
|
|
||
| #### No-Ops | ||
|
|
||
| Costs have been removed from some operations that would have little to no cost on a traditional CPU. These rules are _valid_ under FEVM because the user cannot trigger _specific_ sequences of WebAssembly instructions but must be revisited before introducing full user programmability as some pathologically unoptimized programs may be able to find a way to make these instructions actually take time. |
There was a problem hiding this comment.
Does "full user programmability" mean "native actors" here? IIUC we should add it as an issue to M2.2 release, right?
Stebalien
requested review from
momack2,
arajasek,
jennijuju,
kaitlin-beegle and
anorth
as code owners
|
Can we please have a discussion link? There are technical impact things to discuss here, including impact on built-in actors and core network operations. |
|
@anorth done. |
anorth
reviewed
Jan 13, 2023
luckyparadise
added
PR Submitted
raulk
changed the title
jennijuju
approved these changes
Jan 23, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Discussions: #588
With the introduction of user programmable smart contracts, we need to ensure that the gas model accurately reflects the cost of on-chain computation. In the current network, users can only trigger course-grained behaviors by submitting messages to built-in actors. However, with the introduction of FEVM, users will be able to deploy new smart contracts with fine-grained control over FVM execution. If we don't carefully tune the gas model to accurately charge for computation, an attacker could carefully construct a contract to take advantage that and slow down or even stop chain validation.
This FIP proposes a few adjustments to the gas charging schedule. Specifically:
This FIP also introduces overall memory limits. However, these memory limits currently only include Wasm memories and table elements (not IPLD blocks, wasm code, and other metadata).
Additionally, this FIP introduces a maximum block size limit of 1MiB for all newly created IPLD blocks.
Finally, this FIP reduces the maximum recursive call depth limit from 1025 to 1024 to bring it in-line with the initial intentions of this limit and other blockchain VMs.