fix(Validium): Fix broken integration test

[SantiagoPittella]

Related to: #107

To be correctly compatible with legacy transactions, the effective gas calculation should change and follow the specification in:
https://eips.ethereum.org/EIPS/eip-1559

What ❔

• Updates an integration test to expect a lower or equal gas price instead of an equal gas price

Why ❔

• A test that checks the gas price of a transaction (sent vs received in the receipt) was failing in Validium mode.

Checklist

• PR title corresponds to the body of PR (we generate changelog entries from PRs).
• Tests for the changes have been added / updated.
• Documentation comments have been added / updated.
• Code has been formatted via zk fmt and zk lint.
• Spellcheck has been run via zk spellcheck.
• Linkcheck has been run via zk linkcheck.

[ilitteri]

I dove deeper into this, I think this fix could not necessarily be correct even if it makes the test pass.

For Validium we're setting compute_overhead_part to 1.0 as it is suggested here. This affects the fair_l2_gas_price computation as now we're adding gas_overhead_wei to it (if I remove that variable from the sum, the test passes).

With the above context, now focusing on the test itself, after discarding that this is exclusively a Legacy Tx issue (comment the line that overrides the type and run the test to see this), I concluded that there's an incompatibility between the gasPrice from the transaction being sent and the transaction retrieved by the Web3 API. The endpoint gets the transaction from the database implying that the transaction being sent is not exactly the same as the one stored in the database.

Do you have any idea of what could be happening here? Should we ignore this test in Validium? @popzxc @perekopskiy @StanislavBreadless

[StanislavBreadless]

@ilitteri The reason for that is since eth_getGasPrice will return not exact gas price now, but rather a one with a multiplier (to account for the fact that the L1 gas price may rise in the near term), the gasPrice which is sent by your tx in the test is necessarily larger than the effective one (i.e. the actual one that did not have the multiplier).

My recommendation would be probably to remove the multiplier from the eth_getGasPrice estimation (at a risk having users sending txs that get temporarily stuck in the mempool in case of spikes) or, alternatively amend the test to allow gas price to be <= to the one provided in the tx. We do ignore priority fee and it is a common practice among L2s.

[ilitteri]

@ilitteri The reason for that is since eth_getGasPrice will return not exact gas price now, but rather a one with a multiplier (to account for the fact that the L1 gas price may rise in the near term), the gasPrice which is sent by your tx in the test is necessarily larger than the effective one (i.e. the actual one that did not have the multiplier).

My recommendation would be probably to remove the multiplier from the eth_getGasPrice estimation (at a risk having users sending txs that get temporarily stuck in the mempool in case of spikes) or, alternatively amend the test to allow gas price to be <= to the one provided in the tx. We do ignore priority fee and it is a common practice among L2s.

Thanks for the explanation! We've proceeded on updating the test so the expected gasPrice is lower or equal to the tx's

[ilitteri]

@popzxc if this new change is ok, I think we're done here (the linter and unit-tests are fixed in #1312)