Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[node] Add plumbing that allows authorities to connect to other authorities #1610

Merged
merged 2 commits into from
Apr 28, 2022

Conversation

gdanezis
Copy link
Collaborator

We add the plumbing necessary for an authority to initiate connections to other authorities. This will be used for the 'active' logic of authorities and possibly full nodes, and in particular:

  • To allow authorities to proactively finalise transactions and certificates seen.
  • Enable them to gossip transactions they have seen in a sparse network overlay.
  • Drive the check-pointing protocol.

@gdanezis gdanezis changed the title [node] Add plumbing to allows authorities to connect to other authorities [node] Add plumbing that allows authorities to connect to other authorities Apr 27, 2022

Ok(ActiveAuthority {
authority,
net: AuthorityAggregator::new(committee, authority_clients),
Copy link
Contributor

Choose a reason for hiding this comment

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

So we don't need SafeClient?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, I did wonder about this. The call the AuthorityAggregator::new wraps the network client into a SafeClient, which is a little obscure, BUT safe, since you cannot make an aggregator with an unsafe client.


impl<A> ActiveAuthority<A>
where
A: AuthorityAPI + Send + Sync + 'static + Clone,
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need to define a new trait for the communication among authorities besides AuthorityAPI?

Copy link
Collaborator Author

@gdanezis gdanezis Apr 27, 2022

Choose a reason for hiding this comment

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

Nope. The rule is: everything that the authority can do for itself, an external client can do for the authority too. Active parts in the authority do not exclude active parts outside the authority. Lets try to keep to this as much as we can. This include the checkpointing protocol (which I shall document before my draft pr stops being draft).

Copy link
Contributor

Choose a reason for hiding this comment

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

After extending the AuthorityAPI, I feel like it is getting clunky and keeping smaller, more specialized traits will make it much easier to test and extend functionality.

if let Err(e) = make_server(
net_cfg,
&Committee::from(&network_config),
network_config.buffer_size,
&consensus_committee,
&consensus_store_path,
&consensus_parameters,
Some(net),
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like make_server always take the net as parameter. Might as well take network_config.authorities as param and construct net in there to avoid code redundancy

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I am reluctant to push all the logic in, since I am not entirely familiar with all the call points.

@@ -445,6 +463,7 @@ pub async fn make_server(
consensus_committee: &ConsensusCommittee<Ed25519PublicKey>,
consensus_store_path: &Path,
consensus_parameters: &ConsensusParameters,
net_parameters: Option<Vec<(AuthorityName, String, u16)>>,
Copy link
Contributor

Choose a reason for hiding this comment

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

There's an AuthorityInfo type here that contains all you need:

sui/sui/src/config.rs

Lines 40 to 57 in 7fec599

#[derive(Serialize, Deserialize, Clone, Debug)]
pub struct AuthorityInfo {
#[serde(serialize_with = "bytes_as_hex", deserialize_with = "bytes_from_hex")]
pub name: AuthorityName,
pub host: String,
pub base_port: u16,
}
#[derive(Serialize, Debug)]
pub struct AuthorityPrivateInfo {
pub address: SuiAddress,
pub key_pair: KeyPair,
pub host: String,
pub port: u16,
pub db_path: PathBuf,
pub stake: usize,
pub consensus_address: SocketAddr,
}

You could use it with an impl From<AuthorityPrivateInfo> for AuthorityInfo and eliminate this type signature along with ~25 lines of iterator calls.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh I like that!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In fact there is already a lovely pub fn get_authority_infos(&self) -> Vec<AuthorityInfo> that I will use


impl<A> ActiveAuthority<A>
where
A: AuthorityAPI + Send + Sync + 'static + Clone,
Copy link
Contributor

Choose a reason for hiding this comment

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

After extending the AuthorityAPI, I feel like it is getting clunky and keeping smaller, more specialized traits will make it much easier to test and extend functionality.

A: AuthorityAPI + Send + Sync + 'static + Clone,
{
// TODO: Active tasks go here + logic to spawn them all
pub async fn spawn_all_active_processes(self) -> Option<()> {
Copy link
Contributor

Choose a reason for hiding this comment

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

These will be the processes for gossip?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This should be the location that acts as the root that spawns all tasks dealing with network. So yes, if / when the authority does gossip I presume it will go there?

@gdanezis
Copy link
Collaborator Author

After extending the AuthorityAPI, I feel like it is getting clunky and keeping smaller, more specialized traits will make it much easier to test and extend functionality.

@laura-makdah looking forward to have you back around all this when you are done wrangling narwhals :)

@huitseeker
Copy link
Contributor

This is probably in need of a rebase on #1626, it's about the 5th time I have it fail due to #1624

@gdanezis gdanezis merged commit 3b6cd6b into main Apr 28, 2022
@gdanezis gdanezis deleted the authority-active branch April 28, 2022 09:52
longbowlu pushed a commit that referenced this pull request May 12, 2022
…rities (#1610)

* Add plumbing to allows authorities to connect to other authorities

Co-authored-by: George Danezis <george@danez.is>
punwai pushed a commit that referenced this pull request Jul 27, 2022
…rities (#1610)

* Add plumbing to allows authorities to connect to other authorities

Co-authored-by: George Danezis <george@danez.is>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants