Force consensus loss for parent block if its hash mismatches parent_hash #1657
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
assigned 
goodsoft
force-pushed
the
gs-fix-consensus-loss
branch
from
44b2ddd
to
5b0618c
Compare
goodsoft
added
ready for review
vbaranov
approved these changes
Mar 27, 2019
vbaranov
reviewed
Mar 27, 2019
| SELECT b0.number - 1 FROM "blocks" AS b0 | ||
| LEFT JOIN "blocks" AS b1 ON (b0."parent_hash" = b1."hash") AND b1."consensus" | ||
| WHERE b0."number" > 0 AND b0."consensus" AND b1."hash" IS NULL | ||
| ); |
There was a problem hiding this comment.
@goodsoft
I think we should add at the end and consensus = true; clause to be sure that b0.number - 1 has not already marked as non-consensus before. Otherwise, the where query will return non-empty list every time
There was a problem hiding this comment.
And I believe we should also update updated_at in the query above
ayrat555
reviewed
Mar 27, 2019
| initial = from(b in Block, where: false) | ||
|
|
||
| Enum.reduce(blocks_changes, initial, fn %{consensus: consensus, parent_hash: parent_hash, number: number}, acc -> | ||
| case consensus do |
There was a problem hiding this comment.
I think it is much cleaner to use if instead of case here
if consensus do
There was a problem hiding this comment.
I like copy-pasting code from neighboring functions :D
ayrat555
approved these changes
Mar 27, 2019
goodsoft
force-pushed
the
gs-fix-consensus-loss
branch
from
8e93c6a
to
5b03ebc
Compare
Fixes #1644 When reorg occurs and the older of new blocks fails to be imported, the old consensus block remains in the database. Catchup fetcher ignores it, and we get a discontinuity in the main chain. This commit adds an additional consensus loss step during block import: the parent block with hash not matching parent_hash of current block is marked non-consensus, thus creating a hole in main chain, forcing catchup fetcher to retry fetching it.
goodsoft
force-pushed
the
gs-fix-consensus-loss
branch
from
5b03ebc
to
f5268fc
Compare
zachdaniel
approved these changes
Mar 27, 2019
goodsoft
added a commit
that referenced
this pull request
Mar 29, 2019
As a result of #1657 out-of-place parent blocks are marked as non-consensus more reliably, i.e. they will eventually be fetched even if first attempt is unsuccessful. The `ConsensusEnsurer` module, on the contrary, only tried refetching block once, and left it as-is if the refetch failed. Now it is not needed anymore.
goodsoft
added a commit
that referenced
this pull request
Mar 29, 2019
As a result of #1657 out-of-place parent blocks are marked as non-consensus more reliably, i.e. they will eventually be fetched even if first attempt is unsuccessful. The `ConsensusEnsurer` module, on the contrary, only tried refetching block once, and left it as-is if the refetch failed. Now it is not needed anymore.
goodsoft
added a commit
that referenced
this pull request
Mar 29, 2019
As a result of #1657 out-of-place parent blocks are marked as non-consensus more reliably, i.e. they will eventually be fetched even if first attempt is unsuccessful. The `ConsensusEnsurer` module, on the contrary, only tried refetching block once, and left it as-is if the refetch failed. Now it is not needed anymore.
goodsoft
added a commit
that referenced
this pull request
Apr 2, 2019
As a result of #1657 out-of-place parent blocks are marked as non-consensus more reliably, i.e. they will eventually be fetched even if first attempt is unsuccessful. The `ConsensusEnsurer` module, on the contrary, only tried refetching block once, and left it as-is if the refetch failed. Now it is not needed anymore.
goodsoft
added a commit
that referenced
this pull request
Apr 2, 2019
As a result of #1657 out-of-place parent blocks are marked as non-consensus more reliably, i.e. they will eventually be fetched even if first attempt is unsuccessful. The `ConsensusEnsurer` module, on the contrary, only tried refetching block once, and left it as-is if the refetch failed. Now it is not needed anymore.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #1644
When reorg occurs and the older of new blocks fails to be imported, the old consensus block remains in the database. Catchup fetcher ignores it, and we get a discontinuity in the main chain.
This commit adds an additional consensus loss step during block import: the parent block with hash not matching parent_hash of current block is marked non-consensus, thus creating a hole in main chain, forcing catchup fetcher to retry fetching it.
Upgrading
A query from
scripts/20190326202921_lose_consensus_for_invalid_blocks.sqlshould be run to mark existing invalid blocks as non-consensus.