Skip to content

Enable system call to be traced by inspector - #323

Open
maoueh wants to merge 2 commits into
alloy-rs:mainfrom
streamingfast:feature/inspect-system-calls
Open

Enable system call to be traced by inspector#323
maoueh wants to merge 2 commits into
alloy-rs:mainfrom
streamingfast:feature/inspect-system-calls

Conversation

@maoueh

@maoueh maoueh commented Mar 28, 2026

Copy link
Copy Markdown

Motivation

When using ExEx to replay a full block including the pre/post execution steps, system calls weren't inspected before if inspector was enabled.

Solution

Just like transact_raw does, if the EthEvm is in inspect mode, transact_system_call now check if self.inspect is set and call the inspect variant of
inspect_system_call_with_caller.

Open Questions

One thing I'm unusure of the impact is about other inspector out there, would they be affected?

Maybe self.inspect could be switch off before transact_system_call is called in the current code and restored after to keep current behavior.

PR Checklist

Waiting on initial feedback.

  • Added Tests
  • Added Documentation
  • Breaking changes

When using ExEx to replay a full block including the pre/post execution steps, system calls weren't inspected before if inspector was enabled.

One thing I'm unusure of the impact is about other inspector out there, would they be affected?
@maoueh
maoueh requested review from klkvr and mattsse as code owners March 28, 2026 04:25

@mattsse mattsse left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a bit tricky, because afaik they dont appear as part of the block level tracing return values, so this could potentially end up including them.

but maybe not if we can make this work in the block level tracer

so I think this change seems fine, but we could perhaps consider adding an additional setting

wdyt @klkvr

@maoueh

maoueh commented Mar 28, 2026

Copy link
Copy Markdown
Author

this is a bit tricky, because afaik they dont appear as part of the block level tracing return values, so this could potentially end up including them.

That is my reasoning also, I feel that debug_traceBlock could catch those without being aware which could trace some calls it wasn't before.

Geth don't trace system calls via debug_traceBlock:

	blockCtx := core.NewEVMBlockContext(block.Header(), api.chainContext(ctx), nil)
	evm := vm.NewEVM(blockCtx, statedb, api.backend.ChainConfig(), vm.Config{/* Missing Tracer: tracer here, so no tracing happening with this EVM */})
	if beaconRoot := block.BeaconRoot(); beaconRoot != nil {
		core.ProcessBeaconBlockRoot(*beaconRoot, evm)
	}
	if api.backend.ChainConfig().IsPrague(block.Number(), block.Time()) {
		core.ProcessParentBlockHash(block.ParentHash(), evm)
	}

I think this would be an hidden changes.

I'm using BlockExecutor via executor.apply_pre_execution_changes() so I'm not the direct caller of it. So I'm unsure where this setting should go. Seems like calls sites should take the decision about if they want to trace system calls (pre + post).

but maybe not if we can make this work in the block level tracer

Would be interested to know more, I saw it but unsure if it's ready to try/improve it. Currently using ExEx than creating a BlockExecutorFactory and then tracing full block like that, replicating essentially the tracing we have using Geth Live Tracing feature.

So if BlockTracer makes that easier/better, I'm all ears :)

@klkvr

klkvr commented Mar 31, 2026

Copy link
Copy Markdown
Member

i think we should make sure that any reth rpc callsites explicitly disable inspection before pre/post execution hooks before making this change

@maoueh

maoueh commented Mar 31, 2026

Copy link
Copy Markdown
Author

@klkvr Ok no problem. I've noted https://github.com/paradigmxyz/reth/blob/26a37f3c00649a0b8f5381b2b9a8b42a312c5d5f/crates/rpc/rpc-eth-api/src/helpers/trace.rs as you main points. Probably others in reth.

Is there other repositories I should inspect?

valvecitydev added a commit to valve-tech/reth that referenced this pull request May 9, 2026
The streamingfast [patch.crates-io] for alloy-evm was dropped during
the merge because no sf/v0.34.0 branch existed and pulse needs 0.34
for its erigon3 feature set. Without it, firehose's Inspector hooks
miss state changes from EIP-4788 (beacon-root contract) and EIP-2935
(block-hashes contract) system calls — those calls happen, but the
inspector never sees them.

Doesn't matter for PulseChain right now (Cancun not activated, so
those system calls don't fire) but is needed for Ethereum mainnet
firehose. We need eth support per the project goals, so the patch
has to come back.

The patch itself is 8 lines: route system_call_with_caller through
inspect_system_call_with_caller when an inspector is attached.
Ported cleanly from streamingfast/evm sf/v0.33.0 onto alloy-evm
v0.34.0 (the source-region didn't change between 0.33 and 0.34).
Hosted at github.com/valve-tech/evm branch valve/v0.34.0, pinned by
commit hash so cargo gets reproducible builds.

Runtime gating is built in: `if self.inspect { route_through_inspector }
else { vanilla }`. With no tracer initialized, the patched alloy-evm
behaves identically to the unpatched version. So "activate vs not"
is automatic — no Cargo feature flag needed; tracer initialization
at runtime is the switch.

Upstream tracking: alloy-rs/evm#323. When
that lands and propagates to a tagged release, this patch becomes
redundant and we can drop the [patch.crates-io] entry.
valvecitydev added a commit to valve-tech/reth that referenced this pull request Jun 15, 2026
Records the system-call inspector patch dependency, the reth v2.3 fix
(valve-tech/evm valve/v0.36.0), the upstream blocker (alloy-rs/evm#323
open, gated on guarding reth RPC callsites), and what to re-check before
dropping the fork.
valvecitydev added a commit to valve-tech/reth that referenced this pull request Jul 15, 2026
v2.4.0 (2026-07-14) bumps alloy-evm 0.36->0.37 (lock resolves 0.37.1) and
revm 40->41, which would silently drop our valve/v0.36.0 patch and kill
firehose system-call tracing. Pre-built and verified valve-tech/evm branch
valve/v0.37.1 (cherry-pick clean, builds against revm 41.0.0).

Records the v2.4.0 bump requirements (the #26330 PayloadValidator signature
change and the ParallelSparseTrie removals both land on code we modify), the
revmc JIT firehose-fidelity risk, a repeatable per-bump patch recipe, and the
2026-07-15 fold-back re-review verdict (alloy-rs/evm#323 still open, upstream
0.37.x still un-inspected -> keep the fork).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants