Skip to content
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

Beacon node slasher improvement #13549

Merged
merged 29 commits into from Jan 31, 2024
Merged

Beacon node slasher improvement #13549

merged 29 commits into from Jan 31, 2024

Conversation

nalepae
Copy link
Contributor

@nalepae nalepae commented Jan 29, 2024

Please read this PR commit by commit. Some commit messages contain a lot of information.

What type of PR is this?
Bug fix

What does this PR do? Why is it needed?
Commits with commit message ending by NFC (no functional changes) do not contain any functional change.

Which issues(s) does this PR fix?
Fixes:

nalepae added a commit that referenced this pull request Jan 29, 2024
If a first batch of blocks is sent with:
- validator 1 - slot 4 - signing root 1
- validator 1 - slot 5 - signing root 1

Then, if a second batch of blocks is sent with:
- validator 1 - slot 4 - signing root 2

Because we have two blocks proposed by the same validator (1) and for
the same slot (4), but with two different signing roots (1 and 2), the
validator 1 should be slashed.

This is not the case before this commit.
A new test case has been added as well to check this.

Fixes #13549
@nalepae nalepae force-pushed the slasher-memory-leak-13430 branch 2 times, most recently from 44bbbe1 to c33ec19 Compare January 29, 2024 11:09
@nalepae nalepae marked this pull request as ready for review January 29, 2024 17:07
@nalepae nalepae requested a review from a team as a code owner January 29, 2024 17:07
bkt := tx.Bucket(attestedEpochsByValidator)

min := i + batchSize
Copy link
Contributor

Choose a reason for hiding this comment

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

'min' collides with the 'builtin' function, could we consider renaming this variable?

beacon-chain/db/slasherkv/slasher.go Outdated Show resolved Hide resolved
beacon-chain/db/slasherkv/slasher.go Outdated Show resolved Hide resolved
@@ -12,10 +12,18 @@ import (
"github.com/sirupsen/logrus"
)

const (
couldNotSaveAttRecord = "Could not save attestation records to DB"
couldNotSaveSlashableAtt = "Could not check slashable attestations"
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
couldNotSaveSlashableAtt = "Could not check slashable attestations"
couldNotSaveSlashableAtt = "Could not save slashable attestations"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually the message is the OK but the name of the variable is bad. Will fix it.

Fixes #13550.
In tests, `exitChan` are now useless since waitgroup are used to wait
for all goroutines to be stopped.
- Rename some variables.
- Add comments.
- Use second element of `range` when possible.
Avoid mixes between `indice(s)`and `index(es)`.
- Same target with different signing roots
- Same target with same signing roots
Before this commit, `checkDoubleVotes` did two tasks:
- Checking if there are any slashable double votes in the input
  list of attestations with respect to each other.
- Checking if there are any slashable double votes in the input
  list of attestations with respect to our database.

However, `checkDoubleVotes` is called only in
`checkSlashableAttestations`.

And `checkSlashableAttestations` is called only in:
- `processQueuedAttestations`, and in
- `IsSlashableAttestation`

Study of case `processQueuedAttestations`:
---------------------------------------------
In `processQueuedAttestations`, `checkSlashableAttestations`
is ALWAYS called after
`Database.SaveAttestationRecordsForValidators`.

It means that, when calling `checkSlashableAttestations`,
`validAtts` are ALREADY stored in the DB.

Each attestation of `validAtts` will be checked twice:
- Against the other attestations of `validAtts` (the portion of
  deleted code)
- Against the content of the database.

One of those two checks is redundent.
==> We can remove the check against other attestations in `validAtts`.

Study of case `Database.SaveAttestationRecordsForValidators`:
----------------------------------------------------------------
In `Database.SaveAttestationRecordsForValidators`,
`checkSlashableAttestations` is ALWAYS called with a list of
attestations containing only ONE attestation.

This only attestaion will be checked twice:
- Against itself, and an attestation cannot conflict with itself.
- Against the content of the database.

==> We can remove the check against other attestations in `validAtts`.

=========================

In both cases, we showed that we can remove the check of attestation
against the content of `validAtts`, and the corresponding test
`Test_checkDoubleVotes_SlashableInputAttestations`.
If a first batch of blocks is sent with:
- validator 1 - slot 4 - signing root 1
- validator 1 - slot 5 - signing root 1

Then, if a second batch of blocks is sent with:
- validator 1 - slot 4 - signing root 2

Because we have two blocks proposed by the same validator (1) and for
the same slot (4), but with two different signing roots (1 and 2), the
validator 1 should be slashed.

This is not the case before this commit.
A new test case has been added as well to check this.

Fixes #13551
Well, even if, in our case, "happy path" mean slashing.
In case of multiple votes, arbitrarily save the first attestation.
Saving the first one in particular has no functional impact,
since in any case all attestations will be tested against
the content of the database. So all but the first one will be
detected as slashable.

However, saving the first one and not an other one let us not
to modify the end to end tests, since they expect the first one
to be saved in the database.
Not to conflict with the new `min` built-in function.
Copy link
Contributor

@rauljordan rauljordan left a comment

Choose a reason for hiding this comment

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

Nice improvements, thanks @nalepae !

@nalepae nalepae added this pull request to the merge queue Jan 31, 2024
Merged via the queue into develop with commit 7a294e8 Jan 31, 2024
17 checks passed
@nalepae nalepae deleted the slasher-memory-leak-13430 branch January 31, 2024 10:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants