[pallet-revive] ETH blocks/tx receipts mismatch in terms of base_fee_per_gas/effective_gas_price

[iulianbarbu]

The mismatch is based on:

1. assethub runtime has usually pallet_transaction_payment configured with an index before pallet_revive, and on_finalize hooks are executed ordered by index.
2. an eth block is committed to storage in pallet_revive on_finalize hook.
3. in pallet-revive's on_finalize, to build the eth block we read pallet-transaction-payment's NextFeeMultiplier from storage, when setting its base_fee_per_gas.
4. before 3. (as mentioned in 1.), pallet-transaction-payment's on_finalize is called, which updates the NextFeeMultiplier value, which will be relevant for the transactions included in the next block.
5. when 3. ends, the current eth block base_fee_per_gas will point to a NextFeeMultiplier which is not relevant for the eth block, but for the next eth block.

TL;DR each eth block's base_fee_per_gas points to the NextFeeMultipier considered in the fees calculations for the transactions in the next substrate/eth block, not the transactions of the current block. This is something different than how anvil/eth blocks are built after EIP1559.

LE: related problem #10177 (comment) fixed by #10148

cc @pgherveou @athei

[athei]

Maybe fixed by #10148

[TorstenStueber]

Yes, will be fixed by #10148

[alindima]

Yes, will be fixed by #10148

AFAICT, this PR fixes the gas returned in the transaction receipt. This issue is about the gas returned in the ethereum block itself. I don't see how the PR fixes this, could you explain?

[iulianbarbu]

On last friday during some tests I also observed that the receipts effective_gas_price is based on the base_fee at the block in which the tx was included, which make the receipts effective gas price incorrect too. Relevant code path: [1] -> [2], which calls eventually [3], which at a given block points to the NextFeeMultiplier used in the fees computation for the next block.

I believe fixing the initial reported issue should fix the receipts too. I also think #10148 doesn't focus on this, but let us know if it plans to address all reported mismatches around gas/base_fee.

[athei]

I am not sure if I understand this issue. Are you saying NextFeeMultiplier should not be used for the base_fee of the current block but for the next? If yes that is probably a confusion on your side. If you check pallet_transaction_payment you will see that indeed the current value will be used to calculate the fees of the current block. As a matter of fact the runtime itself cannot read historical values.

And yes, the name of the storage value is confusing.

[iulianbarbu]

Are you saying NextFeeMultiplier should not be used for the base_fee of the current block but for the next?

No. I am saying that NextFeeMultiplier that's referenced in the base_fee_per_gas of an eth block is not the one used to calculate fees for the corresponding substrate block (it is the one that will be used to calculate fees in the next substrate block). And the same issue for the receipts.

[athei]

i.e we are reporting base_price_of_block(n+1) in block n?

[alindima]

i.e we are reporting base_price_of_block(n+1) in block n?

yes. right @iulianbarbu ?

[iulianbarbu]

i.e we are reporting base_price_of_block(n+1) in block n?

precisely. The reason is described in the issue description.

[pgherveou]

so the (hacky) fix is to give revive an index lower than the transaction_payment pallet?