Reduced block production timeout - #5016
Conversation
|
Let's check this on the devnet as we discussed |
|
Well, what we have right now after the run in the devnet:
Right now I'm suspecting that there should be more investigation or/and code change for the shard 0 |
1b9db77 to
cd8dc9d
Compare
|
Deployed on devnet, hardfork in 9 epochs |
|
Tested, result is the same, we still have issue on the shard 0 like previous time. Some of geographically far away nodes are still signing less blocks than 66.6% and getting kicked from the committee:
|
|
This idea doesn't work. With waitTime = 0, the leader freezes the bitmap as soon as 2/3 is reached. Validators whose commit messages are still in flight are recorded as missing, even if they signed prepare and sent commit on time. So they will be excluded from the next epoch committee: |
652294b to
ecd810a
Compare
|
@copilot rebase on dev |
Done, rebased on dev (commit |
|
@Frozen copilot have done strange rebase, it is including 2 commits already in the dev into you PR |
531c565 to
4f688b5
Compare
|
@mur-me rebased |
|
Tick the box to add this pull request to the merge queue (same as
|
|
#5097 - fixed hooray counting on the hmy_consensus_bingo metric |

Reduced block production timeout. On my local machine produced 1639 block for 1664 seconds which is no more than 1.5% deviation for the ideal scenario