...
| Page Properties | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||
|
...
0 View changes (5 signatures needed for commit, 3 received)
| X | X |
|---|
1 View change (5 signatures needed for commit, 3 received)
| X | X |
|---|
2 View changes (5 signatures needed for commit, 3 received)
| X | X |
|---|
3 View changes (5 signatures needed for commit, 4 received)
| X | X |
|---|
4 View changes (5 signatures needed for commit, 4 received)
| X | X |
|---|
5 View changes (5 signatures needed for commit, 4 received)
| X | X |
|---|
6 View changes (5 signatures needed for commit, 4 received)
| X | X |
|---|
This shows that it will not be possible to commit block and the view will be changing until the network is stopped or more peers join.
The problem is with that the faulty peers are distributed across the topology, if they were close together, the change views would help.
Solution
It is suggested to try at first shifting peers by 1 as was done previously up to N times. Then if the problems persist change view by shuffling peers again (as in after the blocks are committed) instead of shifting by one. And to make the process deterministic take the tuple (block_height, n_change_views) as a seed for this shuffling.
Decisions
Alternatives
?Shuffle peers at every change view - can be costly and not optimal in cases with faulty leader.
Concerns
As with any random process shuffling does not guarantee that particular network topology will be reached, and the network theoretically still can be stuck for forever, though with a very low probability.
...