You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 11, 2024. It is now read-only.
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
Forging
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:
Low Consensus increases missed blocks in the network.
Broadcasts
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.
Summary
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...)
1.0.0-beta.*
The text was updated successfully, but these errors were encountered:
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
Forging
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:
Low Consensus increases missed blocks in the network.
Broadcasts
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:
Summary
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...)
1.0.0-beta.*
The text was updated successfully, but these errors were encountered: