Dependency Inflation

[TheBlueMatt]

For something that might eventually move towards being a backend to a trillion dollar asset, a large number of (transitive) dependencies (especially ones that are predominately maintained by a single person) is a critical security issue for the entire network. It'd be nice to go ahead and reduce (non-dev) dependencies early to avoid overly depending on them and finding them hard to remove later.

[rkuester]

For something that might eventually move towards being a backend to a trillion dollar asset [...]

I love where your head's at. :^)

I agree with the spirit of this. Are there particular dependencies you'd flag as concerning? Happy to discuss specifics.

More broadly, here are some ideas:

Types of Risk

When talking about "security", it's helpful to identify the specific attack vectors we want to protect against.

1. Malicious modification of a dependency
2. Disappearance of a dependency (yanked from crates.io, maintainer deletes repo)
3. Rot (dependency falls out of maintenance, accumulates CVEs, becomes incompatible with newer Rust)

Of course, we're completely dependent on the Rust toolchain itself---rustc, cargo, the standard library, and core crates like libc. This is a massive point of trust for which there's no real competition or alternative.

Are there others?

Tradeoffs

Engineering is always about tradeoffs, of course. Fewer dependencies means less supply chain risk but more code to maintain. More dependencies means faster development but larger attack surface. There's no universally correct answer, just context-dependent choices.

The right level of dependency aversion probably changes as the project matures. Early on, velocity matters more. Later, when the code is running big money, the calculus shifts toward minimizing risk.

Mitigation Strategies

• Malicious modification: We can pin exact versions in Cargo.toml and commit Cargo.lock. This doesn't prevent the problem---we'll still want to update dependencies---but it does mean an attacker can't silently inject malicious code into existing deployments. Updates still require review; that's a big surface area. Good test coverage helps here---behavioral changes in dependencies ideally show up as test failures.

• Disappearance: In theory we could mirror dependencies or run our own registry. If a critical dependency vanishes, we can find it somewhere and fork it. The code doesn't disappear from our Cargo.lock or local caches, so with some luck, we have time to respond.

• Rot: Deal with it as it presents itself. Replace or eliminate dependencies that become unmaintained.

Minimizing Dependencies

Some guidelines we can follow:

1. If the alternative custom code is small, skip the dependency. For example, I avoided pulling in a JSON-RPC library for the Stratum v1 implementation because we only need a handful of message types. The custom serialization code was straightforward. (stratum_v1/messages.rs)

2. Prefer dependencies with multiple maintainers and wide use. Tokio, serde, bitcoin---these have ecosystems around them and aren't going anywhere. A crate maintained by one person is riskier than one with a team behind it.

3. Watch out for transitive dependencies. A tiny crate that pulls in half of crates.io is suspect.

Argument for Dependencies

• Speed. We move faster by using existing crates. Examples: axum for the REST API instead of hand-rolling HTTP routing, tokio instead of writing our own async runtime, udev bindings instead of hand-coding libudev FFI calls for USB hotplug detection.

• Correctness. Some domains benefit heavily from battle-tested implementations. USB hotplug via libudev has tricky FFI semantics and lifetime management. HTTP routing has security pitfalls. Async I/O has subtle race conditions. Using existing crates means someone else has already thought through and solved these problems for us. Sometimes a dependency is the lower-risk choice.

• Maintenance burden. Every line of custom code is code we have to maintain.

• Pragmatism at this stage. Right now the project needs to move fast to prove out the architecture and get something working. Using dependencies lets us focus on the novel parts---board abstraction, job scheduling, protocol implementations---rather than reinventing JSON parsing or async I/O.

That said, I'm not opposed to pulling dependencies out as an ongoing background effort. Replacing a dependency with a better dependency or custom code could be a nice bounded task for new contributors who want to get familiar with the codebase.

Next Actions

Anyone want to do a dependency audit? I haven't been too careful thus far. We could go through Cargo.toml and flag anything that feels sketchy or unnecessarily heavy. I'm open to cutting things that don't pull their weight.

[average-gary]

Dependency Audit Results

Ran an audit of the workspace dependencies. Here's what we found.

Current state: 40 direct dependencies in mujina-miner, ~149 unique transitive crates across the workspace.

Dead Dependencies (zero usage in source)

Confirmed by both manual analysis and cargo-machete:

Crate	Location	Exclusive transitive deps eliminated
sha2	workspace + mujina-miner	7 (sha2, digest, block-buffer, crypto-common, generic-array, typenum, cpufeatures)
hyper (direct)	workspace + mujina-miner	5 (hyper, httparse, httpdate, try-lock, want) — still pulled in transitively by axum/reqwest
modular-bitfield	workspace + mujina-miner	3 (modular-bitfield, modular-bitfield-impl, static_assertions)
hex	mujina-dissect	0 (shared)
thiserror	mujina-dissect	0 (shared)
tracing	mujina-dissect	0 (shared)

Removing these is risk-free — 15 exclusive transitive crates eliminated, zero code changes needed.

Note on sha2: The bitcoin crate ships its own SHA-256 implementation via bitcoin_hashes. All hashing in the codebase already uses bitcoin::hashes::sha256d and BlockHeader::block_hash(). The sha2 crate was likely added speculatively and never wired in.

Straightforward Removals (small code replacements)

Crate	Exclusive deps saved	Effort	Replacement
bitvec	5	~6 lines	Replace 2 call sites in bm13xx/protocol.rs with bitwise <</>> ops
strum	3	~30 lines	Replace 2 #[derive(FromRepr)] with manual match in bm13xx/protocol.rs
num-traits	1	~10 lines	Replace Float::integer_decode() in u256.rs with manual IEEE 754 bit extraction
futures → futures-util	2	Rename imports	futures-util re-exports everything used (SinkExt, StreamExt, ready!)

11 more transitive crates eliminated, ~50 lines of replacement code.

Biggest Single Win: reqwest

reqwest is used in exactly one file (api_client/mod.rs) for ~5 simple HTTP GET calls (CLI/TUI talking to the local daemon). It brings in 37 exclusive transitive dependencies including the TLS stack (native-tls, security-framework), ICU unicode normalization, IDNA, encoding_rs, url, etc.

Replacing with a lighter HTTP client built on hyper-util (already available transitively from axum) would be the single highest-impact change.

Moderate Effort

Crate	Exclusive deps	Notes
utoipa-swagger-ui	8	Embeds a full web app. Could serve raw OpenAPI JSON and drop the embedded UI.
crc_all	1	Niche single-maintainer crate. CRC-5 and CRC-16 are ~20 lines each to implement inline.
nix (production)	0	Used for 1 fstat call; replace with direct libc. Keep as dev-dep for PTY tests.
hex (mujina-miner)	1	~30 call sites (lots in tests). Could migrate to bitcoin::hex utilities.

Keep (justified)

tokio, axum, bitcoin, serde, tracing, inventory, slotmap, rustix, tokio-serial, parking_lot, time — all serve core purposes with no lighter alternative.

Potential Total Reduction

From ~149 unique crates down to ~80–90, a 40–50% reduction in dependency surface if all tiers are addressed.

Longer-term: CI Enforcement

To prevent dependency creep, a GitHub Actions workflow running cargo-machete (fast, stable Rust, heuristic) and cargo +nightly udeps (compiler-accurate) on every PR would catch unused dependencies before they're merged. The project currently has no CI — adding fmt/clippy/test/unused-deps checks would match what just checks does locally.

[TheBlueMatt]

FWIW the bitcoin ecosystem is moving towards using bitreq, a pretty trivial HTTP client which is basically a fork of minreq with async support added.

[average-gary]

Thank you for that. I see it's one of the rust-bitcoin crates. I assume that's the one you're referring to?

[TheBlueMatt]

Correct.

[rkuester]

Nice work. Happy to take PRs related to this. Maybe I'll tag this as a good first issue for would-be contributors.

[rkuester]

Created #29.