Tighten length estimation during dry running#10540
Conversation
|
/cmd prdoc --audience runtime_dev --bump patch |
…time_dev --bump patch'
Differential Tests Results (PolkaVM)Specified Tests
Counts
FailuresThe test specifiers seen in this section have the format 'path::case_idx::compilation_mode' and they're compatible with the revive differential tests framework and can be specified to it directly in the same way that they're provided through the The failures are provided in an expandable section to ensure that the PR does not get polluted with information. Please click on the section below for more information Detailed Differential Tests Failure Information
|
Differential Tests Results (REVM)Specified Tests
Counts
FailuresThe test specifiers seen in this section have the format 'path::case_idx::compilation_mode' and they're compatible with the revive differential tests framework and can be specified to it directly in the same way that they're provided through the The failures are provided in an expandable section to ensure that the PR does not get polluted with information. Please click on the section below for more information Detailed Differential Tests Failure Information
|
The length of the RLP-encoded Ethereum transaction will have an effect on the transaction cost (as pallet-transaction-payment charges a length fee) and therefore the required Ethereum gas. During dry running we need to estimate the length of the actual RLP-encoded Ethereum transaction that will submitted later. Some of the parameters that determine the length will usually not be provided at the dry running stage yet: `gas`, `gas_price` and `max_priority_fee_per_gas`. If we underestimate the actual lengths of these parameters, then the gas estimate might be too low and transaction execution will run out of gas. If we over estimate, then the pre-dispatch weight will be unreasonably large and we risk that a transaction that might still fit into a block, won't be put into the block anymore, which leads to lower block utilization. ## Current Approach The current approach is to just assume that maximal possible length for these fields, which results when they have the maximum possible value, `U256::MAX`, due to how RLP encoding works. This is a gross over estimation. ## New Approach In practice there won't be gas requirements and gas estimates that are more than `u64::MAX` and therefore we assume this as the maximal value for `gas`. For `gas_price` and `max_priority_fee_per_gas` we assume that the caller will use the current base fee and will scale it be some small amount so that the RLP encoding is at most one byte longer than the RLP encoding of the base fee. We achieve that by determining the RLP encoding of the base fee multiplied by 256. --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Backport all pallet-revive related changes into `unstable2507`. These are all the changes we want to get onto the next Kusama release. Main changes include - EVM backend - Ethereum block storage - Generalized gas mapping The complete list of PRs in this backport is - #9482 - #9455 - #9454 - #9501 - #9177 - #9285 - #9606 - #9414 - #9557 - #9617 - #9385 - #9679 - #9705 - #9561 - #9744 - #9736 - #9701 - #9517 - #9771 - #9683 - #9791 - #9717 - #9759 - #9823 - #9768 - #9853 - #9801 - #9780 - #9796 - #9878 - #9841 - #9670 - #9865 - #9803 - #9928 - #9818 - #9911 - #9942 - #9831 - #9945 - #9603 - #9968 - #9939 - #9991 - #9914 - #9997 - #9985 - #10016 - #10027 - #10026 - #9418 - #9988 - #10041 - #10047 - #10032 - #10065 - #10089 - #10080 - #10090 - #10106 - #10020 - #9512 - #10109 - #9699 - #10100 - #9909 - #10120 - #10146 - #10157 - #10168 - #10169 - #10160 - #10129 - #10175 - #10186 - #10192 - #10148 - #10193 - #10220 - #10233 - #10191 - #10225 - #10246 - #10239 - #10159 - #10252 - #10224 - #10267 - #10271 - #10214 - #10297 - #10290 - #10281 - #10272 - #10303 - #10336 - #10244 - #10366 - #10380 - #10383 - #10387 - #10302 - #10309 - #10427 - #10385 - #10451 - #10471 - #10166 - #10510 - #10393 - #10540 - #9587 - #10071 - #10558 - #10554 - #10325 --------- Signed-off-by: xermicus <cyrill@parity.io> Co-authored-by: Pavlo Khrystenko <45178695+pkhry@users.noreply.github.com> Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Javier Viola <363911+pepoviola@users.noreply.github.com> Co-authored-by: Bastian Köcher <git@kchr.de> Co-authored-by: Bastian Köcher <info@kchr.de> Co-authored-by: pgherveou <pgherveou@gmail.com> Co-authored-by: Omar <OmarAbdulla7@hotmail.com> Co-authored-by: 0xRVE <robertvaneerdewijk@gmail.com> Co-authored-by: xermicus <cyrill@parity.io> Co-authored-by: Alexander Samusev <41779041+alvicsam@users.noreply.github.com>
The length of the RLP-encoded Ethereum transaction will have an effect on the transaction cost (as pallet-transaction-payment charges a length fee) and therefore the required Ethereum gas.
During dry running we need to estimate the length of the actual RLP-encoded Ethereum transaction that will submitted later. Some of the parameters that determine the length will usually not be provided at the dry running stage yet:
gas,gas_priceandmax_priority_fee_per_gas.If we underestimate the actual lengths of these parameters, then the gas estimate might be too low and transaction execution will run out of gas. If we over estimate, then the pre-dispatch weight will be unreasonably large and we risk that a transaction that might still fit into a block, won't be put into the block anymore, which leads to lower block utilization.
Current Approach
The current approach is to just assume that maximal possible length for these fields, which results when they have the maximum possible value,
U256::MAX, due to how RLP encoding works. This is a gross over estimation.New Approach
In practice there won't be gas requirements and gas estimates that are more than
u64::MAXand therefore we assume this as the maximal value forgas.For
gas_priceandmax_priority_fee_per_gaswe assume that the caller will use the current base fee and will scale it be some small amount so that the RLP encoding is at most one byte longer than the RLP encoding of the base fee. We achieve that by determining the RLP encoding of the base fee multiplied by 256.