-
Notifications
You must be signed in to change notification settings - Fork 271
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
feat(p2p): remaining p2p topic validators #10734
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
2c27b95
to
26c1ed8
Compare
74f2033
to
96a5400
Compare
26c1ed8
to
361753b
Compare
96a5400
to
f3587f0
Compare
f3587f0
to
546d6fa
Compare
post merge this has since broken, looking into it eidt: needed to do plumbing of the new date provider |
const { currentSlot, nextSlot } = await this.epochCache.getProposerInCurrentOrNextSlot(); | ||
|
||
// Check that the attestation is for the current or next slot | ||
const slotNumberBigInt = attestation.payload.header.globalVariables.slotNumber.toBigInt(); |
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 feel like the core validation logic for a BlockAttestation (and BlockProposal, EpochProofQuote, and ideally Tx) should all reside in their respective classes and just take as inputs the information they need.
So in this case we could call attestation.validate(epochCache)
and it could return a PeerErrorSeverity
.
That would make for easier reuse elsewhere, and easier testing (since it looks like none of these are tested?)
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 agreed, I can write it as such
7737ab7
to
a0ef925
Compare
a0ef925
to
9f4f1e1
Compare
Applies epoch and attestation validity checks into the gossip sub module