I want to try wiring hotpath into ethrex as an optional profiler.

It's a feature-gated Rust profiler that shows where code spends time, burns CPU, and allocates. The parts that look useful for us: timing + CPU + allocation breakdowns per function, async observability (futures, channels, streams) and Mutex/RwLock contention, Tokio runtime stats, a live TUI plus static reports, and a CI mode for catching regressions on PRs. Usage is just attributes:

#[hotpath::measure]
fn execute_block(...) { ... }

#[tokio::main]
#[hotpath::main]
async fn main() { ... }

Right now we lean on ad-hoc perf/flamegraph/hyperfine when something feels slow. Having a profiler always sitting behind a feature flag would let us instrument the obvious hot paths (block execution, levm, trie, RLP, RPC), look at allocations and lock contention without a separate setup, and ideally catch regressions in CI before they land.

The one thing I care about most, and the hard requirement for this to land:

It has to be genuinely zero cost with the feature off. No extra deps in the default build, no codegen, the attributes compile down to nothing. hotpath claims this is how it works, but we verify before merging:

• default make build dependency graph is unchanged (hotpath and its transitive deps only show up when the feature is on)
• no runtime regression on the default profile (benchmark block import or ef_tests with the flag off, confirm it's within noise)
• the attributes expand to no-ops when disabled
• both cargo build and cargo build --features <hotpath-feature> build, and CI's default jobs don't turn it on

Rough plan: add it as an optional dep behind a workspace feature (probably hotpath plus the hotpath-cpu / hotpath-alloc sub-features), put #[hotpath::main] on the cmd/ethrex entrypoint behind that feature, instrument block execution + levm as a first pass, and write up how to run it.

A few things to check while doing it: whether hotpath needs nightly or a global allocator override for the alloc feature and how that plays with our allocator, making sure it stays fully out of the zkVM guest builds (sp1, risc0), and whether the MCP-server integration is worth bothering with.