fix: miner does not mine its inturn block #268
Merged
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
minh-bq
force-pushed
the
fix/reorg-case
branch
4 times, most recently
from
9b4030c
to
6f11c88
Compare
minh-bq
commented
Apr 25, 2023
DNK90
reviewed
Apr 25, 2023
We have an issue that a miner A is inturn for block 10. At block 9, due to a node is down, miner A mines the out of turn block 9 and broadcast to the network. As a result, miner A cannot mine block 10 due to recently signed rule. However, at block 9, there is another miner B that mines block 9' and this block is accepted by most of nodes in the network. Then based on block 9', block 10 is mined by miner C and there is a slash transaction for miner A because on network view block 9 is mined by miner B not miner A. Miner A receives the chain 9' - 10 and reorgs to that chain. In theory, miner can mine the block 10' which creates a canonical has greater difficulty. This drops the block 10 and the slash transaction. However, currently, miner tries to mine block 11 instead of reproducing new block 10. This leads to miner is slashed even though the node is running well. To fix this issue, when mining, we try to go backward on the canonical chain to find whether we can produce a better chain. If we cannot find way to create a better chain, we start mining based on the current head block same as current implementation. Fixes: axieinfinity#266
andicrypt
pushed a commit
to andicrypt/ronin
that referenced
this pull request
Nov 1, 2023
We have an issue that a miner A is inturn for block 10. At block 9, due to a node is down, miner A mines the out of turn block 9 and broadcast to the network. As a result, miner A cannot mine block 10 due to recently signed rule. However, at block 9, there is another miner B that mines block 9' and this block is accepted by most of nodes in the network. Then based on block 9', block 10 is mined by miner C and there is a slash transaction for miner A because on network view block 9 is mined by miner B not miner A. Miner A receives the chain 9' - 10 and reorgs to that chain. In theory, miner can mine the block 10' which creates a canonical has greater difficulty. This drops the block 10 and the slash transaction. However, currently, miner tries to mine block 11 instead of reproducing new block 10. This leads to miner is slashed even though the node is running well. To fix this issue, when mining, we try to go backward on the canonical chain to find whether we can produce a better chain. If we cannot find way to create a better chain, we start mining based on the current head block same as current implementation. Fixes: axieinfinity#266
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.
We have an issue that a miner A is inturn for block 10. At block 9, due to a
node is down, miner A mines the out of turn block 9 and broadcast to the
network. As a result, miner A cannot mine block 10 due to recently signed rule.
However, at block 9, there is another miner B that mines block 9' and this block
is accepted by most of nodes in the network. Then based on block 9', block 10 is
mined by miner C and there is a slash transaction for miner A because on network
view block 9 is mined by miner B not miner A. Miner A receives the chain 9' -
10 and reorgs to that chain. In theory, miner can mine the block 10' which
creates a canonical has greater difficulty. This drops the block 10 and the
slash transaction. However, currently, miner tries to mine block 11 instead of
reproducing new block 10. This leads to miner is slashed even though the node is
running well.
To fix this issue, when mining, we try to go backward on the canonical chain to
find whether we can produce a better chain. If we cannot find way to create a
better chain, we start mining based on the current head block same as current
implementation.
Fixes: #266