feat: cross-block state management #78
Conversation
danyalprout
left a comment
danyalprout
left a comment
There was a problem hiding this comment.
lgtm (assuming we optimize the perf in a follow up)
To test this, can we clone this test, but make the flashblocks across block:
https://github.com/base/node-reth/blob/main/crates/flashblocks-rpc/src/tests/state.rs#L289
| } | ||
| fn get_balance(&self, address: Address) -> Option<U256> { | ||
| self.pending_blocks | ||
| .load_full() |
There was a problem hiding this comment.
better to use .load if possible (you will need deref it), because you have 5 premade instances that could be used instantly (and if it exhausted it will fallback to load_full)
There was a problem hiding this comment.
will do this in a follow-up.
| next_log_index += receipt.logs().len(); | ||
|
|
||
| let mut should_execute_transaction = false; | ||
| match &prev_pending_blocks { |
There was a problem hiding this comment.
This is interesting part, would we have state at all, i assume we receive only new transaction in flashblocks
And will this be cleaned on reorgs?
There was a problem hiding this comment.
Ah, because we have vec of flashblocks
This part could be speed up, because we statically know which transactions should we execute. Only last flashblock should have unexecuted transactions
There was a problem hiding this comment.
technically yeah, can probably remove that check in exchange for extracting last flashblock txns separately and checking if current tx is in the set of the last fb's txns. not sure will be much of a difference in practice but can be done as a small follow up
|
Looks great IMO, only 2 places when i see simple optimisations |
* first pass at cross-block state management * please clippy * rename fb_state to state * add test for persisting state overrides across blocks * add test for canonical block progression * add reorg handling on canonical block * naive hacky caching * reduce repeated code and cleanup * add reorg handling test, add sequential cross-block pending state build-up test * lockfile * process flashblocks via a channel queue to avoid data race
Cross block state management for flashblocks
Optimistically queues flashblocks state updates and overrides, even across block boundaries. Will clear pending state if canonical block signals a reorg occured.