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

fix: drop amnesia attacks in consumer misbehaviour handling #1388

Merged
merged 2 commits into from
Nov 2, 2023

Conversation

sainoe
Copy link
Contributor

@sainoe sainoe commented Nov 2, 2023

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...

  • Included the correct type prefix in the PR title
  • Added ! to the type prefix if state-machine breaking change (i.e., requires coordinated upgrade)
  • Confirmed this PR does not introduce changes requiring state migrations, OR migration code has been added to consumer and/or provider modules
  • Targeted the correct branch (see PR Targeting)
  • Provided a link to the relevant issue or specification
  • Followed the guidelines for building SDK modules
  • Included the necessary unit and integration tests
  • Added a changelog entry to CHANGELOG.md
  • Included comments for documenting Go code
  • Updated the relevant documentation or specification
  • Reviewed "Files changed" and left comments if necessary
  • Confirmed all CI checks have passed
  • If this PR is library API breaking, bump the go.mod version string of the repo, and follow through on a new major release for both the consumer and provider

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...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed this PR does not introduce changes requiring state migrations, OR confirmed migration code has been added to consumer and/or provider modules
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage

@sainoe sainoe requested a review from a team as a code owner November 2, 2023 14:57
@sainoe sainoe linked an issue Nov 2, 2023 that may be closed by this pull request
Copy link
Contributor

@mpoke mpoke left a comment

Choose a reason for hiding this comment

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

LGTM

x/ccv/provider/keeper/misbehaviour.go Show resolved Hide resolved
// 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 {
Copy link
Contributor

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 blockIDs have to be different (e.g., see here) and blockID is a hash that incorporates among others the above fields (?)

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@sainoe sainoe merged commit 6e85f2c into release/v2.2.x-provider-lsm Nov 2, 2023
7 checks passed
@sainoe sainoe deleted the sainoe/amnesia-fix branch November 2, 2023 17:19
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.

Drop Amnesia attacks
3 participants