feat: suggest gas price based on latest block's transactions #291
Conversation
CodSpeed Performance ReportMerging #291 will not alter performanceComparing Summary
|
There was a problem hiding this comment.
I will leave review of the logic to @jonastheis and @greged93 who have better gas oracle related context. However, I wonder if we can avoid making changes to crates/rpc/rpc-eth-types/src/gas_oracle.rs and instead exclusively use overrides in crates/scroll/* code? Our objective is to minimise our fork diff with upstream.
Yes, that's a good one. I tried to keep |
It looks a little tricky yes, upstream would need to abstract the |
| // get the gas used by each transaction in the block, by subtracting the | ||
| // cumulative gas used of the previous transaction from the cumulative gas used of | ||
| // the current transaction. This is because there is no gas_used() | ||
| // method on the Receipt trait. | ||
| .windows(2) | ||
| .map(|window| { | ||
| let prev = window[0].cumulative_gas_used(); | ||
| let curr = window[1].cumulative_gas_used(); | ||
| curr - prev | ||
| }) | ||
| .max() | ||
| .expect("len >= 2 guarantees at least one window"), |
There was a problem hiding this comment.
now that I think about it, won't this always fail to return the gas used for the first receipt? if we have [receipt_one, receipt_two], this would return receipt_two.cumulative_gas_used - receipt_one.cumulative_gas_used right? so you miss receipt_one.cumulative_gas_used?
| /// A block is considered at capacity if its total gas used plus the maximum single transaction | ||
| /// gas would exceed the block's gas limit, or the total block payload size plus the maximum | ||
| /// single transaction would exceed the block's payload size limit. | ||
| pub async fn scroll_suggest_tip_cap( |
There was a problem hiding this comment.
I was checking the gas oracle code from l2geth, and noticed the following:
- l2geth has these lines to set the suggestion to defaultGasTipCap or defaultBasePrice based on the fork. Do we not need this because Reth will never run on forks pre-Curie?
- l2geth has two sanity checks here. Should we add these?
This PR focus on implementing a simplified version of the GPO without needing to look at the tx pool, however look at the status of latest block. Suggest gas price base on if the latest block is at capacity. this will help to:
Two JSON_RPC methods are effected.
eth_gasPrice, if the latest block is not at capacity, this will return a minimal suggest gas price.eth_feeHistory, if the latest block is not at capacity, the reward field of return will be the minimal suggest gas price.