StateRootTask mode is counterproductive for RPC/Follower nodes

[louisliu2048]

Summary
Reth defaults to StateRootTask mode for state root computation when available_parallelism >= 5, but this mode is designed for Sequencer nodes and introduces significant overhead for RPC/Follower nodes that only validate blocks. Using --engine.state-root-fallback (Synchronous mode) provides much better performance for RPC nodes.

Problem Description
The plan_state_root_computation() function selects the state root strategy:

fn plan_state_root_computation(&self) -> StateRootStrategy {
    if self.config.state_root_fallback() {
        StateRootStrategy::Synchronous
    } else if self.config.use_state_root_task() {
        StateRootStrategy::StateRootTask  // Default on most machines
    } else {
        StateRootStrategy::Parallel
    }
}

// use_state_root_task() returns true when:
pub const fn use_state_root_task(&self) -> bool {
    self.has_enough_parallelism && !self.legacy_state_root
}
// has_enough_parallelism = available_parallelism >= 5

On most modern machines (≥5 CPU cores), Reth defaults to StateRootTask mode.

Why StateRootTask is Counterproductive for RPC Nodes
StateRootTask is designed for Sequencer nodes, where:

• Block execution and state root computation can happen in parallel
• The Sparse Trie is updated incrementally as transactions are executed
• Multiproof is generated concurrently with execution

For RPC/Follower nodes, the situation is completely different:

• Blocks are already fully executed when received via P2P or Engine API
• State root computation is purely validation - we just need to verify the root matches
• There's no opportunity for parallelism between execution and state root computation

The overhead introduced by StateRootTask mode for RPC nodes includes:

1. Multiproof generation - Computing merkle proofs for all changed accounts/storage
2. Channel communication - Sending updates between tasks via channels
3. Sparse Trie task scheduling - Managing the background trie update task
4. Extra memory allocations - For proof data structures and buffers
5. Task synchronization - Waiting for the background task to complete
   All of this overhead provides zero benefit for RPC nodes since there's no parallel execution happening.

Performance Impact
In our local testing:

• With StateRootTask/Parallel mode: validate_block_with_state takes 2-8 seconds for high-gas blocks
• With Synchronous mode (--engine.state-root-fallback): Same blocks validate in <1 second
  The RPC node was consistently falling behind the Sequencer until we enabled state_root_fallback.

Proposed Solution
Option 1: Auto-detect Node Role
Automatically detect whether the node is a Sequencer or RPC/Follower:

• If the node is not producing blocks (no --sequencer flag or equivalent), default to Synchronous mode
• Only use StateRootTask mode when the node is actively sequencing/building blocks

Option 2: Better Naming and Documentation

1. Rename state_root_fallback to something clearer like synchronous_state_root or simple_state_root
2. Update documentation to explicitly recommend this option for RPC/Follower nodes
3. Consider making Synchronous the default for non-sequencer nodes

Option 3: Separate Configuration
Add a configuration option like --engine.state-root-mode with values:

• auto (default) - Use StateRootTask for sequencer, Synchronous for RPC
• state-root-task - Force StateRootTask mode
• parallel - Force Parallel mode
• synchronous - Force Synchronous mode