-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIP-0057: Update gas charging schedule and system limits for FEVM #573
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does "full user programmability" mean "native actors" here? IIUC we should add it as an issue to M2.2 release, right?
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. This looks ok to me as a first draft. However I think the Product Considerations is currently underdone until it includes indicative numbers for the changing costs of core network operations on the built-in actors.
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.