Closed brendene closed 1 year ago
Do you know if this is only happening on the post merge (7.7.0+) releases?
Do you know if this is only happening on the post merge (7.7.0+) releases?
I see this happening in pre merge releases as well (ex. 7.6.0)
I've looked into this a bit, and it seems that we have a discrepancy for the gas price between the result of eth_getTransactionByHash
and eth_getTransactionReceipt
. The transaction's gasPrice
field differs from the receipt's effectiveGasPrice
field. The receipt's effectiveGasPrice
is the correct value, and is what is actually used at the VM level to update account balances, so that's good.
However, we're returning the wrong gasPrice
when you fetch the transaction via eth_getTransactionByHash
. This is happening because when we save the transaction to the chain, we don't update the transaction's effectiveGasPrice
field based off of the baseFeePerGas
of the block that the transaction was mined onto. Instead, when you fetched the receipt we would calculate the effectiveGasPrice
just to correct what we return to the user. This is a bug.
I have a PR incoming that removes the on the fly calculation of the effectiveGasPrice
on the receipt, and instead updates that actual effectiveGasPrice
of the transaction before saving to the chain.
Running on the latest version of ganache,
ganache v7.7.2 (@ganache/cli: 0.8.1, @ganache/core: 0.8.1)
This could be my misunderstanding, but it appears that
gasPrice != min(maxPriorityFeePerGas + baseFeePerGas, maxFeePerGas)
when multiple transactions are mined in the same block.command:
ganache-cli --chain.vmErrorsOnRPCResponse true --miner.blockTime 3600 --chain.chainId 1 -v --miner.timestampIncrement 12 --wallet.deterministic
repro:
Output:
For the 2nd and 3rd transactions I expected the gasPrice to be 2875000000 and 3875000000 respectively. When the transaction are mined individually, the invariant holds.
The example uses the web3.py library but the raw json is:
And the raw responses are: