Release 2026.4.2: ant-node 0.11.0

[jacderida]

Summary

• Promote RC branch rc-2026.4.2 to main
• Bump ant-node from 0.11.0-rc.2 to 0.11.0
• Upgrade saorsa-core from the RC branch git dependency back to the published crates.io 0.24.0 release (which pulls in saorsa-transport 0.33.0)
• Refresh Cargo.lock

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Release promotion to ant-node 0.11.0, switching saorsa-core back to the crates.io 0.24.0 release and refreshing the lockfile, while adding a merkle-payment “pay-yourself” defence that verifies candidate closeness against the live DHT (and wiring P2P into the verifier across runtime paths).

Changes:

• Bump ant-node to 0.11.0, update saorsa-core to 0.24.0 (crates.io), and refresh Cargo.lock.
• Add merkle candidate “closeness” verification in PaymentVerifier with caching/single-flight to reduce lookup cost.
• Wire P2PNode into the payment verifier in production/devnet/e2e startup and add an e2e test for the fabricated-candidate-pool (“pay-yourself”) attack.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/payment/verifier.rs	Implements DHT-based merkle candidate closeness checks plus caching/single-flight and associated unit tests.
src/node.rs	Attaches the live P2PNode to the payment verifier during node startup.
src/devnet.rs	Attaches P2PNode to the payment verifier for devnet nodes.
tests/e2e/testnet.rs	Attaches P2PNode to the payment verifier in the e2e test harness startup.
tests/e2e/merkle_payment.rs	Adds an e2e attack test for fabricated merkle candidate pools (“pay-yourself”).
Cargo.toml	Bumps crate version and switches saorsa-core from a git dependency to 0.24.0 on crates.io.
Cargo.lock	Lockfile refresh consistent with dependency/version updates.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The closeness match count can be artificially inflated by duplicate candidates. matched is computed by iterating all candidate PeerIds and counting set membership, but it does not enforce that candidate pub_key/PeerId values are unique. An attacker who runs (or grinds) a single real close peer could repeat that same pub_key across many of the 16 candidates and satisfy the CANDIDATE_CLOSENESS_REQUIRED threshold without having 13 distinct close peers. Consider rejecting pools with duplicate derived PeerIds and/or counting unique matches (e.g., intersect the set of candidate PeerIds with the network set).

Suggested change

	// list counts as unmatched.
	let network_set: std::collections::HashSet<PeerId> =
	network_peers.iter().map(|n| n.peer_id).collect();
	let matched = candidate_peer_ids
	// list counts as unmatched. Candidate pub_keys / PeerIds must also be
	// unique, otherwise duplicate entries could artificially inflate the
	// closeness match count.
	let network_set: std::collections::HashSet<PeerId> =
	network_peers.iter().map(|n| n.peer_id).collect();
	let candidate_set: std::collections::HashSet<PeerId> =
	candidate_peer_ids.iter().copied().collect();
	if candidate_set.len() != candidate_peer_ids.len() {
	debug!(
	"Merkle closeness rejected: duplicate candidate PeerIds for pool midpoint {}",
	hex::encode(pool_address.0),
	);
	return Err(Error::Payment(
	"Merkle candidate pool rejected: candidate pub_keys must derive to distinct \
	PeerIds. Duplicate candidates are not allowed."
	.into(),
	));
	}
	let matched = candidate_set

[Copilot]

inflight_closeness is stored in an LruCache, which can evict entries under pressure. If an inflight slot for a given pool_hash is evicted before the leader finishes, new callers won’t find it and will start a second lookup for the same pool_hash, breaking the single-flight/DoS-amplification guarantee described in the comment. Using a non-evicting map for inflight state (and removing on completion), or a dedicated structure sized by actual concurrency, would preserve single-flight semantics for a pool_hash.

Suggested change

	/// In-flight closeness lookups, keyed by pool hash. Lets concurrent PUTs
	/// for the same pool coalesce onto a single Kademlia lookup AND share
	/// its result — on both success and failure — which bounds `DoS`
	/// amplification to one lookup per unique `pool_hash` regardless of
	/// concurrency.
	inflight_closeness: Mutex<LruCache<PoolHash, Arc<ClosenessSlot>>>,
	/// In-flight closeness lookups, keyed by pool hash. This must be a
	/// non-evicting map so an active leader's slot cannot disappear before it
	/// publishes its result; entries are removed explicitly on completion.
	/// Lets concurrent PUTs for the same pool coalesce onto a single Kademlia
	/// lookup AND share its result — on both success and failure — which
	/// bounds `DoS` amplification to one lookup per unique `pool_hash`
	/// regardless of concurrency.
	inflight_closeness:
	Mutex<std::collections::HashMap<PoolHash, Arc<ClosenessSlot>>>,

[Copilot]

This test is intended to validate the single-flight behavior under concurrency, but on the current code path the inner check can complete immediately (fail-open under cfg(test) when no P2PNode is attached). In that case tokio::join! may not actually overlap the two calls, so the test can pass even if coalescing is broken. Consider adding an explicit synchronization point (e.g., barrier/notify) so one task becomes the leader and blocks before publishing, while the second task is forced into the waiter path and must observe the leader’s published result.

[Copilot]

The comment says the per-node payment should be 1024 * 2^2 / 2 = 2048, but per_node is set to 4096. Overpaying may still make the proof pass (since verification checks >= expected_per_node), but the mismatch makes the test harder to reason about and can hide regressions in the payment formula. Consider either setting per_node to 2048 or updating the comment to match the intended overpayment.

Suggested change

	let per_node = Amount::from(4096u64);
	let per_node = Amount::from(2048u64);