Etherlink: implement eth_feeHistory rpc

What

Issue #7174 (closed)

Prerequisite !13159 (merged)

This MR implements the eth_feeHistory rpc. The specification of the rpc can be found in https://ethereum.github.io/execution-apis/api-documentation/.

In the output, 3 optional field are not returned.

• baseFeePerBlobGas: Blob is introduced in Dencun. Not relevant here.
• blobGasUsedRatio: Blob is introduced in Dencun. Not relevant here.
• reward: Related to priority fee. Not relevant here

Why

The RPC is needed but wasn't implemented previously

How

The RPC takes in 3 inputs parameters.

• blockCount
• newestBlock
• rewardPercentiles (ignored)

A backward traversal is done from newestBlock through its (blockCount - 1) predecessors. Base_fee_per_gas and gas_used_ratio are read for each block and the lists are return along with number of the oldest block.

Two configuration options are added, to help operator enforce limits on the length of history and how old the data can be:

• fee_history.max_count : maximum number of blocks to be returned,
• fee_history.max_past : maximum number of blocks in the past that can be queried.

Details of note:

• for pre-EIP1599 blocks, the base_fee_per_gas returned is 0 (see for example alchemy spec )
• if the blockCount asked for is 0, an error is raised (in other implem it seems to be expected to be between 1 and 1024)
• if the newestBlock is a block in the future, then it is replaced by latest.

Manually testing the MR

dune exec etherlink/tezt/tests/main.exe -- --file evm_rollup.ml fee_history

TODO

This MR is yet to be finished. Remaining things that needs to be done includes:

• This RPC should return base_fee_per_gas for the next block, which is not implemented yet. In Ethereum, the base_fee_per_gas of the next block can be deterministically computed using the base_fee_per_gas and gas usage of the current block. We need to modify the kernel to add a way to obtain that info. For now, the fee for the most recent block is duplicated, to ensure the list has the correct length at least.
• SUGGESTION: do a follow up for that.

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR