-
Notifications
You must be signed in to change notification settings - Fork 431
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
Different gas value for weight_to_fee()
in ink! integration and e2e tests
#1985
Comments
Regarding the observation you made: The 0 is intentional, as the comment indicates, "Equivalent to the newer [seal1][super::api_doc::Version2::weight_to_fee] version but works with ref_time Weight only." (proof_size is set to 0). |
The code responsible for the function always returning 0:
|
It has been reported an issue (use-ink/ink#1985) that weight_to_fee always returns zero in end-to-end tests. This pull request adds `type FeeMultiplierUpdate = SlowAdjustingFeeUpdate<Self>` to make it work.
@arturoBeccar, please advise if it works for you, and can we close the issue? |
Hi @smiasojed, recompiling the node on commit #[ink(message)]
pub fn weight_to_fee(&self, gas: u64) -> Balance {
self.env().weight_to_fee(gas)
} We still obtain 0 with any gas number in e2e. Any idea on why this is happening? |
Hi @arturoBeccar,
|
Hi @smiasojed. I tried the suggested steps and it worked correctly. I confirm the issue is now resolved in PR #219 to substrate-contract-node and can be closed. Thanks! |
It has been reported an issue (use-ink/ink#1985) that weight_to_fee always returns zero in end-to-end tests. This pull request adds `type FeeMultiplierUpdate = SlowAdjustingFeeUpdate<Self>` to make it work.
Different gas value for
weight_to_fee()
in ink! integration and e2e testsOn our research into integration and end-to-end function implementation differences, we stumbled upon
weight_to_fee()
not working as expected. Both Integration and E2E environments return a valid gas price (u128
) for a given gas amount. However, the price per gas unit differs in both environments: it is 100 in integration tests and always 0 in E2E tests.Adding to the test-case and documentation we built for analyzing this issue, we explain below the problem, we describe the work we have undertaken to try to identify its source, and propose next steps for resolving it.
The problem
Given a basic contract with this message
When we call the function weight_to_fee() from an integration test we see that the fee for 1 unit of gas is 100.
When we call the function weight_to_fee() from an end-to-end test, we see that the fee for 1 unit of gas is 0.
This behavior is seen in the local development node too, but not in testnets like Aleph Zero testnet.
Looking at the runtime in
polkadot-sdk
, we found a few implementations of the functions, but modifying them didn't change the outcome of the tests as predicted.The functions that we modified to check if something changed were:
polkadot-sdk/substrate/frame/contracts/src/exec.rs
, theget_weight_price()
function.polkadot-sdk/substrate/frame/transaction-payment/src/lib.rs
, theconvert()
function.polkadot-sdk/substrate/frame/system/src/limits.rs
, themax_block: Weight::zero()
inside thebuilder()
function seems to affect at least thepolkadot-sdk/substrate/frame/transaction-payment/src/lib.rs
functionweight_to_fee()
:This seems to be always zero, as the
max_block
field is zero.Observations
In
polkadot-sdk/substrate/frame/contracts/src/wasm/runtime.rs
, there are 2 functions:Where the first one has a hardcoded zero. Is that intentional as "working as intended", or is that a workaround for something else?
Next Steps
We propose to make the following changes to
weight_to_fee()
in ink! e2e tests. Before doing that, we need assistance in identifying all the files relevant to its implementation. Particularly, to identify which code is responible for the function always returning 0.env().setGasPrice(...)
to set the value in the tests (with a default value).Any of this decisions should be properly documented.
The text was updated successfully, but these errors were encountered: