-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Add gossipsub message validation #694
Conversation
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.
Overall looks good. I wonder about the NetworkData
trait though. Also should there be a test of this new behavior?
pub trait NetworkData<T>: Debug + Send { | ||
fn take_data(&mut self) -> Option<T>; | ||
} |
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.
pub trait NetworkData<T>: Debug + Send { | |
fn take_data(&mut self) -> Option<T>; | |
} | |
pub trait NetworkData<T>: Debug + Send { | |
type Metadata; | |
fn take_data(self) -> (Self::Metadata, T); | |
} |
I'm thinking it would be better to actually split the type so that we don't have to handle the 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.
hmm maybe we can defer this to a followup task? Ideally in a way that wouldn't require users of this trait to know or care about the concrete type for metadata.
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 did raise this concern in the architecture PR but was told it was an implementation detail. Happy to do a follow up though
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.
yeah I think it's just a matter of having a fully fleshed out proposal of this actually working
…beak/gossipsub_validate_msg
* remove loop from next_event * initial work * more work * trying to use an alternative approach to message id cache * quick break * fix sized issue * finalize gossipsub validation * remove unused * update fast_gossip_message_id * check MessageId calculation * cleanup network orchestrator * move types to p2p for reuse * add consensus gossip data instead * add serde only feature * update with suggestions * remove unused * use gossipsub_config * hash complete messages * use gossipsub config and its builder * import serde only as feature * use test-helpers from fuel-core-interfaces * to the right place in toml Co-authored-by: Brandon Kite <brandonkite92@gmail.com>
* remove loop from next_event * initial work * more work * trying to use an alternative approach to message id cache * quick break * fix sized issue * finalize gossipsub validation * remove unused * update fast_gossip_message_id * check MessageId calculation * cleanup network orchestrator * move types to p2p for reuse * add consensus gossip data instead * add serde only feature * update with suggestions * remove unused * use gossipsub_config * hash complete messages * use gossipsub config and its builder * import serde only as feature * use test-helpers from fuel-core-interfaces * to the right place in toml Co-authored-by: Brandon Kite <brandonkite92@gmail.com>
Closes #679
In this PR we introduce message validation for our gossipsub messages.
The flow goes like this:
In this PR I have also removed unnecessary loop from p2p service's
next_event
.