piersy
commented
8 months ago Mainnet nodes have been updated to report correct gas limits.
However blockscout is still not indexing correctly, blockscout seems to index gas limit changes as happening one block earlier as we can see from this query showing blocks where the gas limit changed. This will require more investigatio.
+----------+-----------+----------------+
| number | gas_limit | prev_gas_limit |
|----------+-----------+----------------|
| 3316 | 10000000 | 20000000 |
| 3251771 | 13000000 | 10000000 |
| 6137284 | 20000000 | 13000000 |
| 13562577 | 50000000 | 20000000 |
| 14137510 | 20000000 | 50000000 |
| 21355414 | 32000000 | 20000000 |
| 21856834 | 50000000 | 32000000 |
+----------+-----------+----------------+
As of 8th Jan 2023 both explorer.celo.org and celoscan were displaying incorrect block gas limits for some of their blocks.
The block gas limit was only added as a field on the block by the gingerbread fork (effective from block 21616000), before that blocks did not contain the gas limit, instead it was stored in the state and the rpc api could be configured to return the block gas limit (see this pr). This was done to improve compatibility with existing eth tooling. This meant that depending on what version of the client was running and what options were set, different results for block gas limit could be seen for the same block. This likely is what caused the problems in the indexed data of the explorers.
Before the change to improve compatibility with existing tooling the gas limit was never part of blocks returned by the rpc API.
After the compatibility change the gas limit, the below matrix shows when the block gas limit would be returned.
Subsequent to this change which went live in the gingerbread hardfork) the behaviour changed slightly for blocks before the gingerbread hardfork.
In the case where the block was before the gingerbread hardfork block and node did not have the state, it would now return an empty field.
This doesn't seem to have caused problems for users, no tickets have been raised because of this change and I see no discussion about problems caused by this change on our internal comms platform.
So I suggest here, that for the sake of simplicity going forward we always return the gas limit as a field for RPC blocks when compatibility mode is enabled even if we cannot load a value for it. On mainnet, alfajores and baklava, for the blocks from genesis up to the gingerbread hardfork we can hardcode the value returned to match the value that was used by the vm for execution at that block. ( We can do this fairly easily since the gas limit was only modified a handful of times).
Once the change has been enacted we can get blockscout to re-index blocks using the new implementation in order to correct the indexed gasLimit values.
The following block ranges and gas limits were extracted using the script found [here], (https://github.com/piersy/celo_investigations/tree/master/gasLimit). Celoscan has already updated their returned gas limit values based on the table for mainnet below.
Mainnet
Alfajores
Baklava