This repository has been archived by the owner on Aug 14, 2023. It is now read-only.
Fixed-Gas CFG #237
Merged
Fixed-Gas CFG #237
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
Implemented the `svm_allocate` host function. adding some debugging printing to the new `svm_allocate` host function. WIP: computing the `returns` byte-size for a function (sdk-macros) * `calldata` is allocated on instance only when non-empty. The `svm-sdk` relies on the host function for Wasm targeted code and on the default global allocator otherwise. adding `svm_sdk_std::panic` (aborts for Wasm and unwinds otherwise) WIP: adding an explicit feature flag for the host static allocation. svm-codec is using the default global-alloactor (not the "static allocation") codec - js tests pass (commenting the `verify_data` for now) tests pass CI - running only on Windows + running the tests 10 times (there seems to be a sporadic failures) CI - skipping the build stage svm-sdk-std: exposing Rust `Vec` svm-sdk-std: using `panic!` running only the `svm-runtime` crate tests. Removing `wabt` (using only `wat`) - it takes much less time to build. using cache action v2 Adding GitHub Action for LLVM Adding caching to the llvm LLVM 10 Returning back the original LLVM action for Windows adding feature-flags `default-cranelift` and `default-llvm` trying to run CI against `llvm` running tests with a single thread runtime - removing two ignored tests related to gas-metering Commenting a test runtime: ignoring all tests except one running tests in dev-mode Building on Linux and macOS svm-sdk-std: returning back Rust `Vec` Commenting part of the problematic test Commenting another part of the problematic test uncomment part of the problematic test cbindgen version bump problemtic test - wasm input file "runtime_calldata.wasm" isn't using the "static-alloc" problemtic test: input wasm is being compiled with less code and no `.cargo/config` file Uncommenting all the problematic test Trying to locate the bug Trying again to pinpoint the bug Adding asserts against setting explicitly empty `returndata` WIP: debugging WIP: debugging... WIP: debugging... skipping the last CI stages for now... WIP: trying to locate the cause of the bug... WIP commenting the "static-alloc" related code from `svm-sdk-alloc` WIP Trying again to make the test fail Trying to figure out whether the #[endpoint] return-type has anything to do with the bug... Commenting "Storage" from the wasm input of the failing test... More debugging the root cause of the problem debugging... adding "Cache workspace" step Splitting cargo caching into isloated steps. adding "Dump GitHub context" step. CI: changing to `crates/runtime` before running the tests Try again to run CI... Try again CI: disabling LLVM installation for now (Windows) Trying again to reproduce a broken CI on Windows... Checking whether the bug has something to do with `svm_sdk::Address` Trying to find a minimal failing input using `Amount` WIP: Debugging... WIP: removing the parameter from the problematic endpoint This should pass (not using `endpoint`) This should fail again... `ExtHost#get_calldata` - returning a static data Re-compile the wasm input Empty `endpoint` prologue. debugging debugging... Trying to narrow the bug WIP Narrowing the epilogue part should fail... Uncommenting part of the epilogue WIP
… the endpoint's macro.
Closed
YaronWittenstein
force-pushed
the
fixed-gas-cfg
branch
8 times, most recently
from
88d99cd
to
11104df
Compare
YaronWittenstein
force-pushed
the
fixed-gas-cfg
branch
3 times, most recently
from
1e5cd98
to
8de4e95
Compare
YaronWittenstein
force-pushed
the
fixed-gas-cfg
branch
from
fded416
to
eaba3ac
Compare
moshababo
approved these changes
Jun 6, 2021
Merged
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Motivation
Prior to executing a transaction, we should be able to tell what its price will be in terms of gas units. (for now, we only deal with fixed-gas Wasm apps under SVM).
In the future, we could extend the gas pricing to support metering. (and consequently also not only fixed-gas Wasm code)
Since we only deal with fixed-gas Wasm programs for now - we compute the gas costs offline before actually executing the transaction.
Even though the internals of SVM will infer a Gas minimum and maximum range to be paid, in practice the maximum gas units will be charged off the
sender.In case a transaction has not enough gas (i.e the
gas limitis too small) the transaction should be discarded.(it won't be part of a block and won't get a chance to execute at all).
In order to compute the price of a transaction we first need to be able to tell the price of a function. (Wasm function).
So, after making sure we have no
loopneithercall cyclesin theCall-Graph(this is done as part of thevalidationphase when deploying a template) - we can proceed to price-per-function computation.This PR lays the foundations for achieving that. Given a Wasm function, it constructs in one scan a corresponding CFG (see Control-Flow Graph) that simulates different execution paths of a function.
The Function CFG building algorithm is documented here:
https://github.com/spacemeshos/svm/blob/fixed-gas-cfg/crates/gas/src/cfg/mod.rs
Being able to construct the function CFG in a single pass is crucial since it adds security. Otherwise, an attacker would try to generate valid fixed-gas Wasm inputs that would try to take advantage of that.
A next PR will implement the actual pricing part - it will consume functions CFGs one-by-one and compute the price for different paths within a function. In the end, it will be able to report the minimum and maximum prices for the function CFG.
Again - it could be done since the CFG of a fixed-gas Wasm function contains no loops/call-cycles.