DiscV5: New HDWallet based identity scheme.

[pipermerriam]

HD-Identity scheme

The idea is to introduce a new identity scheme for the Discovery V5 network. This new identity scheme would be based on the BIP32 Hierarchical Deterministic Wallet scheme.

The identity would be a combination of the parent key and the derivation path for the child key, with the child-key being the node-id exposed to the network.

Motivation

In the Portal Network, we have two use cases for this.

First, is for our bridge infrastructure. These nodes are responsible for injecting content into the network. We want them to be able to operate in the network using ephemeral node-ids that are use for a brief period of time (minutes/hours) after which they cycle to a new location in the network. It would be useful for us to be able to link all of these nodes together in our network monitoring infrastructure so that we can know that they are all effectively the same machine as we gather metrics and information about the size and shape of our network.

Second, is for large nodes. The way Portal is constructed, it is ineffective for a node to store significantly above average amounts of data. For this reason, we want to architect our clients so that above certain thresholds, a node will "split" itself into multiple identities on the network. A single client that concurrently operates multiple node-ids on the network. It would be ideal to be able to cryptographicaly link these node-ids together in our monitoring infrastructure so that we can get an accurate picture of the network size.

@fjl is this something you'd be willing to entertain adding to the protocol?

[fjl]

It sounds like you want this as an ENR identity scheme? So there would be another entry for the derivation path in the ENR, and it would be used to derive the node ID. It would definitely work...

However I am curious about the motivation. You mention the 'monitoring infrastructure' two times. If this is just to tie 'logical nodes' together for analysis purposes, you wouldn't actually need an identity scheme. You are free to announce the base key and derivation path in the ENR in addition to the secp256k1 key used for the node ID. That would still allow observers of the network to figure out which nodes are related (and verify the derivation...) but it'd be less changes to the protocol itself.