Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[net/libp2p] Use raw Identify observed addresses to discover external addresses #7338

Merged
merged 6 commits into from
Jan 28, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions prdoc/pr_7338.prdoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
title: '[net/libp2p] Use raw `Identify` observed addresses to discover external addresses'
doc:
- audience: Node Dev
description: |-
Instead of using libp2p-provided external address candidates, susceptible to address translation issues, use litep2p-backend approach based on confirming addresses observed by multiple peers as external.

Fixes https://github.com/paritytech/polkadot-sdk/issues/7207.
crates:
- name: sc-network
bump: major
2 changes: 2 additions & 0 deletions substrate/client/network/src/behaviour.rs
Original file line number Diff line number Diff line change
Expand Up @@ -184,6 +184,7 @@ impl<B: BlockT> Behaviour<B> {
request_response_protocols: Vec<ProtocolConfig>,
peer_store_handle: Arc<dyn PeerStoreProvider>,
external_addresses: Arc<Mutex<HashSet<Multiaddr>>>,
public_addresses: Vec<Multiaddr>,
connection_limits: ConnectionLimits,
) -> Result<Self, request_responses::RegisterError> {
Ok(Self {
Expand All @@ -192,6 +193,7 @@ impl<B: BlockT> Behaviour<B> {
user_agent,
local_public_key,
external_addresses,
public_addresses,
),
discovery: disco_config.finish(),
request_responses: request_responses::RequestResponsesBehaviour::new(
Expand Down
3 changes: 3 additions & 0 deletions substrate/client/network/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -291,6 +291,9 @@ pub use service::{
};
pub use types::ProtocolName;

/// Log target for `sc-network`.
const LOG_TARGET: &str = "sub-libp2p";

/// The maximum allowed number of established connections per peer.
///
/// Typically, and by design of the network behaviours in this crate,
Expand Down
11 changes: 5 additions & 6 deletions substrate/client/network/src/litep2p/discovery.rs
Original file line number Diff line number Diff line change
Expand Up @@ -50,6 +50,7 @@ use schnellru::{ByLength, LruMap};
use std::{
cmp,
collections::{HashMap, HashSet, VecDeque},
iter,
num::NonZeroUsize,
pin::Pin,
sync::Arc,
Expand All @@ -72,11 +73,9 @@ const GET_RECORD_REDUNDANCY_FACTOR: usize = 4;
/// The maximum number of tracked external addresses we allow.
const MAX_EXTERNAL_ADDRESSES: u32 = 32;

/// Minimum number of confirmations received before an address is verified.
///
/// Note: all addresses are confirmed by libp2p on the first encounter. This aims to make
/// addresses a bit more robust.
const MIN_ADDRESS_CONFIRMATIONS: usize = 2;
/// Number of times observed address is received from different peers before it is confirmed as
/// external.
const MIN_ADDRESS_CONFIRMATIONS: usize = 3;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are now waiting for 3 confirmations in an LRU of 32 addresses. Are we losing precision somehow with this setup? Should we bump MAX_EXTERNAL_ADDRESSES to a higher value, or are we able to discover addresses just like before?

Copy link
Contributor Author

@dmitry-markin dmitry-markin Jan 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was a bug, and when we received the address for the first time we inserted an empty hash map, and only after that counted confirmations. So it was always 3 confirmations, just the information about the first peer ID we got the address from was lost.


/// Discovery events.
#[derive(Debug)]
Expand Down Expand Up @@ -509,7 +508,7 @@ impl Discovery {
.flatten()
.flatten();

self.address_confirmations.insert(address.clone(), Default::default());
self.address_confirmations.insert(address.clone(), iter::once(peer).collect());

return (false, oldest)
},
Expand Down
Loading
Loading