Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: implement eth_feeHistory #2083

Merged
merged 21 commits into from
Apr 20, 2023
Merged

Conversation

sk1122
Copy link
Contributor

@sk1122 sk1122 commented Apr 2, 2023

Ref: #1782

Note: This PR implements eth_feeHistory

Sources

Todo

  • if max_priority_fee_per_gas is None, decide between using gas_price or 1
  • try optimize the transaction for loop by caching some things, if possible
  • works only upto latest block, pending blocks aren't supported yet

@sk1122 sk1122 changed the title feat: implemented eth_feeHistory feat: implement eth_feeHistory Apr 2, 2023
@codecov-commenter
Copy link

codecov-commenter commented Apr 2, 2023

Codecov Report

Merging #2083 (b787684) into main (8625373) will increase coverage by 0.02%.
The diff coverage is 87.32%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

@@            Coverage Diff             @@
##             main    #2083      +/-   ##
==========================================
+ Coverage   72.14%   72.17%   +0.02%     
==========================================
  Files         472      474       +2     
  Lines       57098    57295     +197     
==========================================
+ Hits        41191    41350     +159     
- Misses      15907    15945      +38     
Flag Coverage Δ
integration-tests 19.11% <4.69%> (-0.06%) ⬇️
unit-tests 66.85% <86.85%> (+0.03%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
crates/rpc/rpc/src/eth/api/mod.rs 65.51% <ø> (ø)
crates/rpc/rpc/src/eth/error.rs 11.71% <0.00%> (-0.11%) ⬇️
crates/rpc/rpc-types/src/eth/fee.rs 63.15% <46.15%> (-36.85%) ⬇️
crates/rpc/rpc/src/eth/api/fees.rs 87.50% <87.50%> (ø)
crates/primitives/src/transaction/mod.rs 87.86% <93.33%> (+0.22%) ⬆️
crates/rpc/rpc/src/eth/api/server.rs 98.14% <96.42%> (+0.17%) ⬆️

... and 18 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@mattsse
Copy link
Collaborator

mattsse commented Apr 4, 2023

is this ready for review?
could you please briefly summarize the changes you made?

@sk1122
Copy link
Contributor Author

sk1122 commented Apr 4, 2023

is this ready for review? could you please briefly summarize the changes you made?

It is not ready, because I have few questions

  • if max_priority_fee_per_gas is None, which to use gas_price or 1? afaik max_priority_fee_per_gas will be None for pre-eip-1559 blocks, so should we just return reward as 0 in that case?
  • are pending blocks supported in current codebase?

@sk1122
Copy link
Contributor Author

sk1122 commented Apr 6, 2023

@mattsse what do you think?

@mattsse mattsse added the A-rpc Related to the RPC implementation label Apr 13, 2023
Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for the delay..

I skimmed it, I can follow for the most part.

@Rjected mind giving this a closer look and have a look at the geth impl for reference?

Comment on lines 10 to 13
/// gas used by a block
pub gas_used: u128,
/// minimum between max_priority_fee_per_gas or max_fee_per_gas - base_fee_for_block
pub reward: u128
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these serialized as numbers or hex?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This struct just mirrors an internal geth struct so this shouldn't be serialized

@Rjected
Copy link
Member

Rjected commented Apr 19, 2023

Took this over to try to get this over the line and pass hive tests! Only thing TODO for this PR now:

  • deduplicate effective_gas_price and effective_tip_per_gas - might have been accidental duplicate work, my bad
  • remove unwraps

@Rjected Rjected marked this pull request as ready for review April 19, 2023 04:35
@Rjected Rjected requested review from Rjected and gakonst as code owners April 19, 2023 04:35
@Rjected Rjected mentioned this pull request Apr 19, 2023
@sk1122
Copy link
Contributor Author

sk1122 commented Apr 19, 2023

Thanks for the help @Rjected

@Rjected
Copy link
Member

Rjected commented Apr 19, 2023

On why effective_gas_price exists: I was trying to reimplement EffectiveGasTip from geth, but I didn't see effective_tip_per_gas, so it's almost identical. It seems slightly different in that effective_gas_price supports an optional base fee, with priority_fee_or_price trying to emulate geth's gasTipCap method.

@Rjected Rjected requested a review from mattsse April 20, 2023 04:22
Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm,

we need another feature that installs a task that inserts new items

@@ -278,6 +278,43 @@ impl Transaction {
}
}

// TODO: dedup with effective_tip_per_gas
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeh, I'd like to dedup this and unify, naming, because everything surrounding fee/price can be incredibly confusing

good with a followup for this

Comment on lines 92 to 93
let headers: Vec<Header> = self.inner.client.headers_range(header_range.clone())?;
let transactions = self.inner.client.transactions_by_block_range(header_range)?;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is reasonable to always read them from disk, if we add a service task that inserts items to the cache for every new block we can prevent this for the majority of requests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-rpc Related to the RPC implementation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants