-
Notifications
You must be signed in to change notification settings - Fork 125
refactor(l1): discovery service #1768
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
Conversation
…o its own folder and files
allow many arguments is a temprarily fix, this will be soled in #1768
f34f403 to
e3e68a4
Compare
|
| let digest = Keccak256::digest(msg.get(65..).ok_or(RLPxError::InvalidMessageLength())?); | ||
| let signature = &Signature::from_bytes( | ||
| msg.get(..64) | ||
| .ok_or(RLPxError::InvalidMessageLength())? | ||
| .into(), | ||
| )?; | ||
| let rid = RecoveryId::from_byte(*msg.get(64).ok_or(RLPxError::InvalidMessageLength())?) | ||
| .ok_or(RLPxError::InvalidRecoveryId())?; | ||
| let peer_pk = VerifyingKey::recover_from_prehash(&digest, signature, rid)?; |
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 remove this because it is recovering the pubkey points bytes (node_id) from the msg, something we already do when decoding the packet (see https://github.com/lambdaclass/ethrex/blob/main/crates/networking/p2p/discv4.rs#L87-L97).
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 is great, missed to comment this on previous review!
| pub(crate) type RLPxConnBroadcastSender = broadcast::Sender<(tokio::task::Id, Arc<Message>)>; | ||
|
|
||
| // https://github.com/ethereum/go-ethereum/blob/master/p2p/peer.go#L44 | ||
| pub const P2P_MAX_MESSAGE_SIZE: usize = 2048; |
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.
The spec doesn't mention a max size but we were using the max size of the discovery protocol, and reading geth code they define 2048 as the max packet size in rlpx, see here.
| tracker.spawn(networking); | ||
| .await.expect("Network starts"); |
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.
Note that we don't need to spawn the networking as a task. This allows us to panic if there is an err during the network startup.
ElFantasma
left a comment
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.
Most comments are minor issues. And some may be wrong 😬
Good work overall!
ElFantasma
left a comment
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.
Nice work!
**Motivation** Discovery service was becoming too big and unmanageable to be inside `net.rs`. **Description** This refactor splits the discovery service into its own structs and files, now the flow is: - `Discv4` struct: handles the core logic of the `discv4` protocol - Loading bootnodes - Listening for incoming connections and handling messages - Managing revalidations - Initiating lookups - `Discv4LookupHandler`: the complexity of the lookups is encapsulated in this struct. The following improvements have also been made: - All Tokio tasks are now spawned using the tracker. - When receiving neighbors' messages, now we check we do not add ourselves to the table (which could occur occasionally). - Error handling has been improved, and the verification logic is now more readable, especially within message handling. Closes None
Motivation
Discovery service was becoming too big and unmanageable to be inside
net.rs.Description
This refactor splits the discovery service into its own structs and files, now the flow is:
Discv4struct: handles the core logic of thediscv4protocolDiscv4LookupHandler: the complexity of the lookups is encapsulated in this struct.The following improvements have also been made:
Closes None