-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Introduce flag to enable sentry nodes to participate in grandpa gossip #3018
Conversation
It looks like @mxinden hasn't signed our Contributor License Agreement, yet.
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 Many thanks, Parity Technologies CLA Bot |
1 similar comment
It looks like @mxinden hasn't signed our Contributor License Agreement, yet.
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 Many thanks, Parity Technologies CLA Bot |
[clabot:check] |
It looks like @mxinden signed our Contributor License Agreement. 👍 Many thanks, Parity Technologies CLA Bot |
1 similar comment
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.
There was a problem hiding this 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.
@rphmeier was voting against calling the flag @andresilva What do you think? |
@mxinden we can always add a |
Sounds good to me @rphmeier. @andresilva and @rphmeier any further comments other than the flag renaming? |
@mxinden is it still in-progress or ready for review? |
@rphmeier ready for review. |
(then you should put the pleasereview label on, otherwise people will skip it :) ) |
There was a problem hiding this 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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
).
Guessing from the contributing guidelines I am the one squashing and merging this pull request.
I will wait for a little longer and then merge if their are no objections. |
Just merge it :) |
@andresilva I am also fine with removing it. No strong opinion. Just thought it might be helpful documenting the use case as code. |
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 furtherdocumentation.
Parent Github issue: #2999