Sentry nodes and validator nodes also imply reserved

[tomaka]

I'm totally lost in where we are in that, but here's a PR that adds sentry nodes and validator nodes as reserved. In other words --sentry and --sentry-node also imply --reserved-node.

[bkchr]

Why not below this match:

reserved_nodes.extend(sentries_and_validators.iter());

?

[bkchr]

And maybe a test to ensure that we don't refactor this away in the future?

[tomaka]

We will refactor this away in the future.

[tomaka]

Like, this entire code is a hack. We pass a magic string "reserved" in a list called priority_groups. This isn't a clean way of doing things.

[mxinden]

I might be missing something here. I understand the flags as such:

--sentry: The private addresses of the validator nodes one is sentrying. (Should be added as reserved nodes.)

--senytr-nodes: The public addresses of the sentry nodes of a validator. Used to advertise them on the DHT. (Should not be added as reserved nodes as a validator should connect to its sentry nodes via their private addresses.)

I guess this is highly dependent on the setup (e.g. whether one uses private IPv4 addresses or public-only IPv6 addresses).

[mxinden]

In most setups I would expect sentry nodes to have a public and a private IP addresses. From the outside nodes can reach a sentry node via its public IP addresses, validators can reach their sentry node via their private IP address.

I would expect sentry_nodes to contain the public multiaddresses of the sentry nodes of a validator.

Does it make sense to have a validator connect to its sentry node via its public address as a reserved node?

[mxinden]

Ah, sorry, we are only adding the nodes by their peer id which would be the same for both the public as well as the private address. One would still need to pass the private addresses of ones sentry via the --reserved flag though.

[tomaka]

For user-friendliness, I would be of the opinion to let the sentry nodes automatically inform their validator about their external IP addresses.

[mxinden]

I expect both validators as well as sentry nodes to be deployed via some kind of configuration management tool (e.g. Ansible). In addition I expect a sentry nodes IP addresses not to change during the lifetime of both sentry as well as validator.

Thereby I would prefer not to introduce a long running protocol between sentry and validator to inform the latter of the IP of the former, but instead push this complexity to the configuration management tool.

[burdges]

I suppose certifying transport keys might impact your choices somewhat:

We should eventually sign some certificate for sentries' transport key, almost surely an x509 certificate for the sentries' TLS keys. I'd think the transport certifying key could be an Ed25519 key listed on-chain.

We could discuss the validator itself signing this certificate, but maybe this complicates the validator discovering its sentries, not sure.

If transport certifying key lives elsewhere then maybe the sentry authenticates itself directly to the validator, which make launching a sentry (resp. outer sentry) as easy as providing it its certificate and telling it the IP address for the validator (resp. secret inner sentry).

In either case, we'd do revocation by replacing the transport certifying key on-chain, and issuing all new certificates with the new key, which sucks but hey.