p2p: add flag to disable snap/1 serving

[lucca30]

Changes

Adds a new p2p.nosnap config flag (nosnap in TOML under [p2p]) that decouples the snapshot tree from the snap/1 p2p sub-protocol.

The problem: before this change, --snapshot and snap/1 were hardcoded together — enabling the snapshot tree automatically registered snap/1. There was no way to have one without the other.

Why BPs want the snapshot tree: the flat snapshot accelerates state reads without trie traversal, benefiting both RPC queries and block building (every SLOAD, balance check, and storage read during EVM execution can hit the snapshot instead of walking the trie).

Why BPs don't want to serve snap/1: BPs are already fully synced and have no reason to be snap sync servers for other nodes. Serving snap/1 adds unnecessary network and CPU overhead.

Important clarification — snap/1 vs --snapshot:

• snap/1 is the p2p sub-protocol used for snap sync state transfer between nodes. Data is served from the flat snapshot, Merkle proofs from the trie DB on disk
• --snapshot / SnapshotCache is the in-memory flat snapshot tree used for fast local state reads

These are independent. nosnap=true disables snap/1 entirely (the node neither serves nor consumes snap sync), while the snapshot tree remains fully active for local performance.

Note: reducing TriesInMemory (dirty trie layers in memory) is a separate and independent optimization — it saves RAM by committing trie nodes to disk sooner. It does not affect snap/1 serving, which reads from the flat snapshot, not trie layers.

How it works

• New NoSnapServing bool field in ethconfig.Config
• Wired from P2PConfig.NoSnapServing (hcl:"nosnap" / toml:"nosnap") through buildEth
• In Protocols(), snap/1 is only registered if SnapshotCache > 0 && !NoSnapServing — previously the condition was SnapshotCache > 0 alone, making snapshot and snap/1 inseparable

Testing

• Unit test in eth/backend_protocols_test.go covering both the default (snap served) and NoSnapServing=true (snap not served) cases
• Validated end-to-end in a local kurtosis devnet: nodes with nosnap = true started without advertising snap/1

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.53%. Comparing base (2a0bfe7) to head (0326622).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #2152      +/-   ##
===========================================
+ Coverage    51.51%   51.53%   +0.02%     
===========================================
  Files          882      882              
  Lines       154140   154149       +9     
===========================================
+ Hits         79403    79440      +37     
+ Misses       69559    69533      -26     
+ Partials      5178     5176       -2     

Files with missing lines	Coverage Δ
eth/backend.go	52.62% <100.00%> (+0.41%)	⬆️
eth/ethconfig/config.go	78.94% <ø> (ø)
internal/cli/server/config.go	65.03% <100.00%> (+0.05%)	⬆️
internal/cli/server/flags.go	100.00% <100.00%> (ø)

... and 21 files with indirect coverage changes

Files with missing lines	Coverage Δ
eth/backend.go	52.62% <100.00%> (+0.41%)	⬆️
eth/ethconfig/config.go	78.94% <ø> (ø)
internal/cli/server/config.go	65.03% <100.00%> (+0.05%)	⬆️
internal/cli/server/flags.go	100.00% <100.00%> (ø)

... and 21 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[manav2401]

Won't this disable snap/1 completely from being registered? In which case the node won't be able to sync from snap.

I think it's fine - but we can mention this fact in comment / description.

Basically, if we want to sync from snap, we can set nosnap to false which will allow snap/1 to be registered.