-
Notifications
You must be signed in to change notification settings - Fork 801
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
Correct ENR decoding on extension trait #6402
Conversation
Confirmed that discovery searches are working now. Added a commit to fix other occurrences of |
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 find!
@mergify queue |
🛑 The pull request has been removed from the queue
|
@mergify requeue |
✅ This pull request will be re-embarked automaticallyThe followup |
✅ The pull request has been merged automaticallyThe pull request has been merged automatically at a97d77c |
* Correct enr extension encodings * Clippy my ol friend * Correct all encoding and comparisons * Found some more encodings * Fix remaining tests
In #6385 we upgraded to a new version of ENR. This version uses alloy-rlp. We have now explicit typing in decoding values to and from an ENR.
The previous update assumed
Vec<u8>
would be decoded as bytes, but the alloy-rlp implements deocde forVec<T>
as an RLP list. So it was trying to decode a list of u8's rather than raw bytes. As the eth2 and attestation fields are not RLP lists this decoding failed and we marked the ENRs as invalid.This should correct this issue by force the type to be
Bytes
allowing us to decode the raw bytes in the ENR.