feat(rpc): Use pool-based pending block for pending state over latest#17924
feat(rpc): Use pool-based pending block for pending state over latest#17924
Conversation
github-actions
bot
added
A-rpc
mattsse
left a comment
mattsse
left a comment
There was a problem hiding this comment.
imo this goes in the right direction,
because this is a bit tricky, I'd like to start smaller and first focussing on making the state_at fn async
for the state I think we should introduce a placeholder pending_state fn first then we don't need to touch the local_pending block fn for now
RomanHodulak
force-pushed
the
pool-pending-block
branch
from
ad70035 to
640db06
Compare
RomanHodulak
force-pushed
the
pool-pending-block
branch
from
640db06 to
0feaa79
Compare
| if at.is_pending() { | ||
| if let Ok(Some(state)) = self.local_pending_state().await { | ||
| return Ok(state) | ||
| } | ||
| } | ||
|
|
||
| self.provider().state_by_block_id(at).map_err(Self::Error::from_eth_err) |
There was a problem hiding this comment.
this will no ignore the real pending state right?
hmm, this is a bit tricky because we don't have a nice way to obtain just the optional pending state from the provider, only if the real pending block exists, but imo we could ignore this case for now and then add this functionality separately as an additional optional fn to:
reth/crates/storage/storage-api/src/state.rs
Lines 185 to 189 in 6264530
as fn maybe_pending?
There was a problem hiding this comment.
You're right, this won't ignore the real pending state.
However, the local_pending_state only returns the pool-based pending state, not the real pending state.
2 participants
Closes #17876
For
LoadStatetrait based RPC features, use pool-based pending block before using latest block if no pending block from consensus layer is available.A feature useful for MEV / flashblocks use-cases.