web3j.getGasPrice

[msak222]

The gasPrice of the main network is more than 300 Gwei, but web3j.getGasPrice is obtained from our latest version of the full node and occasionally returns 6 or 2. What is the problem?

[karalabe]

Just tried it on one of our nodes, returned 209 Gwei. Re you sure the node you're querying is in sync?

[karalabe]

Ran it against all of our bootnodes, 6 returned 206 gwei, and one which is not synced returned 1 gwei.

[msak222]

We found that occasionally a very low gasPrice will be returned at a very small stage. Our node is the latest version and synchronized to the latest block. We are also very confused, so we ask for your help.

[msak222]

If you have the conditions, please monitor for a longer time, such as whether there is this problem in two days, we will continue to observe the problem

[bulgakovk]

Faced the same issue a few times. I have also found a correlation between extremely low fees and mined blocks with 0 transactions:

I do see this comment:

go-ethereum/eth/gasprice/gasprice.go

Lines 182 to 185 in cc33398

	// getBlockPrices calculates the lowest transaction gas price in a given block
	// and sends it to the result channel. If the block is empty or all transactions
	// are sent by the miner itself(it doesn't make any sense to include this kind of
	// transaction prices for sampling), nil gasprice is returned.

but not sure where exactly the case with 0 length TXs blocks is handled in the function. Might it be the root reason for these random drops?

[leevlad]

I would like to chime in here and report that this has been an issue for us for months, and is still ongoing on the latest version of geth. We have not been able to find a good way to isolate the conditions under which this issue occurs as it seems rather sporadic.

[msak222]

Ran it against all of our bootnodes, 6 returned 206 gwei, and one which is not synced returned 1 gwei.

Faced the same issue a few times. I have also found a correlation between extremely low fees and mined blocks with 0 transactions:

I do see this comment:

go-ethereum/eth/gasprice/gasprice.go

Lines 182 to 185 in cc33398

	// getBlockPrices calculates the lowest transaction gas price in a given block
	// and sends it to the result channel. If the block is empty or all transactions
	// are sent by the miner itself(it doesn't make any sense to include this kind of
	// transaction prices for sampling), nil gasprice is returned.

but not sure where exactly the case with 0 length TXs blocks is handled in the function. Might it be the root reason for these random drops?

Hi guys. A friend encountered a similar problem above, please verify the situation, please @karalabe

[junderw]

Verification of this bug requires polling a geth node once every minute for a couple days until congestion occurs.

I think it has to do with blocks, so maybe even polling / gathering data once every 15 seconds would be better to find any issues sooner.

[junderw]

@bulgakovk

Can you share some recent "dips"... I think this is a constant issue among all instances. So it definitely has to do with the blocks.

Our most recent dips that were consitent across all of our instances were

2021/04/22 08:47:00 UTC (dip to 6 gwei from 112 gwei)
2021/04/22 08:53:00 UTC (dip to 6 gwei from 112 gwei)

(times in screenshot are JST (UTC+09:00))

[junderw]

I think you probably have similar dips.

Our polling job polls all of the instances in sequence, but in general the requests should only be a few ms off for us... maybe if your jobs are off by 30 seconds etc. then maybe it won't be exactly the same but I am interested to see if you have dips at similar time.

[holiman]

Verification of this bug requires polling a geth node once every minute for a couple days until congestion occurs.

No, that should not be posslbe. Any given segment of blocks should lead to a totally deterministic gas oracle. If I'm wrong about this, it's a bug which needs to be fixed. I'm 99% certain that if I replay the GPO on the segment used in the charts above, looking only at the actual transactions that were included in the blocks, I would get an identical chart.

[bulgakovk]

@bulgakovk

Can you share some recent "dips"... I think this is a constant issue among all instances. So it definitely has to do with the blocks.

Confirming one of our nodes had the same dip exactly at that time (UTC timezone):

However, it's not a case for the second node:

It seems to depend on which exactly chain segment the node has used to predict the price (since the method returns some percentile of TX gas prices included in the recent blocks IIRC).

[Melraidin]

For instances of this occurring I walked the chain to get the gas price at each block. Here's a block where I saw an unusually low gas price:

Block number: 12287282
Gas price: 1,000,000,000
Prices used in gas calculation: [+0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +0 +1 +1 +1 +1 +1 +1 +1000000000
 +1000000000 +1000000000 +1000000000 +1000000000 +1000000000 +1000000000 +120000000000 +132000000000 +132000000000 +132000000000 +132000000000 +135000001561 +135300000000 +135300000000 +141015000000 +141075000262 +148000001459 +14900000
0000 +149000000000 +150000000000 +150000000000 +150000000000 +150000000000 +150000000000 +150000000000 +161700000000 +162000000000 +164000000000]

That's a lot of zero or one wei gas prices. It makes sense though, given we grab the cheapest transactions from the blocks instead of sampling a random set of transactions from the blocks we're using in the estimate:

go-ethereum/eth/gasprice/gasprice.go

Line 198 in 34f3c95

sort.Sort(transactionsByGasPrice(txs))

Here's links to a few of these transactions to confirm I'm not misreading them and perhaps see how they ended up in a block to begin with:
https://etherscan.io/tx/0xc370d0a480b477fe2465f4259e6cf21603d9cc4906aa1d86704292e6fa369e0a
https://etherscan.io/tx/0xb11fb82fbbc8499bfc2d6c0e20ae5b358b5b3dd7ee91ff56afa773543a19da93
https://etherscan.io/tx/0x939ef48c3bb73fc4b389496c573d77305d8ff1f8f4ed3221ef6d61add378fc80