chore: `remote-signer` feature in arc-node-execution gates build-deps with no build.rs to consume them

[teyrebaz33]

Summary

crates/node/Cargo.toml (the arc-node-execution binary — the Execution Layer) declares a remote-signer feature gating protox and tonic-build as optional build-dependencies:

remote-signer = ["dep:protox", "dep:tonic-build"]
integration = ["remote-signer"]

[build-dependencies]
protox = { workspace = true, optional = true }
tonic-build = { workspace = true, optional = true }

crates/node has no build.rs, so nothing in this crate ever invokes either dependency:

$ find crates/node -iname build.rs
(no output)
$ grep -rn 'remote-signer' crates/node/src/
(no output)

Both dependencies still get pulled and compiled — they're resolved in Cargo.lock under arc-node-execution — for no observable effect.

Why this looks like leftover wiring, not intentional

arc-node-execution doesn't depend on arc-remote-signer at all, directly or transitively (confirmed against Cargo.lock). That tracks: remote signing is a validator/consensus-layer concern, and arc-node-execution is the execution layer — it has no reason to talk to a remote signer in the first place.

The crate that does need this is wired correctly and shows the intended pattern: crates/malachite-app depends on arc-signer, whose remote feature optionally pulls in arc-remote-signer — which has its own build.rs that compiles the proto definitions once. Every consumer downstream of that just links the already-built crate. No consumer needs protox/tonic-build as its own build-dependency except arc-remote-signer itself.

So crates/node's copy of this wiring isn't gating anything real — it's a feature name and two build-deps that do nothing, most likely left over from before proto compilation was consolidated into crates/remote-signer.

This is an isolated case, not a class

Checked every crate in the workspace with a [build-dependencies] section: crates/remote-signer, crates/types, and crates/version each have their own build.rs and genuinely consume their build-deps. crates/node is the only one that doesn't — so this is a single leftover, not a pattern worth a broader sweep.

Also worth noting for anyone re-verifying: arc-node-execution isn't published (publish = false at the workspace root), so there's no external consumer who could be depending on the remote-signer feature name by spelling it out — removing it breaks nothing outside this repo either.

Impact

cargo clippy --all-targets --all-features (CI) and any local --features integration build compile protox + tonic-build for arc-node-execution on every run, with zero effect — wasted build time, and a remote-signer feature name on the EL binary that misleadingly suggests it does something signing-related.

Worth noting this is invisible to the cargo hack --each-feature job proposed in #240 — it wouldn't fail a build either way, since the deps compile fine unused. It's a correctness-of-intent gap, not a build failure.

Suggested fix

Remove protox, tonic-build, the remote-signer feature, and its listing inside integration = [...] from crates/node/Cargo.toml. Nothing in the crate references any of them. Happy to send the PR.

[osr21]

Re-verified all of it against a fresh clone — every factual claim holds, plus some history and one edge worth deciding before the PR.

Confirmed:

• crates/node/Cargo.toml declares remote-signer = ["dep:protox", "dep:tonic-build"], integration = ["remote-signer"], and both optional build-deps; there is no build.rs anywhere under crates/node, and zero references to remote-signer/protox/tonic in crates/node/src/.
• Cargo.lock resolves both protox and tonic-build under arc-node-execution's dependency list, so they really are compiled when the feature activates — and it activates on every --features integration run: the Makefile's test-it/cov-unit and the CI unit-test job (cargo nextest run --workspace --features integration) all light it up transitively via integration → remote-signer. Wasted compilation on every integration-test and coverage run, exactly as described.
• Your workspace sweep is right with one clarification for future readers: crates/quake/src/build.rs also exists, but it's an ordinary module (mod build; in main.rs), not a Cargo build script — so remote-signer/types/version remain the only true build-script crates, each genuinely consuming its build-deps. Isolated case confirmed.
• The correctly-wired pattern is as you describe: proto compilation lives once in crates/remote-signer's own build.rs; consumers link the built crate.

History: git log -S "remote-signer" -- crates/node/Cargo.toml shows the wiring has been there since the initial open-source commit — it arrived dead, presumably a fossil of a pre-open-sourcing layout where the EL crate did compile protos. No later commit ever touched it, which supports "leftover," not "in-progress."

One decision for the PR — what to do with integration: nothing in crates/node is gated on feature = "integration" either (grep comes back empty), so after dropping remote-signer you have two options: keep integration = [] as an empty feature, or delete it too. The conservative choice is keeping it empty: CI invokes --features integration with --workspace, and whether cargo accepts a feature missing from some selected packages varies by invocation shape — keeping the empty feature makes the change provably inert to every existing command line without needing to reason about cargo's feature-selection edge cases. Deleting it outright is probably also fine, but then cargo nextest run --workspace --features integration becomes the thing to verify before merge, not after.

Caveat on my verification: no Rust toolchain in this environment, so the above is static (manifest, lock, grep, git history) — the one thing I couldn't do is build with and without the change and diff the compilation units. The PR's CI run will show that directly: protox/tonic-build should vanish from the EL binary's dep graph while the remote-signer crate's own build stays untouched.

The fix is low-risk, the analysis is already done, and you've pre-empted the obvious objections (not published, no external feature-name consumers, invisible to #240's each-feature matrix). +1 to sending the PR.