TOB-FUEL-38: SRWQ instruction is priced inadequately

[xgreenx]

Description

Using the technique outlined in appendix F we identified several instructions which might not be priced adequately.
One result from this evaluation is that the SRWQ instruction charges gas dependent on the parameter D, though it seems like its consumption is inadequate with respect to the execution time of this instruction. The default cost for it is right now a dependent cost with base 54 and dependent cost per unit of 2.
The SRWQ instruction contains an expensive call to merkle_contract_state_insert_range, which might be inadequately priced. The following figure contains a base64 encoded program which uses the SRWQ function and executes for several seconds.

Figure 38.1: Base64 program which uses SRWQ and consumes relatively high CPU time.

kAAABEcAAAoaMwAAGkQAADND8AAWQRQAc0AAFxBBNIAlP+wAEEUQQBtD8AHnQUwBE0EAUClAAGEQSSRAVgAA
EkQGAlr////////IyMjICQAAAAD1AAAAAAAAAYQV/MABEP/zAGFBARQtQUlJSUlJSUlJ4JAAAEHgkAAABEcA
AAAArb7vVWbOqgCtvu9VZs6qGuxQAJEABrhdQ+gREEEDAF1X8BI7OzsvO/9/Ozs7Ozs7S/AUEEkjOXJMMSAp
TAQgEE+0wHJQACA5TRXwUEkACHJMAMAQT7TAclAAIEtNFfBQUAAgOU0V8FBJAAhyTABAKkkUwFAgG1BgAKio
qBBRNQByVAAgKFEFQJBQACAbUBUA

Note that this is a result of a quantitative analysis and that more benchmarking is required to validate whether the gas consumption of SRWQ is inadequate or not.

Exploit Scenario

An attacker deploys a contract which heavily uses the SRWQ instruction. With very little gas consumption the attack can put a lot of stress on the network. Depending on how much gas the attacker invests the whole network could be blocked.

Recommendations

Short term, evaluate a better value for the dependent cost of SRWQ.
Long term, reevaluate the execution time of programs using a corpus obtained through fuzzing.

[xgreenx]

SRWQ only has the merkle_contract_state_range call inside. So maybe the report is related to another opcode. Or something is wrong with description of the issue for SRWQ. We need to investigate the problem during FuelLabs/fuel-core#1306. Maybe it will be fixed by FuelLabs/fuel-core#1239.

[xgreenx]

The issue is fixed with updated benchmarks FuelLabs/fuel-core#1427.

BTW, we plan to limit sequential opcodes with upper bound #611.