Skip to content

Conversation

@mablr
Copy link
Contributor

@mablr mablr commented Oct 14, 2025

Fix #18924

Copy link
Collaborator

@mattsse mattsse left a comment

Choose a reason for hiding this comment

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

lgtm

pending @emhane

@github-project-automation github-project-automation bot moved this from Backlog to In Progress in Reth Tracker Oct 14, 2025
@emhane emhane added this pull request to the merge queue Oct 14, 2025
@emhane emhane removed this pull request from the merge queue due to a manual request Oct 14, 2025
@emhane
Copy link
Collaborator

emhane commented Oct 14, 2025

@mablr could you pls find out if op-geth adheres to specs and sets the fork id key as 'opel' or if it still sets 'eth'? otherwise it may have trouble to connect to the bootnodes.

possibly we can just assume not every node will set it correctly and relax the passing criteria as if key = NetworkStackId::ETH or NetworkStackId::OP...just to be sure we don't disconnect the network

@mablr
Copy link
Contributor Author

mablr commented Oct 14, 2025

@emhane That's right, op-geth still sets the fork id key to "eth".
https://github.com/ethereum-optimism/op-geth/blob/ded9c88e417b1bc196ae1e6475078952dcd1cd53/eth/protocols/eth/discovery.go#L34-L37

On the side on reth I see you created a MustNotIncludeKeys filter, and it is configured to exclude ETH2 keys

let discovered_peer_filter = discovered_peer_filter
.unwrap_or_else(|| MustNotIncludeKeys::new(&[NetworkStackId::ETH2]));

so according to what I understand the rest of keys are accepted.

Tested locally by spawning a op-geth and reth instances :

./build/bin/geth --discv5 --port 30305 --discovery.port 9202

and apparently reth accepts op-geth peer
image

@emhane
Copy link
Collaborator

emhane commented Oct 15, 2025

thanks @mablr ! ETH is EL and ETH2 is CL.

ok so based on op-geth behaviour, let's do this
here

let Some(key) = self.fork_key else { return Err(Error::NetworkStackIdNotConfigured) };
let fork_id = enr
.get_decodable::<EnrForkIdEntry>(key)
.ok_or(Error::ForkMissing(key))?
.map(Into::into)?;

we want to do smthg like this

        let Some(key) = self.fork_key else { return Err(Error::NetworkStackIdNotConfigured) };
        let fork_id = enr
            .get_decodable::<EnrForkIdEntry>(key)
            .ok_or(enr
                .get_decodable::<EnrForkIdEntry>(NetworkStackId::ETH)
                .ok_or(Error::ForkMissing(key)?
            )?
            .map(Into::into)?;

the syntax in my example is a bit off but I think you get the point? would you mind implementing it? would be good if we had a trace log for the case when the configured key isn't found. we will also need to change the error message for Error::ForkMissing(key) to say that neither {key} nor 'eth' were found among the ENR kv-pairs. need to double check also that metrics are update correctly so they don't increment the count for e.g. 'opel' hits when actually it just found the 'eth' key.

@mablr
Copy link
Contributor Author

mablr commented Oct 15, 2025

Thank you very much @emhane for the pointers.

The metrics are incremented based on peer's Enr, I guess this is ok:

pub fn increment_once_by_network_type(&self, enr: &discv5::Enr) {
if enr.get_raw_rlp(NetworkStackId::OPEL).is_some() {
self.opel.increment(1u64)
}
if enr.get_raw_rlp(NetworkStackId::OPSTACK).is_some() {
self.opstack.increment(1u64)
}
if enr.get_raw_rlp(NetworkStackId::ETH).is_some() {
self.eth.increment(1u64)
}
if enr.get_raw_rlp(NetworkStackId::ETH2).is_some() {
self.eth2.increment(1u64)
}

Copy link
Collaborator

@emhane emhane left a comment

Choose a reason for hiding this comment

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

nice! nitpicks remaining

Co-authored-by: emhane <elsaemiliaevahane@gmail.com>
"fork id not found for '{key}' network stack id, trying 'eth'",
key = String::from_utf8_lossy(key),
);
trace!(target: "net::discv5", "Fork id not found for key, trying 'eth'...");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
trace!(target: "net::discv5", "Fork id not found for key, trying 'eth'...");
trace!(target: "net::discv5",
key = String::from_utf8_lossy(key),
"Fork id not found for key, trying 'eth'..."
);

excuse me if wasn't clear, we want to keep the key kv-pair like it was!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

no problem, I reverted it. Assuming decoding here is useful.

@emhane
Copy link
Collaborator

emhane commented Oct 16, 2025

Screenshot 2025-10-16 at 11 19 44 check out how it looks with the message and then the kv-pairs

@emhane emhane added this pull request to the merge queue Oct 16, 2025
Merged via the queue into paradigmxyz:main with commit 386eaa3 Oct 16, 2025
41 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in Reth Tracker Oct 16, 2025
emhane added a commit to op-rs/op-reth that referenced this pull request Oct 20, 2025
…mxyz#18988)

Co-authored-by: emhane <elsaemiliaevahane@gmail.com>
Co-authored-by: Emilia Hane <emiliaha95@gmail.com>
emhane added a commit to op-rs/op-reth that referenced this pull request Oct 20, 2025
…mxyz#18988)

Co-authored-by: emhane <elsaemiliaevahane@gmail.com>
Co-authored-by: Emilia Hane <emiliaha95@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Discv5 doesn't get fork_id from Enr when discovering peer on OPEL network stack

3 participants