client/authority-discovery: Allow to be run by sentry node #5568
Conversation
When run as a sentry node, the authority discovery module does not publish any addresses to the dht, but still discovers validators and sentry nodes of validators.
mxinden
added
A0-please_review
| use sp_core::traits::BareCryptoStorePtr; | ||
| use sp_runtime::{traits::Block as BlockT, generic::BlockId}; | ||
| use sp_api::ProvideRuntimeApi; | ||
| // TODO: Needed? |
There was a problem hiding this comment.
| // TODO: Needed? |
There is an unused import, but it's not this one.
|
Does not compile. |
andresilva
left a comment
andresilva
left a comment
There was a problem hiding this comment.
minor nits. overall lgtm.
bin/node/cli/src/service.rs
Outdated
| let sentries; | ||
| let authority_discovery_role; | ||
|
|
||
| match role { | ||
| sc_service::config::Role::Authority { ref sentry_nodes } => { | ||
| sentries = sentry_nodes.clone(); | ||
| authority_discovery_role = sc_authority_discovery::Role::Authority ( | ||
| service.keystore(), | ||
| ); | ||
| } | ||
| sc_service::config::Role::Sentry {..} => { | ||
| sentries = vec![]; | ||
| authority_discovery_role = sc_authority_discovery::Role::Sentry; | ||
| } | ||
| _ => unreachable!("Due to outer matches! constraint; qed.") | ||
| } |
There was a problem hiding this comment.
| let sentries; | |
| let authority_discovery_role; | |
| match role { | |
| sc_service::config::Role::Authority { ref sentry_nodes } => { | |
| sentries = sentry_nodes.clone(); | |
| authority_discovery_role = sc_authority_discovery::Role::Authority ( | |
| service.keystore(), | |
| ); | |
| } | |
| sc_service::config::Role::Sentry {..} => { | |
| sentries = vec![]; | |
| authority_discovery_role = sc_authority_discovery::Role::Sentry; | |
| } | |
| _ => unreachable!("Due to outer matches! constraint; qed.") | |
| } | |
| let (sentries, authority_discovery_role) = match role { | |
| sc_service::config::Role::Authority { ref sentry_nodes } => ( | |
| sentry_nodes.clone(), | |
| sc_authority_discovery::Role::Authority(service.keystore()), | |
| ), | |
| sc_service::config::Role::Sentry { .. } => ( | |
| vec![], | |
| sc_authority_discovery::Role::Sentry, | |
| ), | |
| _ => unreachable!("Due to outer matches! constraint; qed."), | |
| }; |
There was a problem hiding this comment.
Maybe we should move this code into some method in authority discovery so that we can re-use it in polkadot service. Do you think it would make sense for the AuthorityDiscovery::new to take sc_service::config::Role? Or maybe add a new constructor that takes it.
There was a problem hiding this comment.
I did have AuthorityDiscovery::new not take sc_service::config::Role for two reasons:
-
Make the authority discovery module independent of the underlying network.
-
Make it impossible at compile time to pass a key store as a sentry or to not pass a key store as a validator.
Does the above sound reasonable @andresilva ? If you think the additional code in cli/service is not worth the benefits above I can move it into the authority discovery module.
There was a problem hiding this comment.
Yeah, I didn't think of the sc_service dependency and also appreciate that keystore requirement is validated statically. Let's keep it in cli/service then.
I still prefer the code as written in my suggestion (I didn't test it, just wrote it in Github), mainly because I prefer expressions over statements. 😊
There was a problem hiding this comment.
Ah, sorry I that I oversaw your suggestion @andresilva. Indeed a lot better. 57d141d.
| fn get_own_public_keys_within_authority_set( | ||
| key_store: &BareCryptoStorePtr, | ||
| client: &Client, | ||
| ) -> Result<HashSet<AuthorityId>> { |
There was a problem hiding this comment.
If we just kept this method as is and made it return an empty HashSet instead for sentries, couldn't we keep the rest of the logic above unchanged? I guess we could still keep the early exit in the method above.
There was a problem hiding this comment.
I am not sure returning an empty HashSet for sentry nodes would be more expressive. This reminds me of C code returning -1 on error.
Do you think the changes above are intrusive?
Co-Authored-By: André Silva <[email protected]>
mxinden
left a comment
mxinden
left a comment
There was a problem hiding this comment.
@andresilva thanks for the review! Would you mind taking another look?
bin/node/cli/src/service.rs
Outdated
| let sentries; | ||
| let authority_discovery_role; | ||
|
|
||
| match role { | ||
| sc_service::config::Role::Authority { ref sentry_nodes } => { | ||
| sentries = sentry_nodes.clone(); | ||
| authority_discovery_role = sc_authority_discovery::Role::Authority ( | ||
| service.keystore(), | ||
| ); | ||
| } | ||
| sc_service::config::Role::Sentry {..} => { | ||
| sentries = vec![]; | ||
| authority_discovery_role = sc_authority_discovery::Role::Sentry; | ||
| } | ||
| _ => unreachable!("Due to outer matches! constraint; qed.") | ||
| } |
There was a problem hiding this comment.
I did have AuthorityDiscovery::new not take sc_service::config::Role for two reasons:
-
Make the authority discovery module independent of the underlying network.
-
Make it impossible at compile time to pass a key store as a sentry or to not pass a key store as a validator.
Does the above sound reasonable @andresilva ? If you think the additional code in cli/service is not worth the benefits above I can move it into the authority discovery module.
| fn get_own_public_keys_within_authority_set( | ||
| key_store: &BareCryptoStorePtr, | ||
| client: &Client, | ||
| ) -> Result<HashSet<AuthorityId>> { |
There was a problem hiding this comment.
I am not sure returning an empty HashSet for sentry nodes would be more expressive. This reminds me of C code returning -1 on error.
Do you think the changes above are intrusive?
|
Needs merge with master to fix conflicts. |
When run as a sentry node, the authority discovery module does not
publish any addresses to the dht, but still discovers validators and
sentry nodes of validators.
polkadot companion: paritytech/polkadot#984