-
Notifications
You must be signed in to change notification settings - Fork 20.2k
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
core: persist bad blocks #21827
core: persist bad blocks #21827
Conversation
I'm not sure... The existing semantics (which is now also supported by Besu) when just making a queiry without parameters is basically " give me the I think we should keep that as is. The usecase that this PR adds support for is basically:
The latter is not really required, IMO, because bad blocks are pretty rare. The former is nice, however..
The nodemonitor will query getbadblocks once every few minutes, I think the LRU is nice to have there |
@holiman yup, i will make the change. |
I agree with @holiman here, we should limit the number of bad blocks on disk so it can't be used to attack the node. It might even be OK to remove the in-memory LRU. |
f1a82fe
to
c165a9d
Compare
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
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.
} | ||
|
||
// WriteBadBlock serializes the bad block into the database. If the cumulated | ||
// bad blocks exceeds the limitation, the oldest will be dropped. |
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.
Hmm thinking out loud: the first bad block is usually the most interesting as it contains the chain split. Maybe it's not a great idea to yeet it out
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.
Yes, but usually all the following blocks will be skipped. So we meet this specific bad block over and over again.
core/rawdb/accessors_chain.go
Outdated
Header: block.Header(), | ||
Body: block.Body(), | ||
}) | ||
sort.Reverse(badBlocks) |
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.
Hm, wait, is there anything here which makes the blocks unique? It may well happen that the blockchain tells the db to save the same exact bad block several times, so we shouldn't store a list with ten instances of the same block.
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 for pointing it out. I have fixed it(also another sort issue). Please take another look.
TxHash: types.EmptyRootHash, | ||
ReceiptHash: types.EmptyRootHash, | ||
}) | ||
WriteBadBlock(db, blockTwo) |
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.
Test uniqueness too:
WriteBadBlock(db, blockTwo) | |
WriteBadBlock(db, blockTwo) | |
WriteBadBlock(db, blockOne) |
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
No description provided.