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 is0
(see for example alchemy spec ) - if the
blockCount
asked for is0
, 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 bylatest
.
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