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

Decrease the number of missed/deleted blocks #2080

MaciejBaj opened this Issue May 31, 2018 · 1 comment


2 participants
Copy link

MaciejBaj commented May 31, 2018

Expected behavior

High Consensus

Ensure Consenus stays or reaches high value when there is a delegate slot to forge. Provide the reliable overview of the network status by collecting the information about recent Peers broadhashes. The slots to forge blocks won't be missed then.

High Broadcast performance

Every data (block/transaction/signature) broadcast should reach all of the Peers. The probability of triggering the fork recovery mechanism will be relatively low - blocks won't be deleted.

The end-goal scenario should be possible based on algorithmic Peers selection, that will guarantee 100% coverage of the network while propagating data. By constainting the numbers of Peers to connect, the scalability of the solution will be kept.

Actual behavior


Before forging a block, Broadhash Consensus is being checked. Delegate misses it's slot to forge when Consensus stays < 50 in every of 10 checks within his time slot. It can occur when:

  • Node stays out of sync (explained in #2073),
  • Consensus is calculated basing on outdated data (explained in #2075).

Low Consensus increases missed blocks in the network.


Current data (block/transaction/signature) broadcasts are not reaching the network in the most efficient possible way as shown on studies presented in #2077. It:

  • decreases Consensus (contributes to missed blocks),
  • contributes to deleting blocks by increasing probability of triggering the fork recovery mechanism.


If Consensus reaches the demanded value only at the last forging attempts or broadcasted blocks didn't reach the whole network, it is most likely that fork1 (broadcasting delays) recovery mechanism gets triggered on all of the Peers that will receive the block in next delegates slot. Block gets deleted - the next or the previous delegate loses a block.

Steps to reproduce

Investigate the number of slots missed by delegates/fork.

Which version(s) does this affect? (Environment, OS, etc...)



This comment has been minimized.

Copy link
Member Author

MaciejBaj commented Jun 11, 2018

The problem is solved by adjusting 'maxRelays' and 'broadcastLimit' constants - #2077.

Child issues are also closed.
Closes #2078, #2076, #2073.

@MaciejBaj MaciejBaj closed this Jun 11, 2018

Version 1.0.0 automation moved this from Open Issues to Closed Issues Jun 11, 2018

Sprint Board 30-05-18 automation moved this from New Issues to Closed Issues Jun 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.