-
-
Notifications
You must be signed in to change notification settings - Fork 426
chore: review epbs gossip topic changes #8715
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
Summary of ChangesHello @nflaig, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request primarily focuses on refining the handling and validation of execution payload bids and envelopes within the beacon node's gossip network. It introduces a new validation constraint for execution payload bids, refactors the signing root computation for execution-related messages, and includes general code cleanup and typo corrections to enhance clarity and maintainability. These changes contribute to more robust and precise processing of gossip messages. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
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.
Code Review
This pull request introduces a series of changes related to EPBS (Execution Payload Bid Submission) gossip topics, primarily for the 'gloas' feature. The changes include refactoring validation logic, adding a new validation rule for execution payload bids, renaming error codes for clarity, and fixing typos. The refactoring improves code quality by making dependencies more explicit and cleaning up unused code.
My review has identified a potential high-severity issue in executionPayloadBidPool.ts where uint64 bid values are compared as numbers. This could lead to precision loss and incorrect bid comparisons for large values. I've suggested reverting to BigInt for these comparisons to ensure correctness.
| const existingValue = existing.value; | ||
| const newValue = value; |
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 value field of an ExecutionPayloadBid is a uint64, which can exceed Number.MAX_SAFE_INTEGER. Comparing these values as numbers can lead to precision loss and incorrect behavior, for example, rejecting a higher-value bid. The previous implementation using BigInt() was safer for comparing these potentially large values. Please revert this change to use BigInt for comparison to avoid bugs with high-value bids.
| const existingValue = existing.value; | |
| const newValue = value; | |
| const existingValue = BigInt(existing.value); | |
| const newValue = BigInt(value); |
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 previous implementation converted number to BigInt which doesn't make much sense since precision is already lost at this point
but either way, this is safe, since the bid value cannot exceed builder balance which is limited by the ETH supply which does not exceed Number.MAX_SAFE_INTEGER
| if (builderBalance < bid.value + MIN_ACTIVATION_BALANCE) { |
|
|
||
| // [REJECT] `bid.builder_index` is a valid, active, and non-slashed builder | ||
| // index. | ||
| // [REJECT] `bid.builder_index` is a valid, active, and non-slashed builder index. |
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 don't think it makes sense to follow spec formatting as it might change at any point if linter rules are adapted, we should rather optimize for readability here
wemeetagain
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.
lgtm
ensi321
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.
Thanks!
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## nc/epbs-p2p #8715 +/- ##
============================================
Coverage 52.08% 52.08%
============================================
Files 848 848
Lines 64754 64754
Branches 4768 4768
============================================
Hits 33725 33725
Misses 30960 30960
Partials 69 69 🚀 New features to boost your workflow:
|
No description provided.