Each run uses a different self=enode:https://, so cannot be added to Geth trusted-peers list

[jlokier]

Geth has a trusted-peers list, where peers are recognised by enode:https:// URL. You add to this list from the Geth JavaScript console with admin.addTrustedPeer("enode:https://...@ip:port"), or in the file <datadir>/trusted-nodes.json.

Geth accepts connections from trusted peers even when they would go over the maximum peer count. It means peers Geth is always willing to serve.

Naturally this is very helpful when you want to connect to your own Geth node for syncing Nimbus, and the Geth node is already well-connected with other peers.

Unfortunately Nimbus-eth1 uses a different enode:https:// URL each time it starts, defeating the point of the trusted-peers list. It's possible to add to the list after Nimbus has started, but Nimbus won't try connecting again after it's been rejected, so that doesn't work either.

There is a file called IDENTITY which is set and retained across runs, but it's not used for the enode:https:// URL.

[jlokier]

I have a good pragmatic workaround using the --nodekey option. The test script run-nimbus-sync reads the nodekey from a location equivalent to where Geth stores its nodekey, and passes it to Nimbus.

Keeping this issue open as it would still be good to automate this in Nimbus itself.

[arnetheduck]

by default, the node id should be fresh for every startup, but for special cases one will indeed need to persist the network key and reuse it - see eth2 as well which does the same for its libp2p identity with the --netkey-file option

[jlokier]

That's interesting. Geth takes the opposite view - once you've started, it retains the same node id so you keep your peer reputation and can act as a static or trusted node. I found the Geth method more convenient. Is there a particular reason for using a new id each startup?

[KonradStaniec]

One reason for using new id on each startup is to avoid tracking of particular node i.e when ip of the node changes and node id stays the same it is easy to conclude that particular node changed location. I remember seeing and issue in geth issues list about introducing some node id rotation strategy but I am not sure if it got merged.

[arnetheduck]

I found the Geth method more convenient. Is there a particular reason for using a new id each startup?

in eth2 in particular, the node id reveals some information about the validators behind it - any trustbased system should also have a built-in notion of decay (ie trusted before != trusted now) - the exception here is when you explicitly select to trust certain nodes, though in that case it might make sense to introduce some other form of token than the node id (for example if you run N nodes, they should all connect to each other)