What this changes

When a block arrives, we need to look up the parent transaction outputs (amount + locking script) for every input in every transaction. Today we do this one transaction at a time. This PR does several transactions in parallel.

How it works today

Aerospike has a batcher in front of it. Instead of firing one call per input, the batcher collects inputs and sends them off in a single batch when either:

• it has collected 100 inputs (size cap), or
• 10 ms have passed since the first input arrived (timer cap).

Good design — but the old code fed the batcher one transaction at a time:

submit tx1's 3 inputs → wait for results → submit tx2's 3 inputs → wait → …

A typical tx only has 2 or 3 inputs, nowhere near the 100-input size cap. So the batcher always fell back to the 10 ms timer before flushing. Every transaction paid that 10 ms wait. On a 1000-tx block that's about 10 seconds of pure timer waiting, even if Aerospike itself is fast.

The fix

Dispatch each transaction in its own goroutine, bounded by UtxoStore.BatchPreviousOutputsDecorateConcurrency (the same knob the SQL store already uses, default 4). Now several transactions feed inputs into the shared batcher at the same time, so:

• each flush carries inputs from multiple txs instead of just one
• the 10 ms timer wait gets shared across many txs instead of paid once per tx
• if you raise the concurrency high enough, the batcher hits its 100-input size cap and flushes immediately — no timer wait at all

The default of 4 is intentionally cautious. Each goroutine is mostly blocked waiting for batcher results, so a small fan-out is enough to keep the batcher busy. Operators can dial it up.

Benchmark — proof it's actually faster

stores/utxo/aerospike/batch_decorate_bench_test.go drives the real BatchPreviousOutputsDecorate against the real go-batcher with production-default settings (100 items / 10 ms timer). The only thing faked is the Aerospike call itself — replaced with a 500 µs sleep that models a real Aerospike round-trip.

1000-tx × 3-input block, Apple M3 Max:

Two things to take from this:

1. Cap=1 behaves exactly like the old code. That's the zero-risk fallback — if anyone hits trouble, setting utxostore_batchPreviousOutputsDecorateConcurrency=1 restores the old behaviour.
2. At the default cap=4, blocks decorate about 4× faster. That's the timer-sharing effect exactly as the maths predicts.

Why is the default only 4 if cap=64 is 570× faster?

Two reasons:

• Matches the existing SQL store knob. SQL store uses the same setting at default 4, so operators only have one number to think about.
• Cautious. An earlier version of this change (in perf(netsync): broaden quickValidationMode to cover CATCHINGBLOCKS + behind-tip #723) used OutpointBatcherSize=1024 as the concurrency cap, which triggered a known legacy-sync OOM. Default 4 has no memory risk; operators with headroom can raise it.

Tests

• go build ./... clean
• go vet ./stores/utxo/aerospike/... clean
• go test -race -short ./stores/utxo/aerospike/ — 464 passed
• New benchmark above

How this relates to #865

Both PRs attack the same 10 ms timer problem, at different layers:

• Add opt-in drain mode for the outpoint batcher (off by default) #865: tells the batcher to flush immediately instead of waiting for the timer (one setting, opt-in).
• This PR: parallelises transaction dispatch above the batcher, so the batcher fills up faster.

They compose. Drain mode plus concurrent dispatch is faster than either alone.

Context

Originally bundled in #723. Pulled out as a focused PR after #723's core change (broadening quickValidationMode to CATCHINGBLOCKS) was superseded by #847.