This repository has been archived by the owner on Nov 6, 2020. It is now read-only.
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.
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.
It would be great to document (and/or add a test for it) what happens in case of an overflow with this change. It fixes the panic, but is the new non-panicky behaviour legal?
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.
I added more docs on how execute_as_system function actually works. I think this is mostly a definition issue -- system transactions are not normal transactions after all.
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.
@sorpaas talking further about this with @ascjones we were wondering what the reason is this method accepts a
gas
param at all: as the system calls are "special" and can use however much gas they want, then perhaps this line could just becomeenv_info.gas_limit = U256::max_value()
?cc @andresilva
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.
It does make sense. Sometimes we want to limit the gas can be used by system transactions. Like BLOCKHASH contract (https://eips.ethereum.org/EIPS/eip-210).
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.
@dvdplm It's typically used for consensus-level transactions, e.g. finalizing changes to
ValidatorSet
, block reward contract transactions. In these cases we don't really need to cap the execution using gas since we assume the contracts are well behaved. Although we do provideU256::max_value()
in most cases, for EIP210 we set the gas limit defined in the spec. So I think we should keep thegas
parameter and don't assume it will always beU256::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.
@sorpaas @andresilva ok, I'll trust you on that. I am still not sure I fully understand what happens when the addition overflows though: wouldn't that risk making the
gas_limit
way too low causing execution to halt unexpectedly?Again, thank you for taking the time to explain things! :)
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.
Isn't that what the change to
saturating_add
in this PR is for?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.
@ascjones you are right ofc, I was totally confused about what
saturating_add
actually does. I thought it wrapped around but of course it doesn't. My bad, please ignore me.