Have the bridge use HD ephemeral identities

[pipermerriam]

What is wrong

IIUC the bridge generates a new ephemeral key each time it boots up leaving us with a lot of single use entries in our census data.

How can it be fixed

ethereum/devp2p#254

I propose we default the bridge to operate using ephemeral HD identities. THere would be a single persistent "parent key". Each time the bridge runs it would randomly generate a new "path" in order to generate a child key that it would use as it's private key for that run. The ENR record would be updated to include the "parent key" and "path" so that glados would be able to link these ephemeral identities together.

[njgheorghita]

Is there another motivation for implementing this? Aka, testing out this scheme for the case where a single user with 100gb available storage spins up 10 x 10gb nodes derived from a parent key...

There have been some concerns in the past about letting the ENR grow too large, even adding a single character for the client type wasn't quickly adopted.

The simplest fix in this scenario is to simply use a consistent private key for the bridge, which we already support, it's just not enabled in our deployment scripts.

[pipermerriam]

Yes, this would also be part of supporting ethereum/portal-network-specs#283