state_root calculation is not using trie cache

[cliff0412]

it seems that this code https://github.com/flashbots/op-rbuilder/blob/main/crates/op-rbuilder/src/builders/flashblocks/payload.rs#L1041
used the database to calculate state root. in reth's implementation, they used

fn overlay_root_from_nodes_with_updates(
        tx: &'a TX,
        input: TrieInput,
    ) -> Result<(B256, TrieUpdates), StateRootError> {
        let state_sorted = input.state.into_sorted();
        let nodes_sorted = input.nodes.into_sorted();
        StateRoot::new(
            InMemoryTrieCursorFactory::new(DatabaseTrieCursorFactory::new(tx), &nodes_sorted),
            HashedPostStateCursorFactory::new(DatabaseHashedCursorFactory::new(tx), &state_sorted),
        )
        .with_prefix_sets(input.prefix_sets.freeze())
        .root_with_updates()
    }

which can used cached trie input. should this be optimized to same as how reth's doing it?

[SozinM]

Hi!
Interesting point, i think CachedReadsMut from the state are used in state root calculation
But i will take a deeper look at it.

[SozinM]

I've looked into reth building for optimsim, and they are using plain state_root_with_updates as we do. I'm not sure ATM that it would be possible to reuse TrieInput from previous flashblocks, but i will try

[cliff0412]

I've looked into reth building for optimsim, and they are using plain state_root_with_updates as we do. I'm not sure ATM that it would be possible to reuse TrieInput from previous flashblocks, but i will try

if possible, maybe i can try work on this and making a PR? kindly let me know if u need assitance ATM, i am happy to contribute.

[SozinM]

If you will make PR to speed up state root calculation and reuse tries produced by previous flashblocks state root calculations we would certain welcome it!

[cliff0412]

If you will make PR to speed up state root calculation and reuse tries produced by previous flashblocks state root calculations we would certain welcome it!

Okay, let us try first

[SozinM]

@cliff0412 i think one possible improvements that could be done - we could use Parallel state root computation (like reth does in newPayload if number of cores sufficient)

[cliff0412]

@cliff0412 i think one possible improvements that could be done - we could use Parallel state root computation (like reth does in newPayload if number of cores sufficient)

i think they have multiple strategy for newPayload stateRoot calculation. probably this can be another topic? as this is more related to payload validation

[SozinM]

@cliff0412 Yes, and it make sense for op-rbuilder to use most performant approach, because block builder are usually running on a good hardware