perf(trie): compute and sort trie inputs async

[yongkangc]

Addresses #19250 by moving both trie sorting and trie input construction out of the hot path; validation can return once the state root is checked.

Changes:

• We stop building trie input on the validation hot path. validate_block_with_state now returns an ExecutedBlock with a pending DeferredTrieData, and offloads the sorting and trie input building to spawn_blocking.
• That background task then reconstructs the ancestor overlay (using in-memory blocks), sorts the state and trie updates, builds the trie input, and stores it in the handle. Callers only wait when they actually need the sorted trie data.

Approach

• We use Arc<OnceLock<ComputedTrieData>> to share the single result with multiple readers. OnceLock::wait blocks synchronously, needs no Tokio runtime, and allows cheap cloning of the handle.

OnceLock
--------
executor thread                background thread
--------------                  -----------------
wait_cloned()                   spawn_blocking()
  | wait() on OnceLock            | compute bundle
  | clone result                  | set_ready(bundle)
  v                               v
all readers see same value      first-set wins; no error state

Flow now:

• Hot path: execute block → verify state root → get unsorted state/updates + parent hash → return with pending handle.
• Background task: rebuild ancestor trie input → sort state/updates → extend trie input → set_ready / set_error.
• Consumers: call trie_data()/hashed_state()/trie_input() and block only when needed.

Impact

• seeing a 3 - 5% improvement on base
  • 1000 block benches on base for a set of problematic blocks: perf(trie): compute and sort trie inputs async #19894 (comment)

---

Other Approaches Considered?

Why not oneshot?

• We need “set once, read many, cache for late readers” and sometimes block in sync contexts - e.g., DB writes or state providers) that need the trie data but don’t run on a Tokio runtime. A oneshot is single-producer/single-consumer, gets consumed on first recv, and is async-only. It would still require a cache and sync wait path, adding complexity here.

Why not Mutex + Condvar?

• Using Mutex + Condvar requires some scaffolding code to handle errors and conditions. With Onelock, we could simplify the handling with blocking wait.

[mattsse]

seconding all of @mediocregopher comments

but functionally this approach lgtm

[yongkangc]

having a panic here - the concern is that if something crashes the process, any panic within the blocking tasks leaves the underlying data unset which would cause the consumers of trie data to block forever.

[yongkangc]

also side note - allows us to see what fails in e2e

[yongkangc]

Performance Changes:
-     NewPayload Latency per-block mean change:   -5.57%
-     NewPayload Latency per-block median change: -5.24%
-     Total newPayload time change:               -7.29%
-     NewPayload Latency p50:                     -7.22%
-     NewPayload Latency p90:                     -24.79%
-     NewPayload Latency p99:                     -2.81%
-     Gas/Second:                                 +1.75%
-     Blocks/Second:                              +1.75%

[mediocregopher]

mostly nits, looking good!

[mediocregopher]

One final nit, LGTM 🚀

[emhane]

@dhyaniarun1993 @itschaindev @sadiq1971 @meyer9 for visibility

[mattsse]

I think this is just Self(Arc::new(bundle.into()))

[mattsse]

hmm, this assumes that there's always something that's already computing the triedata,

imo this could be a potential footgun in case this isnt the case?

[mattsse]

this assumes that there is something that is doing this, otherwise this will deadlock, right?

[mattsse]

ca we make all of this a dedicated function, this existing fn is already quite large

[mattsse]

we don't have access to the internal oncestate and .get() does not block any ongoing initialization.

we could solve this with our own state tracking but this feels a bit redundant.

imo we can take the Hit here and always do get_or_init

imo that'd be better than relying on something else to init it