-
Notifications
You must be signed in to change notification settings - Fork 11.4k
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
Conversation
|
||
Ok(ActiveAuthority { | ||
authority, | ||
net: AuthorityAggregator::new(committee, authority_clients), |
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.
So we don't need SafeClient?
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.
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, |
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.
Do we need to define a new trait for the communication among authorities besides AuthorityAPI?
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.
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).
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.
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), |
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.
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
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.
I am reluctant to push all the logic in, since I am not entirely familiar with all the call points.
sui/src/sui_commands.rs
Outdated
@@ -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)>>, |
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.
There's an AuthorityInfo
type here that contains all you need:
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.
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.
Oh I like that!
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 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, |
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.
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<()> { |
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.
These will be the processes for gossip?
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.
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?
@laura-makdah looking forward to have you back around all this when you are done wrangling narwhals :) |
24d4052
to
98945a2
Compare
…rities (#1610) * Add plumbing to allows authorities to connect to other authorities Co-authored-by: George Danezis <george@danez.is>
…rities (#1610) * Add plumbing to allows authorities to connect to other authorities Co-authored-by: George Danezis <george@danez.is>
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: