-
Notifications
You must be signed in to change notification settings - Fork 744
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
Reduce gas/storage limits in nested calls #6890
base: master
Are you sure you want to change the base?
Conversation
376e944
to
4832380
Compare
Also, a limit of 0 when determining a nested call's metering limit would mean it was free to use all of the callee's resources. Now, a limit of 0 means that the nested call will have an empty storage meter.
In particular, this commit removes the usage of `0` as unlimited metering in the following tests: - `nonce` - `last_frame_output_works_on_instantiate` - `instantiation_from_contract` - `immutable_data_set_works_only_once` - `immutable_data_set_errors_with_empty_data` - `immutable_data_access_checks_work`
ed1f312
to
8e66f50
Compare
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.
The basic idea of the 63/64 rule looks correct to me but there are many failing tests. I left some nits.
substrate/frame/revive/src/gas.rs
Outdated
.min(self.gas_left); | ||
self.gas_left -= amount; | ||
GasMeter::new(amount) | ||
// The reduction to 63/64 is to emulate EIP-150 |
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.
This should be a doc-comment
debug_assert!(matches!(self.contract_state(), ContractState::Alive)); | ||
|
||
// Limit gas for nested call, per EIP-150. |
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.
This could go into the doc-comment (which is no no-longer correct I think)
This fixes, among other tests: * `tests::gas_consumed_is_linear_for_nested_calls` test * `tests::deposit_limit_in_nested_calls` * `tests::transient_storage_limit_in_call` * `tests::call_return_code` * `test::chain_extension_temp_storage_works` * `tests::origin_api_works` * `tests::read_only_call_works`
@xermicus the meters in |
Sorry if this wasn't clear: Only |
@athei Most of the previously failing tests were caused by the contract code of those tests using the now-removed '0 means "use all available gas"' semantic. After fixing this,
The contracts the above tests rely on have removed usages of 0 as "use all", so their failures are somewhere else. |
/bot fmt |
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.
Due to the changes here you can get rid of the fn enforce_subcall_limit()
and enum Nested
. They are no longer needed because we now always enforce the limit at the sub call boundry (calling fn enforce_limit
unconditionally).
Apart from a few other comments it looks pretty much like what I expect. Thanks.
substrate/frame/revive/src/gas.rs
Outdated
let amt = amount.min(self.gas_left - self.gas_left / 64); | ||
self.gas_left -= amt; |
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.
Please use amount
and not amt
. No need to introduce a less readable identifier when we can just shadow.
substrate/frame/revive/src/gas.rs
Outdated
#[test] | ||
/// Previously, passing a `Weight` of 0 to `nested` would consume all of the meter's current gas. | ||
/// | ||
/// Now, a `Weight` of 0 means no gas for the nested call. |
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.
#[test] | |
/// Previously, passing a `Weight` of 0 to `nested` would consume all of the meter's current gas. | |
/// | |
/// Now, a `Weight` of 0 means no gas for the nested call. | |
/// Previously, passing a `Weight` of 0 to `nested` would consume all of the meter's current gas. | |
/// | |
/// Now, a `Weight` of 0 means no gas for the nested call. | |
#[test] |
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.
Still some left over changes in the wrong pallet to roll back.
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 for pointing this out.
...us/parachains/integration-tests/emulated/tests/people/people-westend/src/tests/governance.rs
Outdated
Show resolved
Hide resolved
Weight::zero(), | ||
Weight::max_value(), | ||
storage_meter, | ||
BalanceOf::<T>::zero(), | ||
BalanceOf::<T>::max_value(), |
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.
The first frame is also created by nested
and will be limited to 63/64. We need to make sure the first one can use the full resources.
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.
We need to make sure the first one can use the full resources.
I did not understand this; may you elaborate on what exactly that would mean here?
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.
In the current code the overall transaction will be limited to 63/64. We don't want this. We only want sub calls to be limited. But not the first contract called by the externally owned account. That one should be allowed to use all the gas.
If I raze
? |
The type stating is still useful for other functions than Just remove the variants of |
All GitHub workflows were cancelled due to failure one of the required jobs. |
14 unit tests are still failing, among them these 2 tests fail because of a The remaining tests fail with
⬆️ is context in case you have any insights to share - the tests all failing for the same reason must be a clue to the underlying problem. I'll move fast so paritytech/revive#117 can continue. |
Closes #6846 .