Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Introduce flag to enable sentry nodes to participate in grandpa gossip #3018

Merged
merged 2 commits into from
Jul 9, 2019

Conversation

mxinden
Copy link
Contributor

@mxinden mxinden commented Jul 4, 2019

Given the following situation: A validator 'A' is not supposed to be
connected to the public internet to protect it from e.g. a DoS attack.
Instead it connects to a sentry node 'sentry-A' which connects to the
public internet. Validator 'B' can reach validator 'A' via sentry node
'sentry-A' and vice versa.

A sentry node needs to participate in the grandpa gossip without
becoming a validator itself in order to forward these message to its
validator. This commit adds a new command line flag (--grandpa-voter)
forcing a node to participate in the grandpa voting process even though
no --key was specified. Due to the fact that it does not have a key,
it does not become a validator in the network.

In order to simulate the above situation this commit also adds a Docker
Compose file (scripts/sentry-node/docker-compose.yml) with further
documentation.

Parent Github issue: #2999

@mxinden mxinden added A3-in_progress Pull request is in progress. No review needed at this stage. J0-enhancement An additional feature request. labels Jul 4, 2019
@mxinden mxinden requested a review from rphmeier July 4, 2019 13:33
@parity-cla-bot
Copy link

It looks like @mxinden hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io

Once you've signed, please reply to this thread with [clabot:check] to prove it.

Many thanks,

Parity Technologies CLA Bot

1 similar comment
@parity-cla-bot
Copy link

It looks like @mxinden hasn't signed our Contributor License Agreement, yet.

The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence.
Wikipedia

You can read and sign our full Contributor License Agreement at the following URL: https://cla.parity.io

Once you've signed, please reply to this thread with [clabot:check] to prove it.

Many thanks,

Parity Technologies CLA Bot

@mxinden
Copy link
Contributor Author

mxinden commented Jul 4, 2019

[clabot:check]

@parity-cla-bot
Copy link

It looks like @mxinden signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

1 similar comment
@parity-cla-bot
Copy link

It looks like @mxinden signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

Given the following situation: A validator 'A' is not supposed to be
connected to the public internet to protect it from e.g. a DoS attack.
Instead it connects to a sentry node 'sentry-A' which connects to the
public internet. Validator 'B' can reach validator 'A' via sentry node
'sentry-A' and vice versa.

A sentry node needs to participate in the grandpa gossip without
becoming a validator itself in order to forward these message to its
validator. This commit adds a new command line flag (`--grandpa-voter`)
forcing a node to participate in the grandpa voting process even though
no `--key` was specified. Due to the fact that it does not have a key,
it does not become a validator in the network.

In order to simulate the above situation this commit also adds a Docker
Compose file (`scripts/sentry-node/docker-compose.yml`) with further
documentation.
Copy link
Contributor

@andresilva andresilva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should instead add a --sentry flag and make sure local_key is None even if the user provides a --key argument. In the future we might have some more changes for sentry mode so that's why I'm suggesting adding a sentry flag now.

@mxinden
Copy link
Contributor Author

mxinden commented Jul 5, 2019

Maybe we should instead add a --sentry flag

@rphmeier was voting against calling the flag --sentry as users might want to run a grandpa voter outside of the context of a sentry node. While maybe impacting sentry user experience it does make the binary more versatile.

@andresilva What do you think?

@rphmeier
Copy link
Contributor

rphmeier commented Jul 5, 2019

@mxinden we can always add a --sentry flag which implies a number of other options later. But it's nice to have the flag for running a keyless GRANDPA voter.

@mxinden
Copy link
Contributor Author

mxinden commented Jul 5, 2019

@mxinden we can always add a --sentry flag which implies a number of other options later. But it's nice to have the flag for running a keyless GRANDPA voter.

Sounds good to me @rphmeier.


@andresilva and @rphmeier any further comments other than the flag renaming?

@mxinden mxinden marked this pull request as ready for review July 8, 2019 08:31
@mxinden mxinden changed the title [WIP] Introduce flag to enable sentry nodes to participate in grandpa gossip Introduce flag to enable sentry nodes to participate in grandpa gossip Jul 8, 2019
@rphmeier
Copy link
Contributor

rphmeier commented Jul 8, 2019

@mxinden is it still in-progress or ready for review?

@mxinden
Copy link
Contributor Author

mxinden commented Jul 8, 2019

@rphmeier ready for review.

@rphmeier rphmeier added A0-please_review Pull request needs code review. and removed A3-in_progress Pull request is in progress. No review needed at this stage. labels Jul 8, 2019
@rphmeier
Copy link
Contributor

rphmeier commented Jul 8, 2019

(then you should put the pleasereview label on, otherwise people will skip it :) )

Copy link
Contributor

@andresilva andresilva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, just a minor grumble in the docker compose file (I'm not sure how useful it is to be committed but won't grumble on that).

# - "--validator"
- "--name"
- "CharliesNode"
- "--bootnodes"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe use --reserved-nodes here instead? Same for the other nodes configs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind adding some more details @andresilva?

If I understand correctly, validator addresses can change at runtime. Thus if the address of validator-b changes, sentry-a would need to be restarted. I would suggest only interconnecting validator-a and sentry-a as reserved nodes and sentry-a and validator-b as bootstrap nodes, given that a and b are controlled by different entities.

What do you think?

On a side note, I am currently looking into how a user can tell a validator node to keep x amount of connections open to other validator nodes. As the validator address set can change at runtime, these long-lived connections would also be adjusted along the way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this config A connects to B (through bootnodes). The sentry connects to A and B, and B also tries to connect with A.

My understanding is that in a real scenario the validator nodes that are using a sentry will only be connected to the sentry (or multiple sentries). So I think in this config Validator-A should set Sentry-A as a reserved node (so that it only connects to this node), and the rest of the nodes (Sentry-A and Validator-B) can add everyone as bootnode (even though Validator-B won't be able to connect to Validator-A).

@mxinden
Copy link
Contributor Author

mxinden commented Jul 9, 2019

Guessing from the contributing guidelines I am the one squashing and merging this pull request.

Generally PRs should sit with this label for 48 hours in order to garner feedback.

I will wait for a little longer and then merge if their are no objections.

@bkchr
Copy link
Member

bkchr commented Jul 9, 2019

Just merge it :)

@mxinden
Copy link
Contributor Author

mxinden commented Jul 9, 2019

(I'm not sure how useful it is to be committed but won't grumble on that)

@andresilva I am also fine with removing it. No strong opinion. Just thought it might be helpful documenting the use case as code.

@gavofyork gavofyork added A8-looksgood and removed A0-please_review Pull request needs code review. J0-enhancement An additional feature request. labels Jul 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants