chore: exclude rocksdb

[Fraser999]

Summary

• Drop the transitive rocksdb dependency from our build by disabling default features on the workspace reth dep and re-listing the upstream defaults except rocksdb.
• rocksdb was pulled in via reth → reth-provider (gated behind reth-provider/rocksdb, which reth's default feature enables). We don't use the rocksdb-backed provider paths, so this is dead weight - a heavy C++/bindgen build for no runtime benefit.

Changes

Cargo.toml: workspace reth dep now uses default-features = false with an explicit feature list (jemalloc, otlp, otlp-logs, js-tracer, keccak-cache-global, asm-keccak, min-debug-logs) - i.e. upstream's default array minus rocksdb.

Note: reth-revm/portable is in upstream's default array but is a sub-crate feature directive that can't be re-listed by a consumer. If anything relied on portable revm it would need to be re-enabled via a separate path; nothing in this workspace appears to.

[prestwich]

reth-revm/portable

this naming concerns me for some reason. what does the feature do?

[Fraser999]

@prestwich

what does the feature do?

Ultimately it enables the portable feature on c-kzg and blst which are crypto libs. Their portable feature builds them without CPU-specific instruction-set extensions (ADX, AVX2, etc.).

That means if we build artifacts on one machine and run them on another with a less-capable CPU, the binary could die at runtime when c-kzg or blst hits an unsupported instruction.

I looked into turning it back on, but seems like it's already enabled via a different dep route: trevm enables revm/portable through its default features.

[prestwich]

okay gotcha. so ideally, this is turned off when we're making production builds?

[Fraser999]

I think the safe option is to enable it for production builds to cover the case where the builder machine has a newer CPU than all of the potential machines where the built binary will be expected to run. Enabling it makes the crypto libs avoid using CPU-specific instructions, making the binary more portable, but less performant.

If we know the target machines will always have at least the CPU instruction set of the builder machine, then we can afford to try and disable the portable feature to get the performance gain, but we'd need to do that in trevm I expect.

[prestwich]

for production we can/should know the exact capabilities we're going to run on and prioritize a build path that supports those CPUs, right? cc @init4tech/ryans

[rswanson]

arm64

[rswanson]

specifically we run on the r4g class of graviton processors. https://aws.amazon.com/ec2/graviton/

we build on arm machines on github actions

[rswanson]

thought a bit more- what is the actual performance gain here? I think in an ideal world unless the portable feature might be better for us unless the cpu specific improvements are large; optimizing for cpu's means that we'll need to do this for each person that runs our node software

[prestwich]

all we would need to do is enable a feature on our specific artifact build process. we don't need to do this for everyone. the optimizations are for cold but very expensive code paths