-
Notifications
You must be signed in to change notification settings - Fork 10
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
Stub network
crate
#43
Conversation
# Conflicts: # Cargo.lock
Nice! We need to decide on the thing that is going to poll the swarm. In lighthouse we have The next part will be building a config for the network, instantiating it and then initialising it on boot. Dialing peers and that will be handled by discovery and the peer manager, once we add them in. I think for initial steps, it might be nice to just dial some configured boot-nodes and listen on some gossipsub topics. We could do these steps in future PRs |
If we can group both objects together, we might get away with just calling this crate |
1cf654c
to
09c23ba
Compare
Co-authored-by: Age Manning <[email protected]>
09c23ba
to
ded9e77
Compare
# Conflicts: # Cargo.lock # Cargo.toml # anchor/client/Cargo.toml # anchor/client/src/cli.rs # anchor/client/src/config.rs # anchor/client/src/lib.rs
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.
Great start! Nice work
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.
looks good
if let Ok(mut network_key_file) = File::open(network_key_f.clone()) { | ||
let mut key_bytes: Vec<u8> = Vec::with_capacity(36); | ||
match network_key_file.read_to_end(&mut key_bytes) { | ||
Err(_) => debug!("Could not read network key file"), |
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.
Should we return an error if the key file exists but can't be read?
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.
Good question - the current behaviour is, if the file does not exist, is invalid or cannot be read, then we generate a new one.
This is the same behaviour from Lighthouse - tbh I didn't really think about changing it when I copied this from LH. This node private key is mostly transparent to the user and used for node id, peer id and noise protocol encryption. As it's transparent to the user, I think it's better UX to treat it as invalid if the file cannot be read, and regenerate a new one, instead of crashing and asking the user to fix it manually or delete the existing corrupted file.
Addresses #17 partially.
Specification: https://github.com/ssvlabs/ssv-spec/tree/main/p2p