-
Notifications
You must be signed in to change notification settings - Fork 122
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
fix: drop amnesia attacks in consumer misbehaviour handling #1388
Conversation
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
// we can't identify the byzantine validators. | ||
// | ||
// Note that we cannot differentiate which of the headers is trusted or malicious, | ||
if !headersStateTransitionsAreConflicting(*lightBlock1.Header, *lightBlock2.Header) && lightBlock1.Commit.Round != lightBlock2.Commit.Round { |
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.
It's not clear to me why those header fields (i.e., ValidatorsHash
, NextValidatorsHash
etc.) must be the same?
I'm not sure what I'm missing but my understanding is that for this to be misbehaviour the blockID
s have to be different (e.g., see here) and blockID
is a hash that incorporates among others the above fields (?)
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.
These fields must be the same because, in all amnesia scenarios, it's assumed that correct validators validate both headers.
The BlockID hash contains other fields that are only related to the current block e.g. the time or the proposer.
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.
Deleted my previous comment. After the offline discussion we had yesterday this makes sense and the above code checks what CometBFT already checks in GetByzantineValidators.
Thanks @sainoe !
Just for posterity: If we have 2 headers at the same height H
with h1.AppHash != h2.AppHash
then this is a lunatic attack because AppHash
is computed as the "state after txs from the previous block" H - 1
. Only a "lunatic" validator would have 2 different views of the AppHash
when applying the transactions of a previous block. The same is the case for all the fields that are based on the previous block which are the ones checked against in headersStateTransitionsAreConflicting
. In case of a lunatic attack we can still slash.
Description
Closes: #1387
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if state-machine breaking change (i.e., requires coordinated upgrade)CHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change