Generate PeerIDs given a target common prefix length (CPL)

[vbhattaccmu]

Generate PeerIDs given a target common prefix length (CPL)

[thomaseizinger]

We tend to be very conservative in what functionality we add to libp2p-identity because it is a dependency of the entire libp2p ecosystem.
Given that PeerId offers, from_bytes, am I right to assume that you can implement this on top of the APIs that are currently offered and it doesn't necessarily have to live in libp2p-identity?
Before we add an API like this, I'd like to first see it pulling its weight in where we use it.

Yes, it doesn't need to reside in libp2p-identity. This is mostly useful inside Kademlia.

Cool, thanks for the confirmation! Optimising DHT queries is definitely something we are very open to :)

[vbhattaccmu]

I have been able to successfully generate peer ids from the existing APIs provided using to_bytes() and from_multihash(). I will reach out with a separate pull request on an added method to optimize DHT queries in a while. Would like to close this for now as my issue has been resolved. Thanks!!

[mxinden]

@vbhattaccmu the two snippets below might give some additional inspiration:

rust-libp2p/protocols/kad/src/behaviour.rs

Lines 1349 to 1372 in bb2b798

	.map(|b| {
	// Try to find a key that falls into the bucket. While such keys can
	// be generated fully deterministically, the current libp2p kademlia
	// wire protocol requires transmission of the preimages of the actual
	// keys in the DHT keyspace, hence for now this is just a "best effort"
	// to find a key that hashes into a specific bucket. The probabilities
	// of finding a key in the bucket `b` with as most 16 trials are as
	// follows:
	//
	// Pr(bucket-255) = 1 - (1/2)^16 ~= 1
	// Pr(bucket-254) = 1 - (3/4)^16 ~= 1
	// Pr(bucket-253) = 1 - (7/8)^16 ~= 0.88
	// Pr(bucket-252) = 1 - (15/16)^16 ~= 0.64
	// ...
	let mut target = kbucket::Key::from(PeerId::random());
	for _ in 0..16 {
	let d = local_key.distance(&target);
	if b.contains(&d) {
	break;
	}
	target = kbucket::Key::from(PeerId::random());
	}
	target
	})

rust-libp2p/misc/keygen/src/main.rs

Lines 71 to 111 in bb2b798

	// Generate a random keypair, optionally with a prefix
	Command::Rand { prefix } => {
	if let Some(prefix) = prefix {
	if prefix.as_bytes().iter().any(|c| !ALPHABET.contains(c)) {
	eprintln!("Prefix {prefix} is not valid base58");
	std::process::exit(1);
	}
	// Checking conformity to ALLOWED_FIRST_BYTE.
	if !prefix.is_empty() && !ALLOWED_FIRST_BYTE.contains(&prefix.as_bytes()[0]) {
	eprintln!("Prefix {prefix} is not reachable");
	eprintln!(
	"Only the following bytes are possible as first byte: {}",
	str::from_utf8(ALLOWED_FIRST_BYTE).unwrap()
	);
	std::process::exit(1);
	}
	let (tx, rx) = mpsc::channel::<(PeerId, identity::Keypair)>();
	// Find peer IDs in a multithreaded fashion.
	for _ in 0..thread::available_parallelism()?.get() {
	let prefix = prefix.clone();
	let tx = tx.clone();
	thread::spawn(move || loop {
	let keypair = identity::Keypair::generate_ed25519();
	let peer_id = keypair.public().to_peer_id();
	let base58 = peer_id.to_base58();
	if base58[8..].starts_with(&prefix) {
	tx.send((peer_id, keypair)).expect("to send");
	}
	});
	}
	rx.recv().expect("to recv")
	} else {
	let keypair = identity::Keypair::generate_ed25519();
	(keypair.public().into(), keypair)
	}
	}

[thomaseizinger]

We tend to be very conservative in what functionality we add to libp2p-identity because it is a dependency of the entire libp2p ecosystem.

Given that PeerId offers, from_bytes, am I right to assume that you can implement this on top of the APIs that are currently offered and it doesn't necessarily have to live in libp2p-identity?

Before we add an API like this, I'd like to first see it pulling its weight in where we use it.

[thomaseizinger]

Before we add an API like this, I'd like to first see it pulling its weight in where we use it.

For example, it appears that this is mostly useful for Kademlia so it could also just be a private function in kademlia somewhere and doesn't have to go into the public API of PeerId.

[vbhattaccmu]

We tend to be very conservative in what functionality we add to libp2p-identity because it is a dependency of the entire libp2p ecosystem.

Given that PeerId offers, from_bytes, am I right to assume that you can implement this on top of the APIs that are currently offered and it doesn't necessarily have to live in libp2p-identity?

Before we add an API like this, I'd like to first see it pulling its weight in where we use it.

Yes, it doesn't need to reside in libp2p-identity. This is mostly useful inside Kademlia.