1.1.Node identity

All cryptographic operations are based on the secp256k1 elliptic curve. Each node is expected to maintain a static secp256k1 private key which is saved and restored between sessions. It is recommended that the private key can only be reset manually, for example, by deleting a file or database entry.

Every node has a cryptographic identity, a key on the secp256k1 elliptic curve. The public key of the node serves as its identifier or ‘node ID’.

Node records are signed according to an ‘identity scheme’. Any scheme can be used with Node Discovery Protocol, and nodes using different schemes can communicate. The identity scheme of a node record defines how a 32-byte ‘node ID’ is derived from the information contained in the record.

• To derive a node address, take the keccak256 hash of the uncompressed public key, i.e. keccak256(x || y). Note that x and y must be zero-padded up to length 32.

Peer IDs are derived by hashing the encoded public key with multihash. Keys that serialize to more than 42 bytes must be hashed using sha256 multihash, keys that serialize to at most 42 bytes must be hashed using the “identity” multihash codec.

Specifically, to compute a peer ID of a key:

1. Encode the public key as described in the keys section.
2. If the length of the serialized bytes is less than or equal to 42, compute the “identity” multihash of the serialized bytes. In other words, no hashing is performed, but the multihash format is still followed (byte plus varint plus serialized bytes). The idea here is that if the serialized byte array is short enough, we can fit it in a multihash verbatim without having to condense it using a hash function.
3. If the length is greater than 42, then hash it using the SHA256 multihash.

String representation

There are two ways to represent peer IDs in text: as a raw base58btc encoded multihash (e.g., Qm..., 1...) and as a multibase encoded CID (e.g., bafz...). Libp2p is slowly transitioning from the first (legacy) format to the second (new).

Implementations MUST support parsing both forms of peer IDs. Implementations SHOULD display peer IDs using the first (raw base58btc encoded multihash) format until the second format is widely supported.

Peer IDs encoded as CIDs must be encoded using CIDv1 and must use the libp2p-key multicodec (0x72). By default, such peer IDs SHOULD be encoded in using the base32 multibase (RFC4648, without padding).

For reference, CIDs (encoded in text) have the following format

<multibase-prefix><cid-version><multicodec><multihash>