execution/stagedsync: hand the trace sets to the apply result instead of copying

[AskAlexSharov]

The publish path in nextResult allocated two empty maps into the apply result, then copied every entry of the transaction's trace sets into them. The result already owns those maps.

• The tracer is a local in Worker.RunTxTaskNoLock, built per transaction. The parallel Worker has no CallTracer field — it keeps evm and ibs across transactions, not the tracer.
• CallTracer.OnEnter lazily allocates froms/tos inside that instance and Froms()/Tos() hand them straight to result.TraceFroms / TraceTos. TxResult is not pooled.
• applyLogsAndTraces4 only ranges over the maps — no writes, no deletes.
• Nothing reads result.TraceFroms after the publish block. finalizedResults[tx-1] is read again, but only for .Receipt, and takeNextPending + markComplete publish each transaction once.

The block-end result in the same function already assigns them directly:

traceFroms:            lastResult.TraceFroms,
traceTos:              lastResult.TraceTos,

This makes the per-transaction path match. Costs two map allocations and one insert per distinct from/to address per transaction, on the serial apply loop.

Nil is safe: range over a nil map is zero iterations, and the block-end path already passes possibly-nil maps through.

If the tracer is ever made worker-held to drop its per-transaction allocation, this becomes wrong — but so would the block-end path, and the fix then is Reset semantics at the worker rather than a defensive copy on the apply loop.

No new tests: pure refactor, no behaviour change. Covered by the existing trace-index tests.

Green: execution/stagedsync, execution/tests, rpc/jsonrpc.

[Copilot]

Pull request overview

This PR optimizes the parallel execution publish path in execution/stagedsync by removing per-transaction copying of trace address sets (from/to) into freshly-allocated maps when building the apply result. Instead, it directly hands the existing maps from the finalized execution result into the txResult sent through the apply/commit fan-out, aligning the per-transaction path with the existing block-end path and reducing allocations and per-entry inserts on the serial apply loop.

Changes:

• Remove maps.Copy-based cloning of TraceFroms/TraceTos during nextResult publishing.
• Assign result.TraceFroms/result.TraceTos directly into the per-tx txResult (traceFroms/traceTos), eliminating two map allocations per published tx.
• Drop the now-unused maps import.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yperbasis]

LGTM — verified the ownership and read-only claims against the code, and ran execution/stagedsync under -race plus the rpc/jsonrpc trace tests locally on the branch.

Nit, pre-existing and fine as a follow-up: the block-finalize txResult carries traceFroms/traceTos that no consumer ever reads — isFinalize has been write-only since #20805, and no caller passes ApplyTxIndexes' skipReceiptCache although its docstring cites exactly that finalize result. So the block-end precedent cited here is safe but vacuous: the coinbase TracesToIdx entry actually comes from the block-end task's own per-tx publish. Dropping those dead fields and the stale docstring would tidy this up.