Use Ed25519 for libp2p-level signing

[webmaster128]

When creating a chainspec including boot nodes, libp2p public keys are included, e.g.

  "bootNodes": [
    "/ip4/11.22.33.44/tcp/30333/p2p/QmSZcgM3nxwKMgDuy1FgoDVYbT7nSucwa7s8qnF9o7J8E6"
  ],

This public key is derived from a keypair set via --node-key, which can be auto-generated by substrate. Now if you create the initial bootNodes, the --node-keys must be known at build-spec time. This can be archived by an admin using

cat /dev/urandom | head -c 32 | xxd -p -c 256 > ~/.node_key
substrate --chain=staging --node-key "$(< ~/.node_key)" build-spec ...

As discussed in Rewrite the libp2p networking #742, secp256k1 is used for libp2p-level signing. The problem is: not every 32 byte key is a valid secp256k1 key (value must be < 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141). If we switch to Ed25519, we know that every 32 bytes key is a valid private key. Thus no special secp256k1 tooling is required to generate --node-keys.

[tomaka]

We need an update strategy for existing keys, especially for the bootstrap nodes.
I suggest: if there's an existing file and it is 32 bytes, then we're going to assume it's secpk256k1, and we'll replace the content of the file with a small JSON struct that contains both the key and the type of the key.

[webmaster128]

I think there are two representations currently used:

1. a raw 32 bytes files that is automatically generated by substrate
2. a 64 chars hex command line argument

Changing to JSON means you'd need to pass a JSON string as a command line argument, which is not the most convenient thing to do. What about using strings consistently between file storage and command line argument?

ed25519:a7ddfe6f3b79f6bbeea5279d34459a044e0ce542587dd0b161c8d10a8b43490c
secp256k1:a7ddfe6f3b79f6bbeea5279d34459a044e0ce542587dd0b161c8d10a8b43490c
a7ddfe6f3b79f6bbeea5279d34459a044e0ce542587dd0b161c8d10a8b43490c

where the last version defaults to secp256k1

[tomaka]

Sorry, I was thinking only about the content of the file in ~/.local/Substrate/chains/.../secret when I was talking about a JSON data structure.

What I had in mind is to just assume that keys passed through the CLI are now ed25519, but you're right that specifying the format might be a good idea.

[tomaka]

Also libp2p is missing a method to load an already-known ed25519 key.

cc libp2p/rust-libp2p#807

[tomaka]

cc libp2p/rust-libp2p#890

Libp2p master contains a breaking change though, so let's wait for version 0.3 before upgrading.

[tomaka]

cc #1634

[tomaka]

Note that libp2p also now supports the Noise protocol (https://docs.rs/libp2p/0.3.1/libp2p/noise/index.html). Switching to Ed25519 makes it possible to use Noise.

[tomaka]

#2290 switched to ed25519 keys by default.