Some parts of our code that deal with Ethereum gas units use U256 to represent the gas amounts.
It seems that in practice all gas amounts fit into u64 (and tooling sometimes even assumes that). For that reason we can optimize and use the type u64 instead.
See paritytech/polkadot-sdk#10166 (comment):
We just need to ensure that the serde encoding use hex string if we use a plain u64 in a type that is used by the ETH json-rpc
Random Thoughts
Not all computation done in substrate/frame/revive/src/metering/math.rs should be done in u64. At least whenever we go from gas to storage deposits, we should switch to u128. But that data type switch should be contained in the functions from_adjusted_deposit_charge and to_adjusted_deposit_charge of SignedGas.
This requires some more careful analysis.
Another thought: we might be able to set the gas related parameters in maximized_tx (see here) to less extreme values (e.g., Some(u64::MAX) instead of Some(U256::MAX)) to not overextend and overestimate the length that much.
Some parts of our code that deal with Ethereum gas units use
U256to represent the gas amounts.It seems that in practice all gas amounts fit into
u64(and tooling sometimes even assumes that). For that reason we can optimize and use the typeu64instead.See paritytech/polkadot-sdk#10166 (comment):
Random Thoughts
Not all computation done in
substrate/frame/revive/src/metering/math.rsshould be done inu64. At least whenever we go from gas to storage deposits, we should switch tou128. But that data type switch should be contained in the functionsfrom_adjusted_deposit_chargeandto_adjusted_deposit_chargeofSignedGas.This requires some more careful analysis.
Another thought: we might be able to set the gas related parameters in
maximized_tx(see here) to less extreme values (e.g.,Some(u64::MAX)instead ofSome(U256::MAX)) to not overextend and overestimate the length that much.